Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

["Dongjie (Jimmy)" <[e-mail]>]

Hi PSF, 

Please see some replies inline:

> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Tuesday, December 21, 2021 9:01 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption:
> 12/18/2021 to 1/7/2022
> 
> Hi Sue,
> 
> (sorry for plain tex format)
> 
> Please see in-line
> 
> Regards,
> PSF
> 
> ------------------原始邮件------------------
> 发件人：SusanHares
> 收件人：'Chongfeng Xie';彭少富;
> 抄送人：[e-mail];'Li Cong';
> 日 期 ：2021年12月21日 01:06
> 主 题 ：RE: [Idr]  draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption:
> 12/18/2021 to 1/7/2022 " _ue_custom_node_="true">
> Jie: Chongfeng and Shaofu:
> Let me summarize your answers:
> 1) The description of the VTN+  using existing BGP mechanisms is useful
> Since the majority draft simply describes the use of existing mechanisms, you
> are all interested in this description of these mechanisms.  The IDR WG
> planned to cross-review this document with BESS.  We had already check
> with the BESS WG chairs to determine that IDR was a good home for the
> informational discussion.  The TEAS WG to the list of cross-reviews.
> 
> [PSF] I'm not sure if the VPN+ framework and its extensions (even if it is
> informational ) need to be pushed forward when the slicing framework with
> related solutions are also been discussed in the TEAS WG. The statement that
> VPN+ is not only used for slicing seems interesting : )

Your above statement is groundless and irrelevant to this adoption poll. 

The VPN+ framework was adopted by TEAS WG more than 2 years ago, and the IETF network slice draft refers to VPN+ as an approach to realize IETF network slices. If you want to discuss the relationship between VPN+ and network slicing, there was a thread in TEAS mail list.

> 
> 2) Should IDR recommend the global VTN-ID?
> The IDR chairs understood that VTN-ID is not required for this draft if MT-IDs
> are managed by administrative control.   However, we know that the global
> IDs are useful for inter-domain usage.   So, let’s break down the responses
> to question 2 two steps:
> 1) Requirement:  all of you feel we should have a global ID representing
> MT-IDs managed by IANA.
> 2) You differ on the name and mechanisms
> 
> [PSF] We need a global ID, but it is not VTN-ID, nor AII, I suggest using NRP-ID
> that we have reached more consensus.

It has been clarified that the use cases and mechanism in this document does not rely on a global ID (no matter what you call it). 

If you want to discuss the global ID based mechanisms, please do it on another thread. 

> If I have summarized this correctly, then we may want to pick up the global
> ID as a separate and orthogonal discussion.  We will start another email
> thread on global ID topic.   The two drafts referenced are:
> ·         draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt – provides a BGP
> specific description for VTN-ID (Jie and Chongfeng)
> ·         draft-peng-teas-network-slicing-04.txt on describes use cases
> siting BGP-LS and some general terms on AII (Shaofu)
> To provide a constructive discussion, the Shaofu needs to provide a clear BGP
> description on the BGP-LS feature that can be handle.  The TEAS draft is not
> written to provide a clear BGP feature description.
> Please let me know if I have summarized your requirements and your desire
> for further discussion.
> 
> [PSF] Although draft-peng-teas-network-slicing-04.txt firstly proposed the
> need to introduce global slice-related identifier into the network, based on
> the comments of the TEAS chairs, it is merged to
> draft-bestbar-teas-ns-packet-05 for the purpose to quickly converge the
> scheme.  Please see draft-chen-idr-bgp-ls-transport-slice for the
> corresponding BGP-LS for NRP.
> [PSF] Other comments for this draft:
> i) The sentence
> "the resource-aware segments can be used to build SR based VTNs with the
> required
>    network topology and network resource attributes to support enhanced
>    VPN services."
> should be updated, because a set of segments can not represent a network.
> It like marketing words.

Saying something is "marketing" without concrete comment is not constructive. 

A set of resource-aware segments can be used to represent the links and nodes and the subset of resources allocated on them, thus they together builds an SR based virtual underlay network. 

