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

Chongfeng Xie <chongfeng.xie@foxmail.com> Fri, 06 September 2024 03:24 UTC

Return-Path: <chongfeng.xie@foxmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116FDC14F738 for <idr@ietfa.amsl.com>; Thu, 5 Sep 2024 20:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.83
X-Spam-Level:
X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE9KpgUH4tZB for <idr@ietfa.amsl.com>; Thu, 5 Sep 2024 20:24:21 -0700 (PDT)
Received: from out162-62-57-252.mail.qq.com (out162-62-57-252.mail.qq.com [162.62.57.252]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A9CC14F711 for <idr@ietf.org>; Thu, 5 Sep 2024 20:24:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1725593049; bh=KND7bWOQ2PCug1UGD8SeEWUQRxLcVi/xyitNpwKK5fE=; h=Date:From:To:Cc:Subject:References; b=CQGOCAN20jC4SPGu47IVm7Xe+ffm/NkMSGhqfjVDnjBYPnQfy6q+YCwSTkEvHaYQq 1dWtL3gxiW55fTYIzvo2cH9LMz7l03+HePVNOFRW30//Tlb61KaYxUbfVlQhLaYpNf jeHb3xHO+hiYtMHs6rTUa+YTitvC2FCroGA9Ujz4=
Received: from LAPTOP-BOBOCIFS ([124.127.72.50]) by newxmesmtplogicsvrszc5-2.qq.com (NewEsmtp) with SMTP id 60418CA1; Fri, 06 Sep 2024 11:24:04 +0800
X-QQ-mid: xmsmtpt1725593044ti371lefx
Message-ID: <tencent_1D158580F92AD7E180641CD86676B10D9508@qq.com>
X-QQ-XMAILINFO: NMGzQWUSIfvTV1H01rwyS5yO4pJBoDvoSk5u9hUIbIFWelZRwJ56TGlYvFA+Ap L+wszKvVTJjDgDs2lLYE7e//2XdPN19GFBQeigWTaxkppK1OkEgpK1DNoDJv5twX0kovJxUVCkHe f/7OluCGJT/J0MQ6I8HhpjeGAtcbtF39RbAWOMEWiCvYuTAy+VFVz7KRjh+jmvE4AfPicUWQ4Oq6 xnu1GA7Zr134YXy68vHOsi9XuXs/00f5ToyWOxyAwZDCS+tfNkzztO/jWZ9MCr7h49DdkUONipDa HhfsE9wbD27O2emqKwjK8mCAMLF/dfxr1GZNqLEmH9g4oNCmasiWsUlazobs3KWCwDpgA6Lb/CuR 3rTMiuf4bPta0VMoQnBu7pWzwYagwiNTGNFCjK+AtQp0oQhF6n2vGRzhhkV/p8Hi0dqT+pY75fit Q+WyT4cSvgDAGwgdKFXqD7Yodm/9WRGJNWrjWx0BNSBGAaMA/3SCDUtqXVRL972Vu9bZjJCCV5xI zxZl0PTahQEUORN5hRJV5lU1hu99D1sXP9mMdBYqsH4BYUH3pk0ogLLSErnZrV2wpwkf8psh2SMD 4Lp2dHxf9MXxgcpAqpb2WgubdihNhICmg3EYcMjqHO0/Zz0m+h0KtOB4ZxOYKzn3lXPrExwi7y+t bexdccHuT/t4QaBrL9Hel5tJtsMNMX3VpJyZwWegws47Qpx51UcTs0DeXm5w/mZ+rSOJwfAnDQLQ Huxhkr4epqwQdW2HMenNX3hnvwVcb3zuKuBgwvogrzroJgRQghc/0PU5EzlyPsCFcN5wFFETqPZJ 9ZflcPs6U7NffDMDk6QCTQQidZjuJU1oVOty8f0u36OHlh3VndVxXHEVs+70fwHdo27Mr7g9chKb qFvykZjpbS0zwUi6t+zYevPeALjrZ/2D677lAJPaDXPwV5Z1ozTKARLlBmEBa1jtQgVislD0PdaH IStyqgSFrlZRLLm3jJULup3dTO89tWn+Xymkx/OnEn6y6iOANggZ6mG6cRLQ65Eesyov2/j4J9FH /nqzhBhQ==
X-QQ-XMRINFO: OWPUhxQsoeAVDbp3OJHYyFg=
Date: Fri, 06 Sep 2024 11:24:04 +0800
From: Chongfeng Xie <chongfeng.xie@foxmail.com>
To: adrian <adrian@olddog.co.uk>
References: <tencent_EE8B429FFCBAEB53C0370E2FB39F58BA4A07@qq.com>, <081f01daff02$f5b50670$e11f1350$@olddog.co.uk>
X-Priority: 3
X-GUID: 4B656D9F-8A11-4288-9054-92EBA2E5BB49
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.306[cn]
Mime-Version: 1.0
X-OQ-MSGID: <202409061124028692882@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart654372864205_=----"
Message-ID-Hash: 3QBZ5DODNHHSFYTPWRX2J7NC3I5BDZ6U
X-Message-ID-Hash: 3QBZ5DODNHHSFYTPWRX2J7NC3I5BDZ6U
X-MailFrom: chongfeng.xie@foxmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: idr <idr@ietf.org>, Susan Hares <shares@ndzh.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: Fw: I-D Action: draft-ietf-idr-bgpls-sr-vtn-mt-05.txt
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kro3uc3dz1bp9tFjGuXwyFqfOMA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Adrian,
Thank you very much for your review and revision suggestions, which will be addressed in the next version soon.

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.
 
s/global/globally/
 
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 <chongfeng.xie@foxmail.com> 
Sent: 04 September 2024 10:45
To: idr <idr@ietf.org>; Susan Hares <shares@ndzh.com>
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: i-d-announce@ietf.org
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 -- idr@ietf.org
To unsubscribe send an email to idr-leave@ietf.org