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

From: "Susan Hares" <[email-masked]>
Date: Sat, 18 Dec 2021 11:32:42 -0500

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

---

From: <[email-masked]>
Date: Mon, 20 Dec 2021 10:21:17 +0800 (CST)

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
收件人：[email-masked];
日 期 ：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
[email-masked]
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

---

From: Chongfeng Xie <[email-masked]>
Date: Mon, 20 Dec 2021 15:53:08 +0800

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，[email-masked] 写道：
> 
> Hi Sue,
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 20 Dec 2021 07:58:28 +0000

Hi Sue,

I support the adoption of this document as coauthor. Please find my replies to the questions inline:

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Sunday, December 19, 2021 12:33 AM
To: [email-masked]
Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

[Jie] Yes.

Intra-domain:

[Jie] One clarification: for the mechanism in this document, new VTN-ID is not needed, as the MT-ID is reused in draft-ietf-lsr-isis-sr-vtn-mt and this document. The mechanism with new control plane VTN-ID is another solution as described in draft-dong-lsr-sr-enhanced-vpn for better scalability.

[Jie] Similar clarification: for the mechanism in this document, new VTN-ID is not needed, as the MT-ID can also be used for the inter-domain links. The mechanism with new control plane VTN-ID is another solution as described in draft-dong-idr-bgpls-sr-enhanced-vpn.

[Jie] Since this document simply proposes to reuse MT-ID to identify the VTNs in control plane, my suggestion is that we may discuss the range of MT-IDs which could be used for VTN in the IANA registry. The global name space for VTN-ID is not required by this document.

Best regards,
Jie

Cheers, Sue

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Mon, 20 Dec 2021 09:03:01 +0000

Hi Sue,
I support the adoption of this document. It provides a practical solution to build multiple SR based VTNs with existing BGP-LS MT and SR mechanisms.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Monday, December 20, 2021 3:58 PM
To: Susan Hares <[email-masked]>; [email-masked]
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,

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Sunday, December 19, 2021 12:33 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

[Jie] Yes.

Intra-domain:

Best regards,
Jie

Cheers, Sue

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 20 Dec 2021 22:59:30 +0800

Hi, all

     I support the adoption. This document describes the BGP-LS mechanism to distribute the intra/inter-domain topology and TE attributes to the network controller, which aligns with the IGP MT based mechanism.
 
    My answers to the questions are as below:
 
1)       Yes.
2)       Since it reuses MT-ID, IMO the global VTN-ID is not needed for this document.
 
Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Susan Hares
Date: 2021-12-19 00:32
To: [email-masked]

 

Intra-domain:  

 

 
Cheers, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Dec 2021 12:05:45 -0500

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.   

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:[email-masked]] 
Sent: Monday, December 20, 2021 2:53 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 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,

Thanks!

Chongfeng

Hi Sue,

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked];
日 期 ：2021年12月19日 00:33

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 21 Dec 2021 02:07:06 +0000

Hi Sue,

Thanks for the summary, please see some replies inline:

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, December 21, 2021 1:06 AM
To: 'Chongfeng Xie' <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Li Cong' <[email-masked]>
Subject: Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

[Jie] Yes, as reflected by the document type (informational), it describes the applicability of existing BGP-LS mechanisms for distributing the information of virtual underlay networks.

[Jie] This document focuses on the case where the MT-ID assignment in multiple domains are coordinated, this can happen when the domains belong to the same administrator. In this case, the global ID is not needed. What we may need from IANA is the range of MT-IDs which could be used for the VTN application.

I agree that global ID may be useful for inter-domain cases where such coordination is difficult. The global VTN-ID based mechanism is described in a separate document, thus the discussion about the name and mechanism of the global ID can happen in a separate thread later.

If I have summarized this correctly, then we may want to pick up the global ID as a separate and orthogonal discussion.

[Jie] Agreed.

Best regards,
Jie

We will start another email thread on global ID topic.   The two drafts referenced are:

Cheerily, Sue

From: Chongfeng Xie [mailto:[email-masked]]
Sent: Monday, December 20, 2021 2:53 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 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,

Thanks!
Chongfeng

2021年12月20日 上午10:21，[email-masked]<mailto:[email-masked]> 写道：

Hi Sue,

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked]<mailto:[email-masked]>;
日 期 ：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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 21 Dec 2021 17:02:51 +0800

Hi, Sue and all:

I have read this draft and support its adoption. 

This draft gives the method to report the SR based Multi-Topology derived
VTN information via the BGP-LS, and can assist the controller build the
customized VTN.

Some answers to the mentioned questions are inline.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Susan Hares
Sent: Sunday, December 19, 2021 12:33 AM
To: [email-masked]
Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption:
12/18/2021 to 1/7/2022

[WAJ] Yes, for some applications that need to critical QoS performance.

Intra-domain:  

[WAJ] No new VTN-ID is defined in this document, only reuses the MT-ID。 

