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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 05 August 2020 01:22 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 BDC1A3A121D for <ipv6@ietfa.amsl.com>; Tue, 4 Aug 2020 18:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4xk_oE63g55J for <ipv6@ietfa.amsl.com>; Tue, 4 Aug 2020 18:22:41 -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 CEDDF3A1219 for <6man@ietf.org>; Tue, 4 Aug 2020 18:22:40 -0700 (PDT)
Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A30C69952D0433A65FA1 for <6man@ietf.org>; Wed, 5 Aug 2020 02:22:37 +0100 (IST)
Received: from dggeme751-chm.china.huawei.com (10.3.19.97) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 5 Aug 2020 02:22:36 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme751-chm.china.huawei.com (10.3.19.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 5 Aug 2020 09:22:34 +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; Wed, 5 Aug 2020 09:22:34 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "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/K2vKekKjAAb4TWQ///sPgD//KwywIAGTgQA//8i0QCAATsYgP/5zFjg
Date: Wed, 05 Aug 2020 01:22:34 +0000
Message-ID: <9b35442d69ca4a2fa915ca6febaf4c39@huawei.com>
References: <DM6PR05MB6348F564EE4A9470553B0A8AAE730@DM6PR05MB6348.namprd05.prod.outlook.com> <d579687dd60141b3902706539292a0c4@huawei.com> <3742736f-14b5-ab76-3e9d-d9ad0395eca2@joelhalpern.com> <f9388ba147e147679ec546922c109b07@huawei.com> <c502b7a5-2cf9-78a4-5bf3-262febc7fb22@joelhalpern.com> <53763399e1674e4ca6f23fefc4816d64@huawei.com> <e88c4e04-2968-1089-2ffe-d9e61e9b6686@joelhalpern.com>
In-Reply-To: <e88c4e04-2968-1089-2ffe-d9e61e9b6686@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.143]
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/1UeEgIV_JqiaxArZmjhpRXJ6iKM>
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: Wed, 05 Aug 2020 01:22:43 -0000

Hi Joel, 

Sorry for the late reply. I agree that the mechanism proposed with SR can also provide the required functionality and is one option to do this. 

This document provides another option based on IPv6, which may or may not be coupled with SR. Also when used with SRv6, this mechanism can leverage the IPv6 extension header mechanism to carry information which needs to be processed hop-by-hop along the path, so that the function of different fields in packet header can be decoupled or combined as needed. 

Best regards,
Jie

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Saturday, August 1, 2020 12:44 AM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; 6man@ietf.org
> Subject: Re: draft-dong-6man-enhanced-vpn-vtn-id-01
> 
> If you coupled this with SR, you would get most of what you want.
> And for those cases where you needed more, you could use a destination
> option.
> 
> Otherwise, you are going to have some other hard to guess dependencies to
> make this work meaningfully.
> 
> Yours,
> Joel
> 
> On 7/31/2020 12:32 PM, Dongjie (Jimmy) wrote:
> > Hi Joel,
> >
> > Thanks for your comment, I missed this before the meeting.
> >
> > We understand forwarding loops must be avoided. As mentioned in the
> draft and my presentation, the next hop is determined using the destination
> IP field, and the VTN-ID is used to determine the set of network resources
> associated with the VTN for packet processing and forwarding to the
> determined next hop.
> >
> > Hope this helps.
> >
> > Best regards,
> > Jie
> >
> >> -----Original Message-----
> >> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]
> >> Sent: Friday, July 31, 2020 7:08 PM
> >> To: Dongjie (Jimmy) <jie.dong@huawei.com>; 6man@ietf.org
> >> Subject: Re: draft-dong-6man-enhanced-vpn-vtn-id-01
> >>
> >> Looking at the draft, and reading your note, you seem to be asking
> >> for a hop-by-hop option header which is to be modify the forwarding
> >> selection in some unspecified fashion.
> >>
> >> This kind of open-ended modification of core 6man IPv6 behavior seems
> >> a bad idea.
> >> Having a modification to the forwarding behavior that may not be
> >> noticed or acted on by all routers in the path seems a recipe for
> forwarding loops.
> >>
> >> And it is not at all clear that there is any need for this given MPLS, SRH,
> CRH.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 7/31/2020 4:47 AM, Dongjie (Jimmy) wrote:
> >>> Hi Joel,
> >>>
> >>> As explained in my previous mail, the role of DSCP and VTN-ID are
> different.
> >> VTN-ID can be used as a in packet identifier of the VTN, and it can
> >> be used in a hierarchical manner with DSCP and other fields for
> >> packet forwarding. Thus it is not to extend or replace DSCP.
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>> -----Original Message-----
> >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>>> Sent: Wednesday, July 29, 2020 9:40 PM
> >>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; 6man@ietf.org
> >>>> Subject: Re: draft-dong-6man-enhanced-vpn-vtn-id-01
> >>>>
> >>>> It is unclear to me whether you are asserting that DSCP is
> >>>> insufficiently granular to represent the desired treatment, or
> >>>> whether youa re asking for an in-packet identifier that does not
> >>>> affect
> >> packet queueing or forwarding?
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 7/29/2020 3:43 AM, Dongjie (Jimmy) wrote:
> >>>>> 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
> >>>>> *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
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> -- 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
> > --------------------------------------------------------------------
> >