[Idr] Shepherd's Review of draft-ietf-idr-bgpls-inter-as-topology-ext-15 for Early Allocation

[Susan Hares <[e-mail]>]

Aijun:

Thank you for your kind patience with my processing of Early Allocation requests.

The review notes sections in the draft and reasons for change.  In making changes to your document:

  *   You MUST address the technical changes and questions prior to submission for
  *   You SHOULD address the editorial changes.
  *   The bold text in any section marked “New text” should be removed prior to insertion

This review is lengthy because the IANA Expert reviews for BGP-LS prior to early allocation require a document that is “nearly” ready for WG LC.

I will be glad to review your text again as soon as you submit a -16.  Just send me a note when you submit the draft.

Sue

=============
Item 1:  Introduction
Type: Technical
Reason: Technical clarity on what is being defined.
Old text:

   This document describes the process to build Border Gateway Protocol-

   Link State (BGP-LS) key parameters in inter-domain scenario, defines

   one new BGP-LS Network Layer Reachability Information (NLRI) type

   (Stub Link NLRI) and some new Type-Length-Values (TLVs) for BGP-LS to

   let Software Definition Network (SDN) controller retrieve the network

   topology automatically under various inter-AS environments.

New text:/

   This document describes the process to distribute Border Gateway Protocol-

   Link State (BGP-LS) key parameters for inter-domain links between two

   Autonomous Systems.  This document defines a new type within the

   BGP-LS NLRI for a Stub Link and three new type-length-values (TLVs) for

   BGP-LS Link descriptor.  These additions to BGP-LS let

   Software Definition Network (SDN) controllers retrieve the network

   topology automatically under various inter-AS environments./

Item 2: Section 1, Introduction, paragraph 2

Type technical:  You really mean RFC9086 rather than another draft.

Old text:/

   Draft [RFC9086] defines some extensions for exporting BGP peering

   node topology information (including its peers, interfaces and

   peering ASs) in a way that is exploitable in order to compute

   efficient BGP Peering Engineering policies and strategies./



New text:/

   [RFC9086] defines some extensions for exporting BGP peering

   node topology information (including its peers, interfaces and

   peering ASs) in a way that is exploitable in order to compute

   efficient BGP Peering Engineering policies and strategies./

Item 3: Section 1, paragraph 3,
Status: Technical
Current  text:/

   This draft analysis the situations that the SDN controller needs to

   get the interconnected topology information between different AS

   domains, defines the new Stub Link NLRI and some new TLVs within the

   BGP-LS protocol to transfer the key information related to them./



New text:

   This draft analyzes the situations during which the SDN controller needs to

   get the interconnected topology information between different AS

   domains. After describing these situations, this draft

   defines a new Stub Link type within the BGP-LS NLRI [RFC9552]to describe the

   Iner-AS link and some new TLVs for that new BGP-LS type./


Item 4: Section 5, paragraph 1
Reason:  The four types are 4 types within the BGP-LS Link
Note: Change is bolded in text below.
Old text:/
   [RFC9552] defines four NLRI types(Node NLRI, Link NLRI, IPv4 Topology
   Prefix NLRI, IPv6 Topology Prefix NLRI) to transfer the topology and
   prefix information.  For inter-as link, the two ends of the link
   locates in different IGP domains, then it is not appropriate to
   transfer their information within the current defined NLRI types./

New text:/
   [RFC9552] defines four types within the BGP Link-State NLRI
   (Node NLRI, Link NLRI, IPv4 Topology Prefix NLRI,
   and IPv6 Topology Prefix NLRI) to transfer the topology and
   prefix information.  For inter-as link, the two ends of the link
   exist in different IGP domains, so it is not appropriate to
   transfer their information within the current defined NLRI types.
   /


Item 5: Section 5 paragraph 2

   Reason:  The new type is a new type within the BGP-LS NLRI

   Old text:/

   This draft defines one new NLRI type, called Stub Link NLRI, which is

   coded as the following format:/


  New text:/

   This draft defines one new NLRI type within the BGP Link-State (BGP-LS)

   NLRI, called the Stub link NLRI.  The Stub link NLRI is encoded in the format

   shown in Figure 2 and explained below.
   /

Item 6: Section 5, paragraph 3

   Reason: Please give specific reference for RFC9952


   Old text:/

   The "Protocol-ID" should be set to the value that indicates the

   source protocol of the stub link information, as indicated in

   [RFC9552]/

  New text:/

   "Protocol-ID": should be set to the value that indicates the

   source protocol of the stub link information, as indicated in

   [RFC9552] in section 5.2./