[WAJ] This should be discussed in
draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt

Cheers, Sue

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Dec 2021 05:13:07 -0500

Hi Sue / All

I support WG Adoption of this draft.

TEAS WG has had extensive discussions on how to best identify the underlay
underpinning of overlay VPN to instantiate NSC network slice and has now
changed the naming convention to NRP “Network Resource Partition”.   Jie
and authors are now planning to change all references to VTN and VTN-ID to
NRP and NRP-ID to maintain consistency with TEAS Network slicing document
below.

https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05

In this draft the concept of VTN-ID is irrelevant.

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.

 Gyan> Yes.  This document describes a mechanism to distribute the VTN or
NRP (Network Resource Partitions) logical underlay represented by ISIS MTID
topology partition that maps to VPN+ Enhanced VPN overlay network slice for
5G services instantiatio*n.*

*This draft being adopted maps ISIS MT draft below to TEAS network slice
via centralized
controller https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt
<https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt>*

Intra-domain:

MTID “multi topology ID” RFC 5120 is only relevant to ISIS not OSPF.  Both
OSPFv3 and ISIS have the concept of instances and multi instance ISIS MI
RFC 6822 and OSPF address families RFC 5838 respectively.  MT is separate
control plane and common data plane where Multi Instance is separate
control plane and data plane.  So the intent of the authors I believe is
mapping of ISIS MT and OSPF multi instance concepts to a network slice.

drafts referenced:  draft-ietf-idr-rfc7752bis,
draft-ietf-idr-bgp-ls-segment-routing-ext,  draft-ietf-idr-bgpls-srv6-ext]

Intra domain topology advertisement of MT-ID TLV in BGP LS attribute

BGP-LS extension for SR is now RFC 9085 ( intra-as)

BGP-LS extension for inter-as SR egress peering is now RFC 9086 (inter-as)

 This draft distributes to centralized controller using BGP-LS networks
graph of logical underlay MTID control plane sub layer for Network Slice
Controller (NSC) instantiation of a 5G networks slice

Yes using MT-ID advertisement

Inter domain topology advertisement of MT-ID TLV in BGP LS attribute for
E2E network slice instantiation

 Only ISIS MTID or OSPF instance control plane network graph for
instantiation of 5G network slice.  In this draft VTN ID is not relevant.

VTN-ID TLV is a bgp-ls TLV that specifies unique set of resources per VTN.
Again, VTN-ID is not relevant.

 Again VTN-ID is not relevant here only MT-ID mapping to TEAS 5G Network
slice

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?
No as VTN-ID is not relevant here. Only ISIS MT-ID or OSPF instance is
relevant to map to 5G network slice.

Kind Regards

Gyan

On Sat, Dec 18, 2021 at 11:33 AM Susan Hares <[email-masked]> wrote:

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Tue, 21 Dec 2021 21:01:14 +0800 (CST)

Hi Sue,

(sorry for plain tex format)

Please see in-line

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：'Chongfeng Xie';彭少富;
抄送人：[email-masked];'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 : )

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

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

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.

Cheerily, Sue

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked];
日 期 ：2021年12月19日 00:33

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Dec 2021 11:33:15 -0500

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: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 21, 2021 8:01 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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,

Please see in-line

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：'Chongfeng Xie';彭少富;

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

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

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

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

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked];
日 期 ：2021年12月19日 00:33

---

From: <[email-masked]>
Date: Wed, 22 Dec 2021 11:55:42 +0800 (CST)

Hi Sue,

I'm sorry to confuse you, please see in-line [PSF-2]

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：彭少富;
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2021年12月22日 00:33
主 题 ：RE: [Idr]  draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022
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.

[PSF2] Agree.

[PSF2] for 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."
Suggested sentence:
"The SR based VTNs with the required network topology and network resource attributes
can be identified by a global identifier and build dynamically or by static configuration.
It can allocate a separate set of resource-aware segments."

[PSF2] Yes, IMO, a global ID, but not a global MT-ID. However, agree that such a discussion is benefit.
Most respondents on the adoption thread do not see the global ID as a requirement for this draft.

[PSF2] Indeed I have the same opinion if section "2.2.  Inter-Domain Topology Advertisement" is removed. It is not appropriate to describe the corresponding advertisement of BGP-LS before the discussion of this part is clear that an identification (MT-ID) with only the meaning within the IGP domain is applicable to the inter-domain link. The authors should provide how this can work, and similarly, more locally defined identifiers (such as VLAN-ID) can also be further globalized in L3 for the similar purpose.

Susan Hares
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 21, 2021 8:01 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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,
------------------原始邮件------------------
发件人：SusanHares
收件人：'Chongfeng Xie';彭少富;
------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked];
日 期 ：2021年12月19日 00:33

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 22 Dec 2021 07:42:08 +0000

Hi PSF, 

Please see some replies inline:

