[Idr] Re: Mohamed Boucadair's Discuss on draft-ietf-idr-bgpls-sr-vtn-mt-12: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Chongfeng,

Indeed, some NRP context in the introduction section (including the 1:1
with MT) is good to have. I let the authors pick the "minimal" thing and
point to draft-ietf-spring-sr-for-enhanced-vpn where everything can be
explained in full detail (as it is already done today).

But let us please wait to hear from Med if that would address his concerns
and enable him to clear his DISCUSS position.

Thanks,
Ketan


On Thu, Oct 9, 2025 at 3:08 PM Chongfeng Xie <[e-mail]> wrote:

>
> Hi Ketan,
>
> We authors agree to revise this draft according to your suggestions, thank
> you for raising them.
>
> In addition, considering that the application of MT in this draft is NRP
> scenario specific and different from traditional MT deployment, it needs to
> consider the resource (e.g. bandwidth) information of each topology, while
> traditional MT deployment does not need to consider resource information..
> Therefore, we suggest that this draft keep some NRP-related background
> information at the beginning. Do you think it is ok?
>
> Best regards
> Chongfeng
>
>
>
>
> *From:* 【外部账号】Ketan Talaulikar <[e-mail]>
> *Date:* 2025-10-09 01:07
> *To:* Chongfeng Xie <[e-mail]>
> *CC:* [e-mail]; IESG <[e-mail]>;
> [e-mail]; idr-chairs <[e-mail]>;
> idr <[e-mail]>; Susan Hares <[e-mail]>
> *Subject:* Re: RE: [Idr] Mohamed Boucadair's Discuss on
> draft-ietf-idr-bgpls-sr-vtn-mt-12: (with DISCUSS and COMMENT)
> Hi Med and Authors,
>
> I am top posting here in an effort to try and move this discussion forward.
>
> At its very core, the document in section 2 is describing the following:
> 1) Section 2.1 describes how MT specific SR information (such as SR-MPLS
> and SRv6 SIDs) can be conveyed via BGP-LS. It is tying together things from
> RFC9552 (base) and RFCs 9085/9514 which may or may not be obvious.
> 2) Section 2.2 is a new provisioning mechanism that enables extension of
> MT notion across inter-AS links that are not running IGPs by leveraging
> BGP-EPE. Along with this comes the SR information scoped to that MT.
>
> My sense is (and I may be wrong - so please correct me), there is no
> issue/concern with the above.
>
> The concerns raised by Med are about the NRP related aspects.
> Specifically, if there is a 1:1 relationship between MT and NRP then why is
> the NRP construct required? There are also concerns raised about various
> aspects related to NRP which are described as outside the scope of this
> document.
>
> Now, as clarified by Chongfeng, I had raised this point about this
> document trying to cover things that are outside the scope of typical
> BGP-LS documents where there is no description of the consumer/usage of the
> information. Refer to point (1) of the AD review [1]. The authors have made
> some changes to trim text and instead reference SPRING WG documents.
>
> I have a concern with adding more text in this BGP-LS document to
> answer/clarify the questions that Med has raised since they are clearly
> outside the scope of this document.
>
> Now,
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-for-enhanced-vpn/
> <https://datatracker.ietf..org/doc/draft-ietf-spring-sr-for-enhanced-vpn/>
> which is an informational SPRING WG document describes how SR-based NRPs
> can be deployed - both where there is a 1:1 relationship between NRP and
> MT, but also NRP and FlexAlgo. Refer [2] that references this document.
>
> Here is a suggestion to progress this document:
> - All the NRP specific details are removed from this document and text
> added as appropriate to the SPRING document [2]. This is in scope/charter
> of SPRING WG since it is an SR-based solution.
> - An informative reference is added in this document to
> draft-ietf-spring-sr-for-enhanced-vpn with some necessary overview text
> related to 1:1 NRP to MT mapping and pointing the reader to the SPRING
> document for more details.
>
> Is that workable?
>
> Thanks,
> Ketan
>
> [1] https://mailarchive.ietf.org/arch/msg/idr/2CqQPLntPKQt7908IAQEauUVvt8/
> [2]
> https://www.ietf.org/archive/id/draft-ietf-spring-sr-for-enhanced-vpn-09.html#section-3.3
> <https://www.ietf..org/archive/id/draft-ietf-spring-sr-for-enhanced-vpn-09.html#section-3.3>
>
>
> On Thu, Sep 25, 2025 at 9:15 AM Chongfeng Xie <[e-mail]>
> wrote:
>
>>
>>
>>
>> Hi Med,
>>
>> Thank you for your further comments, please see my comments
>> inline[Chongfeng-2],
>>
>>
>> *From:* 【外部账号】 <[e-mail]>
>> *Date:* 2025-09-24 21:29
>> *To:* Chongfeng Xie <[e-mail]>; IESG <[e-mail]>
>> *CC:* [e-mail]; idr-chairs
>> <[e-mail]>; idr <[e-mail]>; Susan Hares <[e-mail]>
>> *Subject:* RE: [Idr] Mohamed Boucadair's Discuss on
>> draft-ietf-idr-bgpls-sr-vtn-mt-12: (with DISCUSS and COMMENT)
>>
>> Hi Chongfeng,
>>
>>
>>
>> Thank you for the follow-up.
>>
>>
>>
>> Please see inline.
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>>
>>
>> *De :* Chongfeng Xie <[e-mail]>
>> *Envoyé :* mercredi 24 septembre 2025 10:50
>> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; IESG <
>> [e-mail]>
>> *Cc :* [e-mail]; idr-chairs <
>> [e-mail]>; idr <[e-mail]>; Susan Hares <[e-mail]>
>> *Objet :* Re: [Idr] Mohamed Boucadair's Discuss on
>> draft-ietf-idr-bgpls-sr-vtn-mt-12: (with DISCUSS and COMMENT)
>>
>>
>>
>> *Hi Med,*
>>
>>
>>
>> *Thanks for your review and comments, please see my replies inline with
>> [chongfeng]:*
>>
>>
>>
>>
>>
>> *From:* Mohamed Boucadair via Datatracker <[e-mail]>
>>
>> *Date:* 2025-09-18 21:30
>>
>> *To:* The IESG <[e-mail]>
>>
>> *CC:* draft-ietf-idr-bgpls-sr-vtn-mt
>> <[e-mail]>; idr-chairs
>> <[e-mail]>; idr <[e-mail]>; shares <[e-mail]>
>>
>> *Subject:* [Idr] Mohamed Boucadair's Discuss on
>> draft-ietf-idr-bgpls-sr-vtn-mt-12: (with DISCUSS and COMMENT)
>>
>> Mohamed Boucadair has entered the following ballot position for
>>
>> draft-ietf-idr-bgpls-sr-vtn-mt-12: Discuss
>>
>>
>>
>> When responding, please keep the subject line intact and reply to all
>>
>> email addresses included in the To and CC lines. (Feel free to cut this
>>
>> introductory paragraph, however.)
>>
>>
>>
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-sr-vtn-mt/
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>> DISCUSS:
>>
>> ----------------------------------------------------------------------
>>
>>
>>
>> Hi Chongfeng, Cong, Jie, and Zhenbin,
>>
>>
>>
>> Thank you for the effort put into this specification.
>>
>>
>>
>> Also, thanks to Nagendra Nainar for the OPSDIR review and to the authors
>> for
>>
>> the follow-up.
>>
>>
>>
>> I’m supportive of work that helps/informs deployments and walk through the
>>
>> applicability of some technologies.. However, I’m having some issues that
>> I’d
>>
>> like to DISCUSS.
>>
>>
>>
>> # Why this needs to be published as an RFC? This is especially
>> exacerbated by
>>
>> the 1:1 (NRP:MT-ID) mapping assumption:
>>
>>
>>
>> Section 4:
>>
>>    The mechanism described in this document assumes that each NRP is
>>
>>    associated with an independent topology, and for the inter-domain
>>
>>    NRPs, the MT-IDs used in the involved domains are consistent, so that
>>
>>    the associated MT-ID can be used to identify the NRP in the control
>>
>>    plane.
>>
>>
>>
>> Isn’t then obvious to operate existing tools with such MT ID as input?
>> What
>>
>> operational aspects triggered by the specific NRP case are worth
>> additional
>>
>> considerations to be recorded in an RFC?
>>
>>
>>
>>
>>
>> *[Chongfeng] This document describes the applicability of BGP-LS with MT
>> in the distribution*
>>
>> * of NRP-specific topology and resource information to a network
>> controller. This is different *
>>
>> *from how MT was used in the existing network deployments.*
>>
>>
>>
>> *[Chongfeng] For example, for each MT which is mapped to an NRP, a set of
>> link bandwidth is *
>>
>> *reported as MT-specific link attributes in BGP-LS. *
>>
>>
>>
>> *[Med] My point was: is there anything not straightforward to make use of
>> these tools once we assume that an NRP is mapped to an MT-ID? *
>>
>>
>> *[Chongfeng-2] *In current network deployments, MT is only used to
>> define the customized logical topologies, while there is no resource
>> allocation to a specific topology. When an MT-ID is 1:1 mapped to an NRP,
>> the network resource (e.g. bandwidth) associated with the NRP also needs to
>> be advertised, so that it allows to create multiple NRPs on the same link,
>> each is allocated with a set of network resources. In one word, the usage
>> of MT for NRP is different from its traditional use in operators’
>> networks, we hope this document could be helpful in guiding this new usage.
>>
>>
>>
>>
>>
>> ## What NRP specifics are being discussed in the document? Wouldn’t the
>> same
>>
>> considerations in the draft apply based on MT IDs independent of which
>>
>> “abstraction” instance is bound to an MT ID?
>>
>>
>>
>> I appreciate this is seeking to be published as Informational, however
>> I’m not
>>
>> sure the document includes (any?) matters that are specific to NRPs.
>> Consider,
>>
>> for example, Section 2, can we highlight please what is specific to NRPs?
>>
>> Thanks.
>>
>>
>>
>> *[Chongfeng] During the AD review of this document, it was suggested to
>> simplify the *
>>
>> *introduction and background of NRP in this document, and refer to the
>> relevant *
>>
>> *RFC/draft in TEAS and SPRING WG.*
>>
>>
>>
>> *[Med] Which makes sense as this avoid repeating material already in
>> existing document + focus on key contribution.*
>>
>>
>>
>> *[Chongfeng] Section 2 describes the advertisement of topology
>> information of NRP using*
>>
>> * MT.*
>>
>> *[Med] Agree, these same considerations apply independent of which
>> instance was bound to an MT ID. *
>>
>>
>> *[Chongfeng-2] *We don’t know if there is any other “abstraction”
>> instance that is bound to MT-ID. This document focuses on its applicability
>> for NRP. Section 2 is about the topology information advertisement, for
>> which most of the existing MT mechanisms are applicable, thus the text is
>> brief and refers to the relevant RFCs when possible. Some of the text is
>> about the advertisement of MT-specific SR SIDs, which was not elaborated in
>> the BGP SR extension RFCs. We believe the text in section 2 is necessary
>> for applying the MT mechanisms to the NRP case.
>>
>>
>>
>> *For the report of intra-domain topology, it reuses the existing MT
>> related extensions*
>>
>> * in BGP-LS, and additional considerations is described for the
>> inter-domain NRP case in *
>>
>> *section 2..2. We believe this section provides useful information for
>> the deployment of NRPs*
>>
>> * in the network.*
>>
>>
>>
>> *[Med] The only part which I thought might include some NRP specifics is
>> this one, but these matters are left out of scope.*
>>
>>
>>
>> *CURRENT:*
>>
>>    In network scenarios where consistent allocation of MT-ID among
>>
>>    multiple domains can not be achieved, the MT-ID advertised by the two
>>
>>    peering ASBRs to the controller for the same inter-domain link could
>>
>>    be different.  Some mapping mechanism may be needed by the controller
>>
>>    to match the MT-IDs of an inter-domain link in two directions, and
>>
>>    concatenate the inter-domain topology of the NRP.  The detailed
>>
>>    mechanism is out of the scope of this document.
>>
>>
>>
>> (note that base MT specs in general declare classification matters out of
>> scope. For example, RFC 4915 has the following:
>>
>>
>>
>>        With Multi-Topology routing, the
>>
>>        classification of what type of traffic maps to which topology is
>>
>>        not within the scope of this document.
>>
>>
>>
>> That makes sense for a protocol that is designed for general use. I’m
>> expecting an applicability document to touch on those matters, however).
>>
>>
>>
>> *[Chongfeng-2]* In the targeted scope and scenarios (same
>> administration), it is assumed in most cases the allocation of MT-IDs in
>> the interconnected domains can be coordinated thus consistent. When it is
>> not the case, the mapping of MT-IDs between adjacent domains would be
>> similar to the mapping of other IDs between the network domains, thus in
>> our understanding the operation of such mapping is neither MT-ID specific,
>> nor NRP specific. That said, if you really suggest to provide some more
>> guidance to this case, we can add some text.
>>
>>
>>
>>
>>
>>
>> ## Deviation from RFC 9543
>>
>>
>>
>> I was stopped early in the document with statements such as:
>>
>>
>>
>> CURRENT (abstract):
>>
>>    This document describes how BGP-Link
>>
>>    State (BGP-LS) with Multi-Topology (MT) can be used to distribute the
>>
>>    information of SR based NRPs to the network controller when each NRP
>>
>>                                                                ^^^^^^^^
>>
>>    is associated with a separate logical network topology identified by
>>
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>    a Multi-Topology ID (MT-ID).
>>
>>
>>
>> and then in the Introduction:
>>
>>
>>
>>    In some network scenarios, the required number of NRPs could be
>>
>>    small, each NRP can be associated with an separate logical topology,
>>
>>    i.e., there is 1:1 mapping between an NRP and an Multi-Topology (MT)
>>
>>    ID, and a set of dedicated or shared network resources is allocated
>>
>>    to the NRP..
>>
>>
>>
>> This 1:1 mapping assumption is clearly a simplification and does not
>> reflect
>>
>> how the concept is defined in RFC 9543:
>>
>>
>>
>>    Some NRP realizations may
>>
>>    build NRPs with dedicated topologies, while other realizations may
>>
>>    use a shared topology for multiple NRPs.
>>
>>
>>
>> *[Chongfeng] Yes, this document provides a simplified solution for
>> building NRPs in the network.*
>>
>> * When the number of NRPs required is relatively small, this allows
>> operators to deploy NRPs *
>>
>> *with existing control protocol mechanisms. From the text you quote from
>> RFC 9543, the first half*
>>
>> * of the sentence shows that this is one possible approach in realizing
>> NRPs (with dedicated topologies).*
>>
>>
>>
>>
>>
>> ## If 1:1 (NRP==MT-ID) is assumed here, then a key aspect is how actual
>> NRP
>>
>> resources are identified and bound to a topology ID. However, these
>> matters
>>
>> seem to be out of scope.
>>
>>
>>
>> *[Chongfeng] With the mechanism in this document, the NRP-specific
>> resources are identified*
>>
>> * using MT-specific SR SIDs, based on the mechanism specified in
>> draft-ietf-spring-resource-aware-segments..*
>>
>>  *[Chongfeng] As described in the introduction, what is out of the scope
>> is "the mechanism of enforcing*
>>
>> * NRP resource allocation and the mechanism of mapping one or group of
>> enhanced VPN services to a specific NRP".*
>>
>>
>>
>> *[Med] ACK.*
>>
>>
>>
>> Idem stitching mechanisms are also declared out of scope:
>>
>>
>>
>> Section 2.2:
>>
>>    Some mapping mechanism may be needed by the controller
>>
>>    to match the MT-IDs of an inter-domain link in two directions, and
>>
>>    concatenate the inter-domain topology of the NRP.  The detailed
>>
>>    mechanism is out of the scope of this document.
>>
>>
>>
>>
>>
>> *[Chongfeng] As described in section 2, the mechanism described in this
>> document applies to networks where*
>>
>> * multiple domains are under a common administration, or they belong to
>> the same trusted domain. Thus it *
>>
>> *is assumed the normal case is the MT-IDs are allocated consistently in
>> multiple domains. If this is not the *
>>
>> *case, this document also gives the general description about the mapping
>> mechanism, which is similar to the *
>>
>> *mapping of other IDs (e.g. color) between the interconnected domains.
>> The detailed mechanism depends on *
>>
>> *the operators' choice thus does not belong to this document.*
>>
>>
>>
>>
>>
>> # Not obvious causality effect: design assumptions
>>
>>
>>
>> Section 2.2:
>>
>>    In some network scenarios, for instance, an operator's network
>>
>>    consists of multiple network parts, such as metro area networks,
>>
>>    backbone networks, or data center networks, each part being a
>>
>>    different AS..  Thus, there is a need to create NRPs which span
>>
>>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>    multiple ASes.
>>
>>    ^^^^^^^^^^^^^^
>>
>>
>>
>> The causality effect is not given. In the same way that distinct QoS
>> classes
>>
>> can be defined in each segment with appropriate mapping at the
>> boundaries, I
>>
>> don’t see why a single NRP has to be defined here. Stitching can be in
>> place,
>>
>> with handoff mechanisms.
>>
>>
>>
>> Also, support of NRPs does not need to be provided in all segments. NRPs
>> may be
>>
>> used in access-only, core-only.
>>
>>
>>
>>
>>
>> *[Chongfeng] How about changing it to "there may be a need to create NRPs
>> which span multiple ASes"?*
>>
>>
>>
>> *[Chongfeng] It is true that inter-AS NRP may not be required in all
>> network scenarios. An inter-domain *
>>
>> *NRP can be realized by stitching the single-domain NRPs, while the
>> inter-domain links may also need*
>>
>> * to be considered. This document just provides the mechanism for the
>> distribution of both single-domain*
>>
>> * NRP and inter-domain NRP information to a network controller. It is up
>> to the operators to choose *
>>
>> *which part of the mechanism is applicable to their networks.*
>>
>>
>>
>> *[Med] Works for me. Thanks.*
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>> COMMENT:
>>
>> ----------------------------------------------------------------------
>>
>>
>>
>> * Please change all “the network controller” occurrences with “a network
>>
>> controller” as many controllers can be deployed.
>>
>>
>>
>>  *[Chongfeng] Understood, will make this change in next revision of the
>> draft.*
>>
>> *[Med] Thanks.*
>>
>>
>>
>>
>>
>> ___
>>
>>
>> Best regards
>>
>> Chongfeng
>>
>> _________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>>