[Idr] Re: Fw: I-D Action: draft-ietf-idr-bgpls-sr-vtn-mt-05.txt

[Chongfeng Xie <[e-mail]>]

Hi Adrian and all,

Based on the comments of Adrian, a new version of draft-ietf-idr-bgpls-sr-vtn-mt has been submitted, we authors express our sincere thanks to Adrian for his careful review and valuable suggestions. Regarding to the comments raised, most of them have been incoporated into the new version.  For just one comments below, we changed "MAY" into "may", since we think the case is not within the scope of this document, so we can not use "MUST" in this draft, which is informational.
 
We are looking forward to receiving more comments and suggestions.

2.2 has...
 
   In network scenarios where consistent usage of MT-ID among multiple
   domains can not be achieved, a global-significant identifier MAY be
   introduced to identify the inter-domain topology of an NRP.  Within
   each domain, the MT based mechanism could be reused for intra-domain
   topology advertisement.  The detailed mechanism is out of the scope
   of this document.

Working on this "MAY" I wonder why it is only a MAY. Surely, if you
don't use a globally-significant identifier then there is likely to be
a clash of identifiers and things will go badly wrong. So this looks
like at least a "SHOULD" but probably a "MUST".


Best regards
Chongfeng
 
From: Adrian Farrel
Date: 2024-09-05 03:45
To: 'Chongfeng Xie'
CC: 'idr'; 'Susan Hares'
Subject: RE: [Idr] Fw: I-D Action: draft-ietf-idr-bgpls-sr-vtn-mt-05.txt
Hi Chongfeng,
 
Thanks for the reminder to perform a late-stage review.
 
Here are some various minor comments to improve the work.
 
Best,
Adrian
 
===
 
I think BGP-LS needs to be expanded in the Abstract.
 
---
 
Abstract and 1.
 
s/Enhanced VPN requires/Enhanced VPNs require/
 
---
 
1.
 
s/Network slice is considered/A network slice is considered/
 
---
 
Page 3 para 2
 