> From: Idr [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, December 21, 2021 9:01 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 主 题 ：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">
> 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.

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

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

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

> 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
> 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
> 
> 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:
> draft-ietf-idr-bgpls-srv6-ext, draft-ietf-idr-rfc7752bis] New drafts referenced:
> draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt]

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Dec 2021 08:55:38 -0500

Shaofu:

Thank you for your kind and clear email.   See my comments below. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 21, 2021 10:56 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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,

Regards,
PSF

------------------原始邮件------------------
发件人：SusanHares
收件人：彭少富;

[PSF2] Agree.

[PSF2] for sentence

[Sue]:  Since BGP-LS distributes many types of IGP information via BGP,  the discussion should be about whether distributing MT-ID is useful . 
RFC 9086 discusses passing BGP-LS information for efficient BGP egress peer policies.   

Susan Hares
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 21, 2021 8:01 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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,
------------------原始邮件------------------
发件人：SusanHares
收件人：'Chongfeng Xie';彭少富;
------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked];
日 期 ：2021年12月19日 00:33

---

From: Mach Chen <[email-masked]>
Date: Fri, 24 Dec 2021 02:23:15 +0000

Hi Sue,

I have read the draft and support the adoption of the document.

Regarding your 2nd question, I think it can be discussed further in IDR and other relevant WGs (e.g., TEAS),  but should not be in this draft.

Best regards,
Mach

Intra-domain:

Cheers, Sue

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 24 Dec 2021 03:08:47 +0000

Hi Everyone,

    I support the adoption.
    The draft aids some operations of 5G networks.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Sent: Saturday, December 18, 2021 11:32 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-xie-idr-bgpls-sr-vtn-mt%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C39862ebe2ff44bc773bc08d9c24412d4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637754419919150632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hLHTErgnx7dDyMtkV%2BpihfnZFjfr5SoDQ0AXtoswuL0%3D&reserved=0>

Intra-domain:

Cheers, Sue

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 24 Dec 2021 06:40:30 +0000

Hi, Sue and all:

Answers to the questions:
1) Yes, it is useful for meeting the requirement of the new services in 5G and other network scenarios.
2) Global VTN-ID is not required in this document, and can be discussed separately. IDR can follow the discussion about the global ID in TEAS.

Best Regards
Shunwan

Intra-domain:

Cheers, Sue

---

From: Li Cong <[email-masked]>
Date: Fri, 24 Dec 2021 20:43:58 +0800

Hi all,

This work reuses MT-ID to identify the VTNs in control plane. Based on my experience I think this work is useful for building multiple SR based VTNs in single domain or multiple domain operated by the same operator. 

In addition, it is an informational document without introducing any new identifiers and routing mechanism. Therefore, I support the adoption of this document as the co-author. 

Best regards，

Cong Li

------------------原始邮件------------------
发件人：SusanHares
收件人：[email-masked];
日 期 ：2021年12月19日 00:33

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 27 Dec 2021 18:58:02 +0800

Support this adoption.

Yes.

2) Should IDR recommend the global VTN-ID?
I don't think the global VTN-ID is needed.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Susan Hares
Date: 2021-12-19 00:32
To: [email-masked]

 

Intra-domain:  

 

 
Cheers, Sue

---

From: Lizhenbin <[email-masked]>
Date: Tue, 28 Dec 2021 07:59:47 +0000

Hi All,
I support the adoption of the draft.

My answers to the questions is as follows:
1) Yes.
2) Global VTN-ID is not required in this document. The work of the Global VTN ID can be discussed separately and should be discussed firstly in the TEAS WG.

Best Regards,
Zhenbin (Robin)

Intra-domain:

Cheers, Sue

---

From: Chongfeng Xie <[email-masked]>
Date: Wed, 29 Dec 2021 22:37:42 +0800

Hi，folks，
I support the adoption of this draft as the author.
Generally, our network services provide not only 5G-based wireless mobile data, but  also wireline sevice for enterprise services, this poses wide variety of requirements to the underlying transport network, this draft illustrates how to management virtual transport networks (VTNs) which are resource-aware and  resources-isolated among each over the common transport network. Obviously, this is valuable for operators.
As mentioned several times in the mailist, this draft does not intend to design new ID or bop extension  it mainly discusses how to use mt-id and provide slicing service rapidly in operator networks. Global VTN-ID can be discussed in the future in other drafts or in other WGs.

Best regards!
Chongfeng

> 2021年12月28日 下午3:59，Lizhenbin <lizhenbin=[email-masked]> 写道：
> 
> Hi All,

> https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/ <https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/>
>

---

From: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>
Date: Fri, 31 Dec 2021 07:06:46 +0000

Hi all,

I’ve read this document and support its adoption. Below are my answers to the questions:

Yes.

The global ID based mechanism can be discussed later in a separate thread.

Best regards,
Pang Ran.

From: Susan Hares<mailto:[email-masked]>
Date: 2021-12-19 00:32
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022
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.

Intra-domain:

Cheers, Sue

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.