Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Jan 2022 21:49:15 -0800

This message starts a two week 6MAN call on adopting:

 Title:          Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension
                 Header
 Authors:        J. Dong, Z. Li, C. Xie, C. Ma, G. Mishra
 File Name:      draft-dong-6man-enhanced-vpn-vtn-id-06
 Document date:  October 24, 2021

https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id-06

as a working group document.  Substantive comments and statements of support for adopting this document should be sent to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 10 February 2022.

Further, if you are willing to work on this document, either as contributor, author, or reviewer please notify the list.   This will provide the chairs with an indication of the energy level in the working group to work on this document.

Bob & Ole
6man Chairs

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 27 Jan 2022 15:53:33 +0800

I support the adoption.
 
The mechanism in this document can be used in IPv6 networks to provide resource guaranteed virtual networks to meet the performance requirements of 5G and other demanding services.
 
I am willing to help to review this document after the adoption.
 
Best regards,
Yongqing Zhu

[email-masked]
 
From: Bob Hinden
Date: 2022-01-27 13:49
To: IPv6 List
CC: Bob Hinden
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
This message starts a two week 6MAN call on adopting:

 

Bob & Ole
6man Chairs

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 27 Jan 2022 17:12:42 +0800

Hi, all

    I’ve read this document and support the adoption. 

    Using IPv6 HBH to carry VTN resource ID is a reasonable approach, as this information needs to be parsed and processed on each hop during packet forwarding. 

    I would like to help to review this document as it progresses further.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Bob Hinden
Date: 2022-01-27 13:49
To: IPv6 List
CC: Bob Hinden

 

Bob & Ole
6man Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 27 Jan 2022 09:47:27 +0000

Hi,

I support the adoption of this draft. 

This is a valid application of the IPv6 HBH Options Header, where HBH is used to identify the set of reserved network resources on each hop along the forwarding paths. This can be used to provide network slice services with guaranteed network resources.

Thank you! 

Best regards, 
Shuping 

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Thursday, January 27, 2022 1:49 PM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> as a working group document.  Substantive comments and statements of
> support for adopting this document should be sent to the mailing list.
> Editorial suggestions can be sent to the authors.  This adoption call will end
> on 10 February 2022.
> 
> Further, if you are willing to work on this document, either as contributor,
> author, or reviewer please notify the list.   This will provide the chairs with
> an indication of the energy level in the working group to work on this
> document.
> 
> Bob & Ole
> 6man Chairs

---

From: James Guichard <[email-masked]>
Date: Thu, 27 Jan 2022 11:22:59 +0000

I support adoption of this document as it seems a useful application of the HBH option header.

Jim

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Thursday, January 27, 2022 12:49 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-6man-enhanced-vpn-vtn-id-06&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C2fb62a0f16254773279708d9e158cd5a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788593812197999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=j0bw9PYws%2FZCJp9SCctPIyiGaLuSM5IFFXz%2BhSf%2BI8A%3D&amp;reserved=0

Bob & Ole
6man Chairs

---

From: Chongfeng Xie <[email-masked]>
Date: Thu, 27 Jan 2022 19:29:04 +0800

Hi, folks,

I support the adoption poll as a co-author.
 
It makes use of IPv6 HBH to identify the network resources allocated for per VTN packet processing, which can be useful for network scenarios with a large number of VTNs.
 
Best regards,

Chongfeng
 
> 2022年1月27日 下午1:49，Bob Hinden <[email-masked]> 写道：
> 
> <signature.asc>--------------------------------------------------------------------

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 27 Jan 2022 09:44:22 -0500

I support WG adoption of this draft as co-author.

This draft proposes an important new IPv6 HBH extension header option to
carry the VTN resource ID used to identify the underlay resources allocated
for TEAS Network Slicing underpinning for  Enhanced VPN provisioning with
high reliability  low latency and jitter SLA/SLO  to be utilized for 5G
edge compute services requirement being deployed by wireless operators.

Kind Regards

Gyan

On Thu, Jan 27, 2022 at 6:29 AM Chongfeng Xie <[email-masked]>
wrote:

> It makes use of IPv6 HBH to identify the network resources allocated for
> per VTN packet processing, which can be useful for network scenarios with a
> large number of VTNs.
>
> Best regards,
>
> Chongfeng
>
>
> Editorial suggestions can be sent to the authors.  This adoption call will
> end on 10 February 2022.
>
> Further, if you are willing to work on this document, either as
> contributor, author, or reviewer please notify the list.   This will
> provide the chairs with an indication of the energy level in the working
> group to work on this document.
>
> Bob & Ole
> 6man Chairs
>
> <signature.asc>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 27 Jan 2022 16:05:06 +0000

