Subject: [Idr] Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 9 Sep 2014 23:33:10 +0000

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

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 10 Sep 2014 09:20:05 +0200

hi acee,

thanks for reviewing the document thoroughly. see comments/responses inline.

On Tue, Sep 09, 2014 at 11:33:10PM +0000, Acee Lindem (acee) wrote:
| 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. 

main reason is to spare the controllers the need of alwys requiring to understand two protocols.
AI: i'll add a note.

|   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.

we have defined opaque containers for the document lag between defining

1) a new IGP extension
2) the BGP extension being published

it is expected that those opaque carriers are only used
in vendor private extensions.
AI: i'll add a note

|   3. The draft is based mainly on ISIS encoding and does a poor job of representing the OSPF. Examples include: 

the draft is a "protocol neutral" representation of node/links and prefixes.
wherever possible we have put in reference to the message format
of the original IS-IS spec as we found it generally easier to read (sorry acee).
there is no point of adding a second pointer to the relvant OSPF spec.
as sometimes the format of those OSPF-TLVs differs from IS-IS

|     A. Page 10 - There is no protocol-id for OSPFv3. 

AI: i'll add a protocol code for it.

|     B. Page 11 - Why is RFC 6822 normative and RFC 6549 informational? 

AI: i'll move it into normative.

|     C. Psuedonode Representation - The absence of a condensed format for the pseudonode following the OSPF model.

AI: i'll add an OSPF example after section 3.6.

|     D. Page 15 - Relevant OSPF RFCs should be referenced for TLV code points.

there is no single OSPF RFC representing the information which is encoded here.
again - this is not a lets wrap OSPF and IS-IS spec - it is a protocol
neutral representation of nodes, links and prefixes - if the BGP-LS
message format is identical to IS-IS we have picked IS_IS as a reference.

|     E. Page 18 - Why an ISIS Area identifier and not an OSPF Area identifier?

there is - see TLV 514
AI: i'll rename 514 as 'OSPF Area-ID'

|     F. Page 18 - 'E' is for an ASBR and 'B' is for ABR.

AI: change the name but keep the bit value.

|     G. Page 19 - RFC 5642 is the OSPF Node Name RFC.

see answer to comment 3).

|     H. Page 21 - Should be references to OSPF RFC, RFC 3630, RFC 4203, and RFC 5329. 

see answer to comment 3).

|     I. Page 22 - OSPF Link metrics are 2 bytes but OSPF prefix metrics are 3 bytes.

thats why the 'IGP metric' is variable length.

|     J. Page 25 - OSPF Prefix Options are defined in RFC 5340, A.4.1.1. It not clear which need to be advertised. 

good point - 
AI: add a reference to rfc5340 and copy teh flags descriptions

|     K. Page 26 - Forwarding Address for OSPFv3 should reference RFC 5340 as well.

AI: add reference

|   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? 

there is no limit to a single MT-ID, the provided references as well
as the TLV siziing (N* ...) indicate that this is a variable
length TLV.

AI: add text to say that this TLV is used to advertise memebership in 'one or more' 
    topologies.

| Minor Issues:
|   1. Figures and tables are referenced by number, yet those figures and tables are not numbered.  

thats an artifact of xml2rfc on mac - i'll render the next version under unix which has gotten it right.

|   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. 

AI: let me fix that

|   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. 

we did want to lock the codepoint as some are mocking with BGP-LS as an NNI protocol 
for optical. - 

|   4. Page 11 - The BGP-LS Identifier is referenced before it is defined. 

AI: add a forward reference in section 3.2.1.4

|   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? 

AI: add clarification text that the BGP-NH serves solely the purpose of BGP path tie-breaking
    based on IGP distance.

|   6. Page 18 - Why isn't the IS-IS Area Identifier applicable to prefixes? OSPF can scope prefixes to areas (unless they AS-External). 

different schemas - in IS-IS an Area is an attribute of a node, vs. in OSPF its an attribute of an interface.

|   7. For FQDN node/link name recommendation - should usage dictate "RECOMMENDED" rather than "recommended”?

AI: RECOMMENDE

|   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. 

thats use when the BGP-LS data are not generated by redistibution of an LSDB or TED but
rather is generated 'direct' (using protocol code 'direct') - i.e. every node
ina an IGP domain becomes a publisher of its local link-state data.

AI: add a note that this only applies for generation of using protocol 'direct'

| 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 
|