Item 7: Section 5, paragraph 4



   Reason: Please give specific descriptions of semantics of

   “Local Node Descriptors” and “Stub Link Descriptors in this document.



   Question about Local Node Descriptors: RFC9552 has a “Local node Descriptor”

   in RFC9552 in section 5.2.1.2. Are you restricting your definition for

   local node descriptors to descriptions in RFC9552 section 5.2.1?



   Question about Link Descriptors: Are you adhering to all of the Link Descriptors

   Requirements in RFC9952.  For example, are you adhering to this requirement from

   RFC9552 section 5.2.2:



   “A link between two nodes is not considered as complete (or available)

   unless it is described by the two Link NLRIs corresponding to the

   half-link representation from the pair of anchor nodes.  This check

   is similar to the 'two-way connectivity check' that is performed by

   link-state IGPs.”



   Question about Prefix Descriptors: What Prefixes Descriptors are you allowing?

   You do not define a prefix descriptor in the NLRI.



   Old text for Local node and Stub link :/

   The semantics of "Local Node Descriptors" and "Stub Link Descriptors"

   are same as that defined in [RFC9552] for "Node Descriptors" and

   "Link Descriptor".



   New text-1:/

   Local Node descriptors: define the ASBRs that are attached to the

   Inter-AS stub link, and use the RFC9552 “Local Node Descriptor”

   in section 5.2.1.4. The following Node Descriptor SubTLVs from

   [RFC9952] are valid for inclusion in the local Node descriptor:

   AS system, OSPF Area-ID, IGP Router-ID. /



   Stub Link Descriptors: define the Stub link which has only one end

   Located in the IGP domain using the RFC9552 “Link Descriptor definition”

   in section 5.2.2 of RFC9552 with the exceptions noted below.  The

   The Stub link Descriptor supports the inclusion of the following subTLVs:

*         Link/Local Identifier  (TLV 258, [RFC9552]),

*         IPv4 Interface Address (TLV 259, [RFC9552]),

*         IPv4 Neighbor Address  (TLV 260, [RFC9552]),

*         IPv6 Interface Address (TLV 261, [RFC9552]),

*         IPv6 Neighbor Address  (TLV 262, [RFC9552]),

*         Multi-topology identifier (TLV 263, [RFC9552]),

*         Remote-AS Number (TLV TBD1, [This document], section 7.1),

*         IPv4 Remote ASBR ID [TLV TBD2, [This document], section 7.2), and

*         IPv6 Remote ASBR ID [TLV TBD2, [This document], section 7.3).





Item 8: Section 5, paragraph 4



Old text:/ This newly defined NLRI can be used to describe the link that has

   only one end located within the IGP domain, as described in the

   following sections.  The Node/Link/Prefix Descriptor sub-TLVs and

   Node/Link/Prefix attributes that defined in [RFC9552] can be included

   in the NLRI if necessary.  The interface and neighbor address sub-

   TLVs SHOULD be included in the Local Node Descriptors to

   differentiate the parallel links between two ASBRs./





New text:/

Operation: This newly defined NLRI can be used to describe the link that has

   only one end located within the IGP domain, as described in the

   following sections.  The Node and Link Descriptor sub-TLVs and

   Node and Link attributes that are defined in [RFC9552] can be included

   in the NLRI if necessary.  The interface and neighbor address sub-

   TLVs SHOULD be included in the Local Node Descriptors to

   differentiate the parallel links between two ASBRs./





Item 9: Section 6, paragraph 1

Status: Technical + Editorial

Reason: The sentences must clearly define these values come from IGPs definitions.



Old text:/

   [RFC9346] and [RFC5392] define IS-IS and OSPF extensions respectively

   to deal with the situation for inter-AS link.  Three sub-TLVs(Remote

   AS Number、IPv4 Remote ASBR ID、IPv6 Remote ASBR ID) which are

   associated with the inter-AS link are defined./



New text:/

   [RFC9346] and [RFC5392] define IS-IS and OSPF extensions respectively

   to deal with the reasons for reporting inter-AS links.  Three sub-TLVs

   relating to Inter-Domain Links (Remote AS Number、IPv4 Remote ASBR ID、

   and IPv6 Remote ASBR ID) are defined in these documents./





Item 10: Section 6, paragraph 2-3

Status: Technical

Reason: It needs to be clear that the Local Descriptors are in the new NLRI type in the BGP-LS NLRI



Old text:/

   These TLVs are flooded within the IGP domain automatically.  They

   should be carried within the newly defined Stub Link NLRI within the

   BGP-LS protocol, as the descriptors for the inter-AS stub link.



   The "Local Node Descriptors" should describe the the characteristics

   of ASBRs that are connected these inter-AS links./