I support adoption of this document. I think it is a useful application of the HBH option header.

Linda Dunbar

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Thursday, January 27, 2022 12:49 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-6man-enhanced-vpn-vtn-id-06&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cdb64c2fd94a74e1869e308d9e18773d0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788794211367831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X%2BqIJh4fGdhY85d9uSuJfotymNLoC7%2BqLCKBCSQq0kw%3D&amp;reserved=0

Bob & Ole
6man Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cdb64c2fd94a74e1869e308d9e18773d0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788794211367831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dwXVy4K7l7vEEYeglSsRsvjGuoI%2Bc2sry%2BHMCFHXgnA%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Haoyu Song <[email-masked]>
Date: Thu, 27 Jan 2022 18:08:59 +0000

Hi WG,

I support the adoption of the draft. VTN is an important use case can carry its identifier in HBH EH is a reasonable solution.

Best,
Haoyu  

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Wednesday, January 26, 2022 9:49 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-6man-enhanced-vpn-vtn-id-06&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C6d0fe5a32a704e6af1ea08d9e158d1e6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788593911783663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=pVqfoAtUACR8AIwQWvTA4729LasKqunE7HmPogh8McA%3D&amp;reserved=0

Bob & Ole
6man Chairs

---

From: <[email-masked]>
Date: Fri, 28 Jan 2022 11:24:19 +0800 (CST)

Hi Chairs, WG,

I OBJECT to the adoption of this draft.
VTN-ID is not something that most people has reached a consensus. It has an irresistible debate with AII defined in  draft-peng-teas-network-slicing, now that is converged to NRP-ID defined in draft-bestbar-teas-ns-packet according to the latest network slice framwork draft-ietf-teas-ietf-network-slices.
Please see the debate in https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/ to know when/how VTN-ID is introduced.

The author needs to clarify the difference between VTN-ID and NRP-ID. The argument that the VTN-ID is not only used for slicing is weak. If VTN-ID equals to NRP-ID plus something X, someone may also introduce a VVTN-ID that equals to VTN-ID plus something Y, it doesn't make any sense.

Regards,
PSF

------------------原始邮件------------------
发件人：BobHinden
收件人：IPv6 List;
抄送人：Bob Hinden;
日 期 ：2022年01月27日 13:50
主 题 ：Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 28 Jan 2022 06:33:01 +0000

Hi PSF,

Your comment is about the terminology rather than the technology. Thus I assume you also agree with the HBH based mechanism described in the draft.

The essence of this document is to define a data plane identifier which refers to a subset of network resources allocated on a group of nodes and links. In my understanding the "AII" you mentioned was an identifier in the control plane, which is irrelevant to this draft. 

The term VTN was introduced in draft-ietf-teas-enhanced-vpn (VPN+ framework) for a virtual underlay network, and this document aligns with that terminology. Later the term NRP was introduced in TEAS. The relationship between VTN and NRP will be described in next revision of VPN+ framework, and further discussion could happen in TEAS. If after some discussion it turns out that VTN and NRP are synonymous for TEAS, we are open to align the term in a future version with whatever the TEAS WG prefers.

In summary, IMO we should focus on the technology part here. The coordination on the terminology is needed, while we don't need to worry too much about it. 

Best regards,
Jie

> From: ipv6 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, January 28, 2022 11:24 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
> 
> Hi Chairs, WG,
> 
> VTN-ID is not something that most people has reached a consensus. It has an
> irresistible debate with AII defined in  draft-peng-teas-network-slicing, now
> that is converged to NRP-ID defined in draft-bestbar-teas-ns-packet according
> to the latest network slice framwork draft-ietf-teas-ietf-network-slices.
> Please see the debate in
> https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PP
> bRM/ to know when/how VTN-ID is introduced.
> 
> The author needs to clarify the difference between VTN-ID and NRP-ID. The
> argument that the VTN-ID is not only used for slicing is weak. If VTN-ID equals
> to NRP-ID plus something X, someone may also introduce a VVTN-ID that
> equals to VTN-ID plus something Y, it doesn't make any sense.
> 
> Regards,
> PSF
>

---

From: <[email-masked]>
Date: Fri, 28 Jan 2022 17:53:03 +0800 (CST)

Hi Dongjie,

Please see inline.

Regards,
PSF
------------------原始邮件------------------
发件人：Dongjie(Jimmy)
收件人：彭少富10053815;[email-masked];
抄送人：[email-masked];[email-masked];
日 期 ：2022年01月28日 14:33
主 题 ：RE: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
Hi PSF,
Your comment is about the terminology rather than the technology. Thus I assume you also agree with the HBH based mechanism described in the draft.
The essence of this document is to define a data plane identifier which refers to a subset of network resources allocated on a group of nodes and links. In my understanding the "AII" you mentioned was an identifier in the control plane, which is irrelevant to this draft.

