Hi, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-ls-distribution-05.txt Reviewer: Acee Lindem Review Date: 09/09/2014 Current IDR WG Document Intended Status: Standards Track Summary: The draft describes encoding for the encoding of the IGP link-state database and TE database in BGP NRLI. This information is advertised in to external BGP speakers performing applicaiton such as Path Computation Element (PCE) servers and Application-Layer Traffic Optimizers (ALTO) servers. My opinion is that the draft needs significant improvement prior to publication. Major Issues: 1. The draft should indicate the overall goal of translating the IGP link state database and TE Database into a generic representation. It should also better enumerate the requirements for this translation. 2. The draft includes opaque attribute TLVs for advertising protocol-specific information (node, link, and prefix). However, there is no indication on how this information is encoded or identified. Hence, there can be no interoperability between implementations. 3. The draft is based mainly on ISIS encoding and does a poor job of representing the OSPF. Examples include: A. Page 10 - There is no protocol-id for OSPFv3. B. Page 11 - Why is RFC 6822 normative and RFC 6549 informational? C. Psuedonode Representation - The absence of a condensed format for the pseudonode following the OSPF model. D. Page 15 - Relevant OSPF RFCs should be referenced for TLV code points. E. Page 18 - Why an ISIS Area identifier and not an OSPF Area identifier? F. Page 18 - 'E' is for an ASBR and 'B' is for ABR. G. Page 19 - RFC 5642 is the OSPF Node Name RFC. H. Page 21 - Should be references to OSPF RFC, RFC 3630, RFC 4203, and RFC 5329. I. Page 22 - OSPF Link metrics are 2 bytes but OSPF prefix metrics are 3 bytes. J. Page 25 - OSPF Prefix Options are defined in RFC 5340, A.4.1.1. It not clear which need to be advertised. K. Page 26 - Forwarding Address for OSPFv3 should reference RFC 5340 as well. 4. Section 3.2.15 - Why do you limit a link or prefix to a single MT-ID? Links and prefixes can be reachable in multiple topologies with different metrics. Is this simply a typo? Minor Issues: 1. Figures and tables are referenced by number, yet those figures and tables are not numbered. 2. Several acronymns that are not designated as well-known are not expanded with the first usage. Examples include LSDB and TED. Refer to http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt . 3. Page 11 - The table mentions L1 optical topology but there are are no optical attributes. This seems like it should be removed and added when GMPLS information is defined for BGP LS. 4. Page 11 - The BGP-LS Identifier is referenced before it is defined. 5. Page 17 - In the context of this NRLI, what purpose does the next hop address serve? If none, couldn't we just advertise a 0 length network address? 6. Page 18 - Why isn't the IS-IS Area Identifier applicable to prefixes? OSPF can scope prefixes to areas (unless they AS-External). 7. For FQDN node/link name recommendation - should usage dictate "RECOMMENDED" rather than "recommended”? 8. Page 21 - Is knowing whether MPLS signaling is enabled on a link all that is needed by the applications? This seems somewhat out of place with the LSDB and TE data. Nits: *************** *** 21,27 **** called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically ! distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared --- 21,27 ---- called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically ! distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared *************** *** 246,252 **** routers in a POP. Abstracted topology can also be a mix of physical and virtual nodes and physical and virtual links. Furthermore, the BGP Speaker can apply policy to determine when information is updated ! to the consumer so that there is reduction of information flow form the network to the consumers. Mechanisms through which topologies can be aggregated or virtualized are outside the scope of this document --- 246,252 ---- routers in a POP. Abstracted topology can also be a mix of physical and virtual nodes and physical and virtual links. Furthermore, the BGP Speaker can apply policy to determine when information is updated ! to the consumer so that there is reduction of information flow from the network to the consumers. Mechanisms through which topologies can be aggregated or virtualized are outside the scope of this document *************** *** 267,278 **** policy control and algorithms, and coordination of computation across the whole area. ! o If a router wants to compute a MPLS-TE path across IGP areas its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path, and cannot even select the right exit router (Area Border Router - ABR) for an optimal path. This is an issue for large-scale networks that ! need to segment their core networks into distinct areas, but which still want to take advantage of MPLS-TE. Previous solutions used per-domain path computation [RFC5152]. The --- 267,279 ---- policy control and algorithms, and coordination of computation across the whole area. ! o If a router wants to compute an MPLS-TE path across multiple IGP ! areas, then its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path, and cannot even select the right exit router (Area Border Router - ABR) for an optimal path. This is an issue for large-scale networks that ! need to segment their core networks into distinct areas, but still want to take advantage of MPLS-TE. Previous solutions used per-domain path computation [RFC5152]. The *************** *** 426,434 **** (thus a TLV with no value portion would have a length of zero). The TLV is not padded to four-octet alignment. Unrecognized types are preserved and propagated. In order to compare NLRIs with unknown ! TLVs all TLVs MUST be ordered in ascending order. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending ! order of the TLV value within the set of TLVs with the same type. All TLVs that are not specified as mandatory are considered optional. 3.2. The Link-State NLRI --- 427,435 ---- (thus a TLV with no value portion would have a length of zero). The TLV is not padded to four-octet alignment. Unrecognized types are preserved and propagated. In order to compare NLRIs with unknown ! TLVs, all TLVs MUST be in ascending order by TLV type. If there are multiple TLVs of the same type, then the TLVs MUST be ordered in ascending ! order of the TLV value within the TLVs with the same type. All TLVs that are not specified as mandatory are considered optional. 3.2. The Link-State NLRI *************** *** 490,496 **** The 'Total NLRI Length' field contains the cumulative length, in octets, of rest of the NLRI not including the NLRI Type field or ! itself. For VPN applications it also includes the length of the Route Distinguisher. The 'NLRI Type' field can contain one of the following values: --- 491,497 ---- The 'Total NLRI Length' field contains the cumulative length, in octets, of rest of the NLRI not including the NLRI Type field or ! itself. For VPN applications, it also includes the length of the Route Distinguisher. The 'NLRI Type' field can contain one of the following values: *************** *** 665,671 **** transitions it may happen that two redundant IGPs are in place. In section Section 3.2.1.4 a set of sub-TLVs is described, which ! allows to specify a flexible key for any given Node/Link information such that global uniqueness of the NLRI is ensured. 3.2.1.2. Local Node Descriptors --- 666,672 ---- transitions it may happen that two redundant IGPs are in place. In section Section 3.2.1.4 a set of sub-TLVs is described, which ! allows specification of a flexible key for any given Node/Link information such that global uniqueness of the NLRI is ensured. 3.2.1.2. Local Node Descriptors *************** *** 749,762 **** non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). For an IS-IS Pseudonode corresponding to a LAN, this contains 6 octet ISO node-ID of the "Designated Intermediate System" (DIS) ! followed by one octet nonzero PSN identifier (7 octet in total). ! For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains 4 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this ! contains 4 octet Router-ID of the designated router (DR) followed ! by 4 octet IPv4 address of the DR's interface to the LAN (8 octet ! in total). Similarly, for an OSPFv3 "Pseudonode", this contains 4 ! octet Router-ID of the DR followed by 4 octet interface identifier ! of the DR's interface to the LAN (8 octet in total). The TLV size in combination with protocol identifier enables the decoder to determine the type of the node. --- 750,763 ---- non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). For an IS-IS Pseudonode corresponding to a LAN, this contains 6 octet ISO node-ID of the "Designated Intermediate System" (DIS) ! followed by one octet nonzero PSN identifier (7 octets in total). ! For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this ! contains the 4 octet Router-ID of the designated router (DR) followed ! by the 4 octet IPv4 address of the DR's interface to the LAN (8 octets ! in total). Similarly, for an OSPFv3 "Pseudonode", this contains the 4 ! octet Router-ID of the DR followed by the 4 octet interface identifier ! of the DR's interface to the LAN (8 octets in total). The TLV size in combination with protocol identifier enables the decoder to determine the type of the node. *************** *** 770,777 **** There can be at most one instance of each sub-TLV type present in ! any Node Descriptor. The TLV ordering within a Node descriptor ! MUST be kept in order of increasing numeric value of type. This needs to be done in order to compare NLRIs, even when an implementation encounters an unknown sub-TLV. Using stable sorting an implementation can do binary comparison of NLRIs and hence --- 771,778 ---- There can be at most one instance of each sub-TLV type present in ! any Node Descriptor. The sub-TLVs within a Node descriptor ! MUST be arranged in ascending order by sub-TLV type. This needs to be done in order to compare NLRIs, even when an implementation encounters an unknown sub-TLV. Using stable sorting an implementation can do binary comparison of NLRIs and hence *************** *** 804,812 **** carried in the TLV. The MT-ID TLV MAY be present in a Link Descriptor, a Prefix ! Descriptor, or in the BGP-LS attribute of a node NLRI. In Link or ! Prefix Descriptor, only one MT-ID TLV containing only the MT-ID of ! the topology where the link or the prefix belongs is allowed. In the --- 805,813 ---- carried in the TLV. The MT-ID TLV MAY be present in a Link Descriptor, a Prefix ! Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or ! Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of ! the topology where the link or the prefix is reachable is allowed. In the *************** *** 828,834 **** Internet-Draft Link-State Info Distribution using BGP May 2014 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array ! of MT-IDs of all topologies where the node belongs can be present. 3.2.2. Link Descriptors --- 829,835 ---- Internet-Draft Link-State Info Distribution using BGP May 2014 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array ! of MT-IDs of all topologies where the node is reachable is allowed. 3.2.2. Link Descriptors *************** *** 838,845 **** links between a pair of anchor routers. A link described by the Link descriptor TLVs actually is a "half-link", a unidirectional representation of a logical link. In order to fully describe a ! single logical link two originating routers advertise a half-link ! each, i.e. two link NLRIs are advertised for a given point-to-point link. The format and semantics of the 'value' fields in most 'Link --- 839,846 ---- links between a pair of anchor routers. A link described by the Link descriptor TLVs actually is a "half-link", a unidirectional representation of a logical link. In order to fully describe a ! single logical link, two originating routers advertise a half-link ! each, i.e., two link NLRIs are advertised for a given point-to-point link. The format and semantics of the 'value' fields in most 'Link *************** *** 888,894 **** If interface and neighbor addresses are not present and the link local/remote identifiers are present, then the link local/remote ! Identifier TLV is included in link descriptor. The Multi-Topology Identifier TLV is included in link descriptor if that information is present. --- 889,895 ---- If interface and neighbor addresses are not present and the link local/remote identifiers are present, then the link local/remote ! Identifier TLV is included in the link descriptor. The Multi-Topology Identifier TLV is included in link descriptor if that information is present. *************** *** 917,924 **** OSPF Route Type is an optional TLV that MAY be present in Prefix NLRIs. It is used to identify the OSPF route-type of the prefix. It is used when an OSPF prefix is advertised in the OSPF domain with ! multiple different route-types. The Route Type TLV allows to ! discriminate these advertisements. The format of the OSPF Route Type TLV is shown in the following figure. 0 1 2 3 --- 918,925 ---- OSPF Route Type is an optional TLV that MAY be present in Prefix NLRIs. It is used to identify the OSPF route-type of the prefix. It is used when an OSPF prefix is advertised in the OSPF domain with ! multiple route-types. The Route Type TLV allows discrimination of ! these advertisements. The format of the OSPF Route Type TLV is shown in the following figure. 0 1 2 3 *************** *** 957,963 **** The IP Reachability Information is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP ! topology. Its purpose is to glue a particular BGP service NLRI vi virtue of its BGP next-hop to a given Node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. The format of the IP Reachability Information TLV is shown in the --- 958,964 ---- The IP Reachability Information is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP ! topology. Its purpose is to glue a particular BGP service NLRI by virtue of its BGP next-hop to a given Node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. The format of the IP Reachability Information TLV is shown in the *************** *** 1052,1061 **** 3.3.1.2. IS-IS Area Identifier TLV An IS-IS node can be part of one or more IS-IS areas. Each of these ! area addresses is carried in the IS-IS Area Identifier TLV. If more ! than one Area Addresses are present, multiple TLVs are used to encode them. The IS-IS Area Identifier TLV may be present in the BGP-LS ! attribute only with the Link-State Node NLRI. --- 1053,1062 ---- 3.3.1.2. IS-IS Area Identifier TLV An IS-IS node can be part of one or more IS-IS areas. Each of these ! area addresses is carried in the IS-IS Area Identifier TLV. If multiple ! Area Addresses are present, multiple TLVs are used to encode them. The IS-IS Area Identifier TLV may be present in the BGP-LS ! attribute only when advertised in the Link-State Node NLRI. *************** *** 1087,1093 **** ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display. ! Altough [RFC5301] is a IS-IS specific extension, usage of the Node Name TLV is possible for all protocols. How a router derives and injects node names for e.g. OSPF nodes, is outside of the scope of this document. --- 1088,1094 ---- ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display. ! Altough [RFC5301] is an IS-IS specific extension, usage of the Node Name TLV is possible for all protocols. How a router derives and injects node names for e.g. OSPF nodes, is outside of the scope of this document. *************** *** 1281,1288 **** The IGP Metric TLV carries the metric for this link. The length of this TLV is variable, depending on the metric width of the underlying protocol. IS-IS small metrics have a length of 1 octet (the two most ! significant bits are ignored). OSPF metrics have a length of two ! octects. IS-IS wide-metrics have a length of three octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 --- 1282,1289 ---- The IGP Metric TLV carries the metric for this link. The length of this TLV is variable, depending on the metric width of the underlying protocol. IS-IS small metrics have a length of 1 octet (the two most ! significant bits are ignored). OSPF link metrics have a length of two ! octets. IS-IS wide-metrics have a length of three octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 *************** *** 1542,1549 **** BGP link-state information for both IPv4 and IPv6 networks can be carried over either an IPv4 BGP session, or an IPv6 BGP session. If ! IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI ! SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. Usually the next hop will be set to the local end-point address of the BGP session. The next hop address MUST be encoded as described --- 1543,1550 ---- BGP link-state information for both IPv4 and IPv6 networks can be carried over either an IPv4 BGP session, or an IPv6 BGP session. If ! an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI ! SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. Usually the next hop will be set to the local end-point address of the BGP session. The next hop address MUST be encoded as described *************** *** 1833,1839 **** An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from ! neighbors An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in router's RIB. --- 1834,1840 ---- An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from ! neighbors. An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in router's RIB. *************** *** 1846,1852 **** instance ID. An implementation SHOULD allow the operator to configure a pair of ! ASN and BGP-LS identifier per flooding set the node participates in. 6.2.4. Accounting Management --- 1847,1853 ---- instance ID. An implementation SHOULD allow the operator to configure a pair of ! ASN and BGP-LS identifiers per flooding set in which the node participates. 6.2.4. Accounting Management *************** *** 1981,1987 **** Speaker. An operator SHOULD employ a mechanism to protect a BGP Speaker ! against DDOS attacks from Consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits. --- 1982,1988 ---- Speaker. An operator SHOULD employ a mechanism to protect a BGP Speaker ! against DDoS attacks from Consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits. Thanks, Acee