New text:/

   These IGP TLVs are flooded within the IGP domain automatically.  This

   document specifies that these MAY also be carried within the newly

   defined Stub Link NLRI within the BGP-LS protocol, as the descriptors

   for the inter-AS stub link.



   The "Local Node Descriptors" in the Stub Link NLRI within the BGP-LS NLRI

   should describe the characteristics of ASBRs that are connected across

   the inter-AS links./





Item 11: Section 7, paragraph 1

Status: Technical, IANA allocations

Reason:  It must be clear that the Stub Link NLRI is within the BGP-LS NLRI.



   This section proposes to add three new TLVs to be supported in

   the Stub Link NLRI in the BGP-LS NLRI. These new TLVs allow BGP-LS

   to transfer inter-AS information gathered by the SDN controller.





Item 12: Section 7, chart 1





   +-----------+---------------------+--------------+----------------+

   |  TLV Code | Description         |IS-IS/OSPF TLV| Reference      |

   |   Point   |                     |   /Sub-TLV   | (RFC/Section)  |

   +-----------+---------------------+--------------+----------------+

   |    TBD1   |Remote AS Number     |   24/21      | [RFC9346]/3.3.1|

   |           |                     |              | [RFC5392]/3.3.1|

   |    TBD2   |IPv4 Remote ASBR ID  |   25/22      | [RFC9346]/3.3.2|

   |           |                     |              | [RFC5392]/3.3.2|

   |    TBD3   |IPv6 Remote ASBR ID  |   26/24      | [RFC9346]/3.3.3|

   |           |                     |              | [RFC5392]/3.3.3|

   +-----------+---------------------+--------------+----------------+




Note: You must uniquely specify each IANA value to be assigned.

Item 13: Section 7.1
Reason: Technical, IANA allocations require a specific identification (TBD1)

Old text:/

   The remote AS number TLV is TLV type TBD (see Section 10 ) and is 4

   octets in length.  /

New text:

   /The remote AS number TLV is TLV type TBD1 (see Section 10 ) and is 4

   octets in length./


Item 14: Section 7.2
Reason: Technical, IANA allocations require a specific identification (TBD2)

Old text:/

   The IPv4 remote ASBR ID TLV is TLV type TBD (see Section 10) and is 4

   octets in length.

New text:

   The IPv4 remote ASBR ID TLV is TLV type TBD2 (see Section 10) and is 4

   octets in length.



Item 15: Section  7.3
Reason: Technical, IANA allocations require a specific identification (TBD3)



Old text:

/  The IPv6 remote ASBR ID TLV is TLV type TBD (see Section 10) and is

   16 octets in length./



New text:

Old text:

/  The IPv6 remote ASBR ID TLV is TLV type TBD3 (see Section 10) and is

   16 octets in length./


Item 15: Section 8
Reason: Technical, Clarity in method

Old text:/

   When SDN controller gets such information from BGP-LS protocol, it

   should find the corresponding associated router information, build

   the link between these two border routers.  After iterating the above

   procedures for all of the stub links, the SDN controller can then

   retrieve the connection topology between different domains

   automatically./



New text:/

   When SDN controller gets such information from BGP-LS protocol, it

   should find information from the associated router.  Based on this

   information it can create a logical topology that contains

   the link between these two border routers.



   Iterating the above procedures for all of the stub links, the SDN

   controller can automatically retrieve the Inter-AS connection topology./

Item 16: Section 9



9.  Security Considerations



Old text:/

   It is common for one operator to occupy several IGP domains that are

   composited by its backbone network and several MAN(Metrio-Area-

   Network)s/Internet Data Centers (IDCs).  When they do traffic

   engineering which spans MAN, Backbone and IDC, they need to know the

   inter-as topology via the process described in this draft.  Using the

   passive interface features or configuring the Traffic Engineering

   (TE) parameters on the interconnect links will not spread the

   topology fluctuation across each other domain./



New text:/



   BGP-LS security is described in [RFC9552].



   This addition to BGP-LS focuses on the case when

   one network operated by a single entity has several IGP domains that are

   composited by its backbone network and several MANs (Metro-Area-

   Networks) and Internet Data Centers (IDCs).  The configuration of these

   networks operated by the single administrative entity creates a “walled garden”.



   Within this single Administrative Domain, the network operator needs to

   monitor and engineer traffic flows that traverse such a network

   that spans multiple Autonomous Systems. The network operators can obtain this

   information on inter-as topology via the process described in this draft.



   Using the passive-interface features or configuring the Traffic Engineering

   (TE) parameters on the interconnect links will not provide the real-time

   Information for this single Administrative Domain. /