> ii) As this document clearly states that it describe corresponding BGP-LS
> mechanisms for [I-D.ietf-lsr-isis-sr-vtn-mt], then section "2.2.  Inter-Domain
> Topology Advertisement" should be removed. The content of this section is
> irelated with draft-lsr, and especially, it is challenge to advertise an IGP MT-ID
> for inter-domain links.

This document is based on the BGP-LS mechanisms, which can be used to distribute both the intro-domain link states and also the inter-domain connectivity and attributes. 

MT-ID was introduced in IGP first, then MT-ID TLV is introduced in BGP-LS, nothing prevents its usage on the inter-domain links for the connection of multiple domains under the same administration. 

Best regards,
Jie

> 
> Cheerily, Sue
> From: Chongfeng Xie [mailto:[e-mail]]
> Sent: Monday, December 20, 2021 2:53 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; Li Cong
> Subject: Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption:
> 12/18/2021 to 1/7/2022 Hi, Shaofu, This document describes the
> mechanism of reusing BGP-LS Multi-topology TLV and the BGP-LS SR
> extensions to distribute the intra-domain topology and inter-domain
> topology attribute and the resource attribute of SR based VTNs. It does not
> introduce new BGP extensions nor new data plane identifiers. As the
> document type indicated, this is an informational document. Thus your
> comments related to VTN ID or NRP ID do not apply here.
> Thanks!
> Chongfeng
> 2021年12月20日 上午10:21，[e-mail] 写道：
> Hi Sue,
> 
> So far, VTN identifier mentioned in this draft is a very controversial thing.
> When the authors of VPN+ proposed the term VTN-ID, similar term, AII, has
> already existed and already discussed the details of resource partition. AII is
> defined in
> https://www.ietf.org/archive/id/draft-peng-teas-network-slicing-04.txt and
> now it is renamed as NRP-ID according to the latest network slice framwork
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/).
> So, does IDR WG want to standardize multiple similar identifiers (NRP-ID,
> VTN-ID, ...) or a single unified identifier that is just VTN-ID ?
> 
> Regards,
> PSF
> 
> ------------------原始邮件------------------
> 发件人：SusanHares
> 收件人：[e-mail];
> 日 期 ：2021年12月19日 00:33
> 主 题 ：[Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption:
> 12/18/2021 to 1/7/2022
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 
> This begins a WG Adoption call for draft-xie-idr-bgpls-sr-vtn-mt-03.txt from
> 12/18 2021 to 1/7/2022.  The longer period is due to the Holiday/New Year
> time period.
> The draft can be found at:
> https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/
> While reviewing the document consider the following questions:
> 1)  Does this informational draft aid operation of 5G networks for new
> applications?
> New 5G services require stringent  performance requirements for
> applications.  This information draft describes how to use existing segment
> routing (SR) mechanisms to allow a centralized control to allocate a set of
> virtual transport networks (VTNs) which are resource aware.  Isolation
> between resources for multi-AS transport may be necessary to protect the
> application.
> Intra-domain:
> a) Uses MT-ID which identifies 1 or more ISIS/OSPF topologies.
> [drafts referenced:  draft-ietf-idr-rfc7752bis,
> draft-ietf-idr-bgp-ls-segment-routing-ext,  draft-ietf-idr-bgpls-srv6-ext]
> b) New VTN-ID which specifies resources associated with each VTN [draft
> referenced: draft-ietf-lsr-isis-sr-vtn-mt] Inter-Domain mechanisms used
> include:
> a) Isolation of certain VTNs to specific inter-domain links or BGP peers,
> b) consistent use of MT-ID across multiple domains or use of VTN-ID TLV
> VTN-ID TLV is a bgp-ls TLV that specifies unique set of resources per VTN.
> [existing WG drafts referenced: draft-ietf-idr-bgpls-segment-routing-epe,
> draft-ietf-idr-bgpls-srv6-ext, draft-ietf-idr-rfc7752bis] New drafts referenced:
> draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt]
> 2) Should IDR recommend the global VTN-ID?
> The MT-ID is not an IANA registered named space.  VTN-ID is proposed as a
> global name space, but does not have any proposed IANA registry text.
> Should VTN-ID become a register global name space that identifies a set of
> MT-IDs and other resources?
> Cheers, Sue
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr