[Idr] FW: draft-ietf-idr-bgpls-sr-vtn-mt-10 - Review

[Susan Hares <[e-mail]>]

Updating the IDR list with Keyur’s comments and authors’ response.  This will be updated in the Shepherd’s list.

Sue Hares
(IDR shepherd)

From: [e-mail] <[e-mail]>
Sent: Sunday, June 8, 2025 11:14 PM
To: keyur <[e-mail]>; idr-chairs <[e-mail]>
Cc: Susan Hares <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; lizhenbin <[e-mail]>; Li Cong <[e-mail]>
Subject: Re: draft-ietf-idr-bgpls-sr-vtn-mt-10 - Review

Hi Keyur, Thank you again for your comments, please see my feedback inline[Chongfeng]  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzE4NGM5OGJlYzVjOGI1NWFlOGJmZmM0YTE3YjBmYTk2LzE3NDk0Mzg4MzguODA2MTEzNw==#key=f3dc410a342cdc0f00415c25e684e00e>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


Hi Keyur,

Thank you again for your comments, please see my feedback inline[Chongfeng]


From: 【外部账号】Keyur Patel<mailto:[e-mail]>
Date: 2025-06-06 02:54
To: [e-mail]<mailto:[e-mail]>; idr-chairs<mailto:[e-mail]>
Subject: draft-ietf-idr-bgpls-sr-vtn-mt-10 - Review
Hi Authors,

Had a chance to review the document. Got few comments:


1.      Section 1:
<snip>
An NRP could be used as the
   underlay to meet the requirement of one or a group of enhanced VPN
   services.  To meet the requirement of enhanced VPN services, a number
   of NRPs can be created, each with a subset of network resources
   allocated on network nodes and links in a customized topology of the
   physical network.
</snip>
Consider:
An NRP could be used as the
   underlay to meet the requirement of one or a group of enhanced VPN
   services.  To meet the requirement of enhanced VPN services, a number
   of NRPs can be created, each with a subset of network resources
   allocated on network nodes and links in a customized topology of the
   physical network. An exact mechanism to map NRP to one or group of enhanced VPN
services are outside the scope of this document.

  [Chongfeng] Thanks for the proposed text. My suggestion is to make a little change to the last sentence:
       The exact mechanism to map one or group of enhanced VPN services to a specific NRP is outside the scope of this document.

2. Do you need to worry about enforcing mechanism for Network Resource Partitioning or is that outside the scope of this document?
[Chongfeng] The enforcing mechanism for NRP is outside the scope of this document. We can clarify this in next revision.

3. Section 2.1: Do you envision the case where a given NRP supports multiple fabrics (SRv6 and SR MPLS)?
[Chongfeng] Good question, it is considered that in each domain, one data plane mechanism is selected for an specific NRP. In different domains, different data plane may be used for an inter-domain NRP. We can add some text to make this clearer.

4.  Section 2.2: I think your referring to an ebgp case where these domains are under a common administration? Is that correct? If so, can you explicitly call it out in second paragraph?

[Chongfeng] Yes, these domains should be under a common administration, or they belong to the same trusted domain as specified in section 8 of RFC 8402.

5. Section 3: Last Paragraph: What is the guidance when the max bandwidth is exceeded? Is that out of scope for this doc? If so, can we call it out? Also, what exactly does the “advertisement of other TE    attributes in BGP-LS for NRP is for further study” mean? [cid:_Foxmail.1@1be7d018-a565-0090-12dd-a750f5f58cde] Any error handling needs to be done or an implementation should silently ignore them.

[Chongfeng] To my understanding BGP-LS is just to report the information of the NRPs to the network controller, the validation of the information is done by the controller and is out of the scope of BGP-LS mechanism. As for the advertisement of other TE attributes, as they are based on existing TLVs, the advertisement and reception should be allowed, and the error handling in BGP-LS is the same as those defined in RFC 9552, while the usage of such information is out of the scope of BGP-LS.

 If you are OK with the above replies, we will produce a new revision with the corresponding changes this week.

Many thanks,

Chongfeng


Best Regards,
Keyur