Subject: Re: [Idr] Routing Directorate Review of draft-ietf-idr-ls-distribution-05.txt (Reply to this one)

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 11 Sep 2014 17:58:34 +0000

Hi Hannes, 

On 9/10/14, 3:20 AM, "Hannes Gredler" <[email-masked]> wrote:

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

Also, a single representation will enable policy on the receiver.

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

Great. 

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

The example would result in the same BGP LS. My point was that OSPF¹s
Network-LSA representation is significantly more compact and satisfies the
pseudonode requirement.

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

Sure - these should match RFC 2328.

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

That doesn¹t mean the draft should have incorrect information.

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

This was in response to this text:

   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.

However, if you change this, it still doesn¹t solve the satisfy the
requirement of a separate metric per topology for links and prefixes.

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

I don¹t think this is a problem with mac - it is just a tcl script. So,
unless you have a very old Xcode package installed and there is a tcl bug,
it is should not be a problem. You can download the latest version of
xml2rfc though. 

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

Then you should add a registry for the protocol IDs. Since this is a new
field, you don¹t have to worry about others assigning values.

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

But above you said you were going to make this an OSPF Area ID TLV?

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

Ok

Thanks,
Acee 

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