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

[Bob Hinden <[e-mail]>]

Joel,

> On Aug 4, 2020, at 10:15 PM, Joel M. Halpern <[e-mail]> wrote:
> 
> You are asking for a new hop-by-hop IPv6 header with forwarding impact.
> Given that we have an Internet Standard RFC saying that new hop-by-hop headers are not a good idea, the bar for this seems pretty high.

My read of the draft is that is is proposing a new header option, not a new header.

   3.  New IPv6 Extension Header Option for VTN

   A new option type of IPv6 extension headers is defined to carry the
   Virtual Transport Network Identifier (VTN ID) in IPv6 packet header.
   Its format is shown as below:

              Option   Option       Option
               Type   Data Len       Data
            +--------+--------+--------+--------+
            |BBCTTTTT|00000100|  4-octet VTN ID |
            +--------+--------+--------+--------+

Could be written a little clearer…

I think the rest of your questions about the need and justification would need to be answered before this could go anywhere.

Bob



> 
> First, it seems that the behavior would need to be very clearly specified.
> 
> Second, it would seem that there should be an over-riding need for the extension.
> 
> Neither of these criteria is met by the draft as it stands.
> Yours,
> Joel
> 
> On 8/4/2020 9:22 PM, Dongjie (Jimmy) wrote:
>> 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:[e-mail]]
>>> Sent: Saturday, August 1, 2020 12:44 AM
>>> To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
>>> 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:[e-mail]]
>>>>> Sent: Friday, July 31, 2020 7:08 PM
>>>>> To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
>>>>> 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:[e-mail]]
>>>>>>> Sent: Wednesday, July 29, 2020 9:40 PM
>>>>>>> To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
>>>>>>> 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:[e-mail]] *On Behalf Of *Ron
>>>>>>>> Bonica
>>>>>>>> *Sent:* Wednesday, July 29, 2020 1:45 AM
>>>>>>>> *To:* [e-mail]
>>>>>>>> *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 [e-mail]
>>>>>>>> Administrative
>>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> --
>>>>>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------