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

Aijun Wang <wangaijun@tsinghua.org.cn> Sat, 29 January 2022 03:49 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1023A10D4 for <ipv6@ietfa.amsl.com>; Fri, 28 Jan 2022 19:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mybkFUFctEE7 for <ipv6@ietfa.amsl.com>; Fri, 28 Jan 2022 19:49:03 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4943A10DE for <ipv6@ietf.org>; Fri, 28 Jan 2022 19:48:56 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 2170C1C034C; Sat, 29 Jan 2022 11:48:54 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: peng.shaofu@zte.com.cn, jie.dong@huawei.com
Cc: ipv6@ietf.org, bob.hinden@gmail.com
References: A423376D-CC8F-4841-A571-B4FFEF8B62F5@gmail.com, 202201281124190882212@zte.com.cn, 64225b3c1e2f45529594eda417909fbd@huawei.com <202201281753038221701@zte.com.cn>
In-Reply-To: <202201281753038221701@zte.com.cn>
Subject: RE: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
Date: Sat, 29 Jan 2022 11:48:54 +0800
Message-ID: <00c901d814c3$22f01fd0$68d05f70$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH94/Fdl6Rv/aFSe1RiyFKKrBeYYKwtuwSw
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWRlNGRlWTUlOHUgeTh 5MGRkYVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Nhw6KRw4FD4CDihDTQkzPCMB UVFPCSpVSlVKTU9IT0lDSkhPTk1NVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUxNTkg3Bg++
X-HM-Tid: 0a7ea3f33d81d993kuws2170c1c034c
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TdAJnThqTGNHRwYaMcfQIdAjCKM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2022 03:49:08 -0000

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: ipv6-bounces@ietf.org <ipv6-bounces@ietf.org> On Behalf Of peng.shaofu@zte.com.cn
Sent: Friday, January 28, 2022 5:53 PM
To: jie.dong@huawei.com
Cc: ipv6@ietf.org; bob.hinden@gmail.com
Subject: 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
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------