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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 28 January 2022 06:33 UTC

Return-Path: <jie.dong@huawei.com>
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 E9BEE3A1EC3 for <ipv6@ietfa.amsl.com>; Thu, 27 Jan 2022 22:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 fP3pfyKgOg_8 for <ipv6@ietfa.amsl.com>; Thu, 27 Jan 2022 22:33:07 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB983A1EC2 for <ipv6@ietf.org>; Thu, 27 Jan 2022 22:33:06 -0800 (PST)
Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JlSGy2CN5z67NW9; Fri, 28 Jan 2022 14:29:30 +0800 (CST)
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.21; Fri, 28 Jan 2022 07:33:03 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Fri, 28 Jan 2022 14:33:01 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.2308.021; Fri, 28 Jan 2022 14:33:01 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>, "bob.hinden@gmail.com" <bob.hinden@gmail.com>
CC: "bob.hinden@gmail.com" <bob.hinden@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
Thread-Topic: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
Thread-Index: AQHYE0G4NKv6hZFSfEG/N3hGEJ3eMax3QHKAgACJwwA=
Date: Fri, 28 Jan 2022 06:33:01 +0000
Message-ID: <64225b3c1e2f45529594eda417909fbd@huawei.com>
References: A423376D-CC8F-4841-A571-B4FFEF8B62F5@gmail.com <202201281124190882212@zte.com.cn>
In-Reply-To: <202201281124190882212@zte.com.cn>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/K9UOCDk-iCpoP4jlyT7tlNvvfSc>
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: Fri, 28 Jan 2022 06:33:11 -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

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