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

[Susan Hares <[e-mail]>]

Shaofu: 

Some of your message is unclear to me.   To make sure we are communicating, let me restate some basic principles I'm working on. 

First of all,  BGP mechanisms for BGP-LS are discussed in IDR rather than TEAS.   Use cases and Yang modules are defined in TEAS.  draft-peng-teas-network-slicing-04.txt - appears to be a general use case description which you indicated is no longer going forward.  

Second, adoption calls for WG drafts should give concrete comments.   One of your comments provides a nice clear description of a sentence you do not like.  You can also propose alternate text for the authors.  

Third, my understanding is that you see a requirement for a IANA managed global ID that associated with MT-ID values.  I will start an alternate discussion forum for the discussion of the 
 
draft-chen-idr-bgp-ls-transport-slice-03.txt 
draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt

Please continue the comparison description of two alternatives for a global ID on that mail thread.   

Most respondents on the adoption thread do not see the global ID as a requirement for this draft.  

Susan Hares 
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, December 21, 2021 8:01 AM
To: [e-mail]
Cc: [e-mail]; [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 : )

[Sue] I cannot parse this information.  TEAS should not be discussing BGP mechanisms, but only use cases.   The draft-bestbar-teas-yang-topology-filter-02.txt is a yang module.   You propose an alternate solution for the global ID, but you say you are not interested the VTN+ requirements.  This seems contradictory.  


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.

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.

[Sue] OK, so the draft you wish compare is draft-chen-idr-transport-slice-03.txt.    I will start the alternate comparison. 

[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.

[Sue] This is good comment that is specific.  Can you suggest an alternate set of text for the authors? 

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.

[Sue]:  The coordination of the MT-ID is administratively challenging.  Please provide specific detail on why you feel this drafts solution will not work.   The specific detail should focus on BGP or on the operational aspects.   If you are referring to the fact that BGP-LS exposes ISIS/OSPF mechanisms,  it is unclear what you are stating.  
 
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