Expand SID on first use (moving it up 4 lines.
 
---
 
Page 3 para 3
 
You should expand BGP-LS on first use and also include a reference to
RFC 9552 (moving the latter up from the following paragraph).
 
---
 
1.
 
Expand TE on first use.
 
---
 
2.
 
s/Multi-topology/Multi-Topology/
 
---
 
2.1
 
Some nits of English.
More importantly, the "MAY" in this text is inherited from 9552 and
does not form part of the procedures defined in this draft. So...
 
 
OLD
   In section 4.2.2.1 of [RFC9552], Multi-Topology Identifier (MT-ID)
   TLV is defined, which can contain one or more IS-IS or OSPF Multi-
   Topology IDs.  The MT-ID TLV MAY be present in a Link Descriptor, a
   Prefix Descriptor, or the BGP-LS Attribute of a Node NLRI.
NEW
   Section 4.2.2.1 of [RFC9552] defines the Multi-Topology Identifier 
   (MT-ID) TLV, which can contain one or more IS-IS or OSPF Multi-
   Topology IDs.  According to [RFC9552] the MT-ID TLV may be present in
   a Link Descriptor, a Prefix Descriptor, or the BGP-LS Attribute of a 
   Node Network Layer Reachability Information (NLRI).
END
 
---
 
2.1
 
s/used with SR-MPLS data/used with an SR-MPLS data/
s/used with SRv6 data plane/used with an SRv6 data plane/
 
---
 
2.1
 
Adj-SID and SRv6 need to be expanded on first use.
 
---
 
2.1
 
You have "Node NLRI" but "prefix NLRI" and "link NLRI". Should the
capitalisation be consistent?
 
---
 
2.2
 
s/defines the BGP-LS extensions/define the BGP-LS extensions/
s/with different set of/with different sets of/
 
---
 
2.2 has
 
   In some network scenarios, there are needs to create NRPs which span
   multiple ASes.
 
This is unproven. Either give an example (short sentence) or provide a 
reference.
 
---
 
2.2
 
Expand EBGP on first use.
 
---
 
2.2
 
OLD
      In this case, different underlying links can be
      used for different inter-domain NRPs which requires link isolation
      between each other.
NEW
      In this case, different underlying links can be
      used for different inter-domain NRPs, which requires the links to
      be isolated from each other.
END
 
---
 
2.2
 
s/End.X SID need to be/End.X SIDs need to be/
s/of the NRP need to be/of the NRP needs to be/   (three times)
s/different set of peering/different sets of peering/
 
---
 
2.2 has...
 
   *  At the AS-level topology, different inter-domain NRPs may have
      different inter-AS connectivity.  Then different BGP Peer Set SIDs
      MAY be allocated to represent the groups of BGP peers which can be
      used for load-balancing in each inter-domain NRP.  
 
I am trying to parse this "MAY". I think that is applies to the "may" in
the previous sentence, but that whenever the "may" is met, the "MAY" is
actually a "MUST". I suggest...
 
   *  At the AS-level topology, different inter-domain NRPs may have
      different inter-AS connectivity.  In this case, different BGP Peer
      Set SIDs are allocated to represent the groups of BGP peers which
      can be used for load-balancing in each inter-domain NRP.
 
---
 
2.2 has...
 
   In network scenarios where consistent usage of MT-ID among multiple
   domains can not be achieved, a global-significant identifier MAY be
   introduced to identify the inter-domain topology of an NRP.  Within
   each domain, the MT based mechanism could be reused for intra-domain
   topology advertisement.  The detailed mechanism is out of the scope
   of this document.

 
Working on this "MAY" I wonder why it is only a MAY. Surely, if you 
don't use a globally-significant identifier then there is likely to be
a clash of identifiers and things will go badly wrong. So this looks
like at least a "SHOULD" but probably a "MUST".
 
From: Chongfeng Xie <[e-mail]> 
Sent: 04 September 2024 10:45
To: idr <[e-mail]>; Susan Hares <[e-mail]>
Subject: [Idr] Fw: I-D Action: draft-ietf-idr-bgpls-sr-vtn-mt-05.txt
 
Hi folks,
 
A new version of draft-ietf-idr-bgpls-sr-vtn-mt has been submitted, with it we made some editorial changes based on Sue's suggestions. 
If you have any further comments, please feel free to let me know. Thanks.
 
Best regards
Chongfeng
 
 
 
From: internet-drafts
Date: 2024-09-04 17:01
To: [e-mail]
CC: idr
Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-sr-vtn-mt-05.txt
Internet-Draft draft-ietf-idr-bgpls-sr-vtn-mt-05.txt is now available. It is a
work item of the Inter-Domain Routing (IDR) WG of the IETF.
 
   Title:   Applicability of BGP-LS with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRP)
   Authors: Chongfeng Xie
            Cong Li
            Jie Dong
            Zhenbin Li
   Name:    draft-ietf-idr-bgpls-sr-vtn-mt-05.txt
   Pages:   10
   Dates:   2024-09-04
 
Abstract:
 
   Enhanced VPNs aim to deliver VPN services with enhanced
   characteristics to customers who have specific requirements on their
   connectivity, such as guaranteed resources, latency, or jitter.
   Enhanced VPN requires integration between the overlay VPN
   connectivity and the characteristics provided by the underlay
   network.  A Network Resource Partition (NRP) is a subset of the
   network resources and associated policies on each of a connected set
   of links in the underlay network.  An NRP could be used as the
   underlay to support one or a group of enhanced VPN services.
 
   When Segment Routing is used as the data plane of NRPs, each NRP can
   be allocated with a group of Segment Identifiers (SIDs) to identify
   the topology and resource attributes of network segments in the NRP.
   The association between the network topology, the network resource
   attributes and the SR SIDs may need to be distributed to a
   centralized network controller.  In some network scenarios, each NRP
   can be associated with a unique logical network topology.  This
   document describes a mechanism to distribute the information of SR
   based NRPs using BGP-LS with Multi-Topology (MT).
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-sr-vtn-mt/
 
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-sr-vtn-mt-05
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgpls-sr-vtn-mt-05
 
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
 
 
_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]