RE: draft-dong-6man-enhanced-vpn-vtn-id-01

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 31 July 2020 15:08 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 EEBB63A1402 for <ipv6@ietfa.amsl.com>; Fri, 31 Jul 2020 08:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 PHNpv_p_0ZI5 for <ipv6@ietfa.amsl.com>; Fri, 31 Jul 2020 08:08:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3A73A1404 for <6man@ietf.org>; Fri, 31 Jul 2020 08:08:45 -0700 (PDT)
Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8944A4AE506F5121CF41 for <6man@ietf.org>; Fri, 31 Jul 2020 16:08:43 +0100 (IST)
Received: from dggeme753-chm.china.huawei.com (10.3.19.99) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 31 Jul 2020 16:08:41 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme753-chm.china.huawei.com (10.3.19.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 31 Jul 2020 23:08:39 +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.1913.007; Fri, 31 Jul 2020 23:08:39 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Ron Bonica <rbonica@juniper.net>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: draft-dong-6man-enhanced-vpn-vtn-id-01
Thread-Topic: draft-dong-6man-enhanced-vpn-vtn-id-01
Thread-Index: AdZlBQlO9JhlnyNeQUaR/K2vKekKjAAb4TWQAEeikQAAIQhKwAAMbY9wAACSb1A=
Date: Fri, 31 Jul 2020 15:08:39 +0000
Message-ID: <ba95837420c445699118e8adc25056f9@huawei.com>
References: <DM6PR05MB6348F564EE4A9470553B0A8AAE730@DM6PR05MB6348.namprd05.prod.outlook.com> <d579687dd60141b3902706539292a0c4@huawei.com> <DM6PR05MB6348760B5BD1F8BA8874717EAE710@DM6PR05MB6348.namprd05.prod.outlook.com> <c8f4a8b241b94b3c8ab904a6ae08be3a@huawei.com> <DM6PR05MB6348074D195B3DA137F60389AE4E0@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6348074D195B3DA137F60389AE4E0@DM6PR05MB6348.namprd05.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.34.5]
Content-Type: multipart/alternative; boundary="_000_ba95837420c445699118e8adc25056f9huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OBWYfGnMxsSDjf0Z1V8QEWwNIhs>
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, 31 Jul 2020 15:08:57 -0000

Hi Ron,

Thanks for your comment.

We understand that the routing needs to be consistent in the network, thus as described in the current draft, the destination IP is used to determine the next hop, VTN-ID is for forwarding behaviors associated with this next hop.

Hope this helps.

Best regards,
Jie

From: Ron Bonica [mailto:rbonica@juniper.net]
Sent: Friday, July 31, 2020 10:49 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>; 6man@ietf.org
Subject: RE: draft-dong-6man-enhanced-vpn-vtn-id-01

Hi Jimmie,

My main concern is routing loops. If the destination address determines the next hop and the VTNI determines forwarding behavior on the interface to the next-hop, routing loops are not a problem.

However, if the VTNI has a part in determining the next hop,  routing loops become an concern.

                                                     Ron




Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: Friday, July 31, 2020 5:00 AM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; 6man@ietf.org<mailto:6man@ietf.org>
Subject: RE: draft-dong-6man-enhanced-vpn-vtn-id-01

[External Email. Be cautious of content]

Hi Ron,

What you described (identify a virtual interface which can have bandwidth reserved) is one usage of VTN-ID. As it provides an identifier of a virtual network in packet, it may also be associated with other attributes and behaviors of the virtual network.

Best regards,
Jie

From: Ron Bonica [mailto:rbonica@juniper.net]
Sent: Friday, July 31, 2020 1:12 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; 6man@ietf.org<mailto:6man@ietf.org>
Subject: RE: draft-dong-6man-enhanced-vpn-vtn-id-01

Jimmy,

Please tell me if I am understanding this correctly.....

On each node, the IPv6 destination address identifies a set of virtual interfaces to the next hop. Each virtual interface:

-        Originates on the same physical interface on the local node
-        Terminates on the same physical interface on the next-hop node

The VTNI determines which virtual interface the packet traverses. The DSCP bits determine scheduling, queuing and drop profiles on each virtual interface.

Do I have this right?

Also, is there a bandwidth reservation associated with each virtual interface?

                                                            Ron




Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: Wednesday, July 29, 2020 3:43 AM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; 6man@ietf.org<mailto:6man@ietf.org>
Subject: RE: draft-dong-6man-enhanced-vpn-vtn-id-01

[External Email. Be cautious of content]

Hi Ron,

Thanks for your review and comment.

Your interpretation is in the right direction, while the relationship between VTN-ID and DSCP could be considered as in a hierarchical manner, and each is for different purpose. VTN-ID is used to consistently identify a virtual network with a group of network resources allocated from the network, there is no priority difference between VTNs. DSCP is used to provide class (priority) based traffic differentiation, which can be used within VTN.

Hope this helps.

Best regards,
Jie

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Wednesday, July 29, 2020 1:45 AM
To: 6man@ietf.org<mailto:6man@ietf.org>
Subject: draft-dong-6man-enhanced-vpn-vtn-id-01

Co-authors,

In Section 4.2, you say:

"There can be different implementations of reserving local network
   resources to the VTNs.  On each interface, the resources allocated to
   a particular VTN can be seen as a virtual sub-interface with
   dedicated bandwidth and other associated resources.  In packet
   forwarding, the IPv6 destination address of the received packet is
   used to identify the next-hop and the outgoing interface, and the VTN
   ID is used to further identify the virtual sub-interface which is
   associated with the VTN on the outgoing interface."

I interpret this as meaning:

-        The IPv6 destination address is solely responsible for identifying the IP next hop
-        The VTNI, along with the DSCP bits, determine how the packet is forwarded to the next-hop

So, I can think of the VTNI as "more DSCP bits".

Do I have that right?

                                                                  Ron




Juniper Business Use Only