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]>]

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.   

 

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

 

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. 

 

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