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

[Aijun Wang <[e-mail]>]

Hi, Sue:

 

Thanks for your careful review and concrete suggestions!

I have updated the document and uploaded the version 16 to the IETF
repository:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology
-ext-16

 

Please check whether there is still other issues that needs to be solved
before the early allocation and WGLC.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

发件人: [e-mail] [mailto:[e-mail]]
代表 Susan Hares
发送时间: 2024年5月31日 19:43
收件人: [e-mail]
抄送: [e-mail]
主题: [Idr] Shepherd's Review of
draft-ietf-idr-bgpls-inter-as-topology-ext-15 for Early Allocation

 

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./ 
【WAJ】Done

 

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./
【WAJ】Done
 

 

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./ 
【WAJ】Done

 

 

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.

   /

【WAJ】Done

 

 

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.  

   /

【WAJ】Done

 

 

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./
【WAJ】Done
 
 
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? 
  【WAJ】: section 5.2.1.2 is enough, has included the referenced section
information.
 
   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.” 
  【WAJ】No. For the stub link NLRI, the above check should be omitted.  I
have updated the related descriptions as that you suggested in the below.
 
   Question about Prefix Descriptors: What Prefixes Descriptors are you
allowing? 
   You do not define a prefix descriptor in the NLRI.   
【WAJ】Remove the related prefix descriptors.
 
   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). 
 【WAJ】Done
   
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./  
  【WAJ】Done, omit the “Operation:” in the begin of the sentence.
 
    
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./ 
 【WAJ】Done
 
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./ 
【WAJ】Done
 
 
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. 
【WAJ】Done
 
 
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. 

【WAJ】Done。Start from TBD1 for newly defined NLRI type(Stub Link NLRI) 

 

 

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./ 
【WAJ】Done 
 

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.
【WAJ】Done 
 
 
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./
 【WAJ】Done 

 

 

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

 【WAJ】Done

 

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

  【WAJ】Done