Re: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-06.txt

"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 20 February 2024 09:40 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 02190C14F680; Tue, 20 Feb 2024 01:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo3t2jVYUo58; Tue, 20 Feb 2024 01:40:01 -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 9E39AC18DBB8; Tue, 20 Feb 2024 01:39:55 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TfDm81RKDz67pJF; Tue, 20 Feb 2024 17:35:36 +0800 (CST)
Received: from lhrpeml100006.china.huawei.com (unknown [7.191.160.224]) by mail.maildlp.com (Postfix) with ESMTPS id B8D89141478; Tue, 20 Feb 2024 17:39:52 +0800 (CST)
Received: from dggpemm100005.china.huawei.com (7.185.36.231) by lhrpeml100006.china.huawei.com (7.191.160.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 20 Feb 2024 09:39:51 +0000
Received: from kwepemd100004.china.huawei.com (7.221.188.31) by dggpemm100005.china.huawei.com (7.185.36.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 20 Feb 2024 17:39:49 +0800
Received: from kwepemd100004.china.huawei.com ([7.221.188.31]) by kwepemd100004.china.huawei.com ([7.221.188.31]) with mapi id 15.02.1258.028; Tue, 20 Feb 2024 17:39:49 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
CC: 6man Chairs <6man-chairs@ietf.org>
Thread-Topic: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-06.txt
Thread-Index: AQHaY9xx84BBHSlKSEiyt1wcVFnxO7ES9i8A
Date: Tue, 20 Feb 2024 09:39:49 +0000
Message-ID: <8c74e0a3fddd48e28e97297a1edb3ede@huawei.com>
References: <170842004213.21830.77988683637006936@ietfa.amsl.com>
In-Reply-To: <170842004213.21830.77988683637006936@ietfa.amsl.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/82Eal1r08UQTL1g3olISfcP1sPQ>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-06.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 20 Feb 2024 09:40:03 -0000

Hi all, 

This new revision addresses the comments and discussion both on the mail list and in offline reviews. Specifically, the usage and benefit of the S flag is elaborated. 

It also follow the decision of TEAS WG on the terminology alignment between VTN and NRP, so now NRP is used consistently among the enhanced VPN documents. 

The authors believe this version is in a good shape and ready for WG last call, and we would like to request for early allocation of the code point for the new HBH option as defined in the document. 

As always review and comments are welcome. 

Best regards,
Jie

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Tuesday, February 20, 2024 5:07 PM
> To: i-d-announce@ietf.org
> Cc: ipv6@ietf.org
> Subject: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-06.txt
> 
> Internet-Draft draft-ietf-6man-enhanced-vpn-vtn-id-06.txt is now available. It
> is a work item of the IPv6 Maintenance (6MAN) WG of the IETF.
> 
>    Title:   Carrying Network Resource Partition (NRP) Information in IPv6
> Extension Header
>    Authors: Jie Dong
>             Zhenbin Li
>             Chongfeng Xie
>             Chenhao Ma
>             Gyan Mishra
>    Name:    draft-ietf-6man-enhanced-vpn-vtn-id-06.txt
>    Pages:   12
>    Dates:   2024-02-20
> 
> Abstract:
> 
>    Virtual Private Networks (VPNs) provide different customers with
>    logically separated connectivity over a common network
>    infrastructure.  With the introduction and evolvement of 5G and also
>    in some existing network scenarios, some customers may require
>    network connectivity services with advanced features comparing to
>    conventional VPN services.  Such kind of network service is called
>    enhanced VPNs.  Enhanced VPNs can be used, for example, to deliver
>    network slice services.
> 
>    A Network Resource Partition (NRP) is a subset of the network
>    resources and associated policies on each of a connected set of links
>    in the underlay network.  An NRP could be used as the underlay to
>    support one or a group of enhanced VPN services.  For packet
>    forwarding in a specific NRP, some fields in the data packet are used
>    to identify the NRP the packet belongs to, so that NRP-specific
>    processing can be performed on each node along a path in the NRP.
> 
>    This document specifies a new IPv6 Hop-by-Hop option to carry the NRP
>    related information in data packets, which could be used to identify
>    the NRP-specific processing to be performed on the packets by each
>    network node along a network path in the NRP.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-vpn-vtn-id/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-enhanced-vpn-vtn-id-0
> 6
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-enhanced-vpn-vtn-i
> d-06
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------