Early Review of draft-ietf-idr-ls-distribution-05
review-ietf-idr-ls-distribution-05-rtgdir-early-lindem-2014-09-10-00

Request Review of draft-ietf-idr-ls-distribution
Requested rev. no specific revision (document currently at 13)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2014-09-10
Requested 2014-08-29
Authors Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray
Draft last updated 2014-09-10
Completed reviews Genart Last Call review of -10 by Alexey Melnikov (diff)
Secdir Last Call review of -10 by Matthew Miller (diff)
Opsdir Last Call review of -10 by Carlos Pignataro (diff)
Rtgdir Early review of -05 by Acee Lindem (diff)
Assignment Reviewer Acee Lindem
State Completed
Review review-ietf-idr-ls-distribution-05-rtgdir-early-lindem-2014-09-10
Reviewed rev. 05 (document currently at 13)
Review result Has Issues
Review completed: 2014-09-10

Review
review-ietf-idr-ls-distribution-05-rtgdir-early-lindem-2014-09-10

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