[PSF] That is misunderstanding of AII. In fact, AII is used in management plane, control plane, and data plane. You may think that an identifier is only considered to be used in the data plane if it is carried in the packets. That is not true.
[PSF] The converged term, NRP-ID, also indicates to be used in data plane only, control plane only, and  both control and data planes.
The term VTN was introduced in draft-ietf-teas-enhanced-vpn (VPN+ framework) for a virtual underlay network, and this document aligns with that terminology. Later the term NRP was introduced in TEAS. The relationship between VTN and NRP will be described in next revision of VPN+ framework, and further discussion could happen in TEAS. If after some discussion it turns out that VTN and NRP are synonymous for TEAS, we are open to align the term in a future version with whatever the TEAS WG prefers.
In summary, IMO we should focus on the technology part here. The coordination on the terminology is needed, while we don't need to worry too much about it.

[PSF] Even if we put aside the debate on the identifier first, it does not mean that the packets need to carry the identifier itself, and other information (e.g, slice aggregate selector) can be carried and mapped to it.

Best regards,
Jie

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 29 Jan 2022 11:48:54 +0800

Hi, Shaofu:
I think the terminology can be synchronized up later.
Or, Is there any different between the "VTN Resource ID" identifier and the "slice aggregate selector"?
If there are enough difference, can we define and include both of them within the packet header(that is, define another additional HBH option)? 

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, January 28, 2022 5:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Dongjie,

Please see inline.

Regards,
PSF
------------------原始邮件------------------
发件人：Dongjie(Jimmy)

Best regards,
Jie
> VTN-ID is not something that most people has reached a consensus. It 
> has an irresistible debate with AII defined in  
> draft-peng-teas-network-slicing, now that is converged to NRP-ID 
> defined in draft-bestbar-teas-ns-packet according to the latest network slice framwork draft-ietf-teas-ietf-network-slices.
> Please see the debate in
> The author needs to clarify the difference between VTN-ID and NRP-ID. 
> The argument that the VTN-ID is not only used for slicing is weak. If 
> VTN-ID equals to NRP-ID plus something X, someone may also introduce a 
> VVTN-ID that equals to VTN-ID plus something Y, it doesn't make any sense.
>
> Regards,
> PSF
>
> https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn
> -id
> -06
> Editorial suggestions can be sent to the authors.  This adoption call 
> will end on 10 February 2022.

---

From: <[email-masked]>
Date: Sat, 29 Jan 2022 14:17:32 +0800 (CST)

Hi Aijun,

IMO VTN-ID is equivalent to NRP-ID, however, the right of interpretation belongs to the author of this draft.

Regards,
PSF

------------------原始邮件------------------
发件人：AijunWang
收件人：彭少富10053815;[email-masked];
抄送人：[email-masked];[email-masked];
日 期 ：2022年01月29日 11:48
主 题 ：RE: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
Hi, Shaofu:
I think the terminology can be synchronized up later.
Or, Is there any different between the "VTN Resource ID" identifier and the "slice aggregate selector"?
If there are enough difference, can we define and include both of them within the packet header(that is, define another additional HBH option)?
Best Regards
Aijun Wang
China Telecom
-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, January 28, 2022 5:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
Hi Dongjie,
Please see inline.
Regards,
PSF
------------------原始邮件------------------
发件人：Dongjie(Jimmy)

---

From: Huzhibo <[email-masked]>
Date: Sat, 29 Jan 2022 09:35:18 +0000

Hi WG,

It defines a simple approach to identify the network-wide isolated resources, which can be useful for network slicing.

The VTN resource ID needs to be processed hop-by-hop, thus I think this document is in the right direction.

Thanks
Zhibo
> Editorial suggestions can be sent to the authors.  This adoption call will end on
> 10 February 2022.
> 
> author, or reviewer please notify the list.   This will provide the chairs with an
> indication of the energy level in the working group to work on this document.
> 
> Bob & Ole
> 6man Chairs

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 30 Jan 2022 11:39:09 +0800

Hi all,

I support the adoption as a coauthor.
 
The HBH based extension proposed in this document is needed in IPv6 networks which will need to provide customized network resource and characteristics for different services.
 
I also think the technology part is what we can spend more effort on, and the terminology can always be aligned and updated when there is consensus reached.
 
Best regards,
Chenhao
From: Bob Hinden
Date: 2022-01-27 13:49
To: IPv6 List
CC: Bob Hinden

 

Bob & Ole
6man Chairs