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

Hi Dongjie,

Please see inline.

Regards,
PSF
------------------原始邮件------------------
发件人：Dongjie(Jimmy)
收件人：彭少富10053815;bob.hinden@gmail.com;
抄送人：bob.hinden@gmail.com;ipv6@ietf.org;
日 期 ：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
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of
> peng.shaofu@zte.com.cn
> Sent: Friday, January 28, 2022 11:24 AM
> To: bob.hinden@gmail.com
> Cc: bob.hinden@gmail.com; ipv6@ietf.org
> Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
>
> 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/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
>
> ------------------原始邮件------------------
> 发件人：BobHinden
> 收件人：IPv6 List;
> 抄送人：Bob Hinden;
> 日 期 ：2022年01月27日 13:50
> 主 题 ：Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
> 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------