Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

[Benson Schliesser <[e-mail]>]

Hi, Behcet -

Just to conclude this topic:

I suspect that you think my question has been answered by your 
message(s), but it has not. So... At this point, I maintain my view that 
the NVO3 consensus is: there is no QoS gap that needs to be addressed in 
the overlap encap layer.

Cheers,
-Benson


> Behcet Sarikaya <mailto:[e-mail]>
> November 13, 2014 at 4:23 PM
> Hi Benson,
> On Thu, Nov 13, 2014 at 8:08 PM, Benson Schliesser 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi, Behcet -
>
>     Quoting from my previous message: "one could imagine the NVE
>     imposing an underlay DSCP in IP2,
>
> Is IP2 outer IP header? I am assuming it is.
>
>     e.g. to discriminate between tenants."
>
> Not quite. We need to decide on DSCP or 802.1Q type of QoS marking. So 
> I think it is not that simple as you say.
>
>     This seems so obvious to me that I doubt anybody has bothered to
>     write it down...
>
>     It does seem like we should document a mechanism for configuration
>     of the NVE's QoS behavior. (E.g. as part of the NVO3 control plane
>     and/or in a YANG model for NVE management) But that's a different
>     topic.
>
> This is also part of our draft.
>
>     So, back to my question: Is there actually a problem that you
>     trying to solve that cannot be solved with the existing mechanisms?
>
>     If so, then I will reconsider my beliefs about WG consensus. But
>     if not, then I don't see why we're having this conversation.
>
> Please do so.
> Regards,
> Behcet
>
>     Thanks,
>     -Benson
>
>
>>     Behcet Sarikaya <mailto:[e-mail]>
>>     November 13, 2014 at 4:00 PM
>>
>>     On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Hi, Behcet -
>>
>>         Stepping back from the conversation about bits... What is the
>>         problem that you're trying to solve, Behcet?
>>
>>         I see multiple existing QoS mechanisms both in the underlay
>>         and in the overlay, and I don't see any QoS gap that needs to
>>         be addressed in the overlap encap layer. I believe that my
>>         point of view is consistent with the WG consensus at this point.
>>
>>     I am not familiar with any QoS mechanism that is based on the
>>     tenant, i.e static mapping.
>>     Let me know which document discusses it?
>>     Thx,
>>     Behcet
>>
>>         Thanks,
>>         -Benson
>>
>>>         Dino Farinacci <mailto:[e-mail]>
>>>         November 13, 2014 at 12:02 PM
>>>>         Sorry there are no EXP bits mentioned in RFC 7348. MPLS is
>>>>         out of scope.
>>>>         EXP is 3 bits long, DSCP is 6 bits and dividing it into two
>>>>         3 bit
>>>>         pieces, I am not sure if David will like it.
>>>
>>>         I am referring to user-priority bits below:
>>>
>>>
>>>         Dino
>>>
>>>         Benson Schliesser <mailto:[e-mail]>
>>>         November 12, 2014 at 9:34 AM
>>>         Hi, Behcet -
>>>
>>>         Perhaps I'm confused about what comment (from Dino) that you
>>>         are referring to... But in general, I think of it this way:
>>>
>>>         Assuming the encap stack looks something like: IP1 / Eth1 /
>>>         VXLAN / UDP / IP2 / Eth2  (progressing L->R as inner->outer)
>>>
>>>         Then e.g. tenant VMs can mark the IP1 and Eth1 headers with
>>>         whatever appropriate markings they desire. The NVE can mark
>>>         the IP2 and Eth2 headers with whatever appropriate markings.
>>>
>>>         Specifically, one could imagine the NVE copying the IP1 DSCP
>>>         codepoint into the IP2 header. Alternatively one could
>>>         imagine the NVE imposing an underlay DSCP in IP2, e.g. to
>>>         discriminate between tenants. Possibly, one could also
>>>         imagine some kind of translation policy which maps IP1
>>>         codepoints into IP2 codepoints. And that's not even
>>>         considering mechanisms that leverage the Eth headers, use
>>>         different encap stacks, etc.
>>>
>>>         Cheers,
>>>         -Benson
>>>
>>>         Behcet Sarikaya <mailto:[e-mail]>
>>>         November 12, 2014 at 9:01 AM
>>>         Hi Dino,
>>>
>>>         Regarding your comment on copying IP header QoS bits into
>>>         VXLAN header,
>>>
>>>         note that IP packet is coming from the VMs.
>>>
>>>         Yes for dynamic marking these bits can be copied.
>>>         However, VMs may not be configured to mark these fields.
>>>
>>>         For static marking these bits can not be used because VMs
>>>         are not
>>>         aware of the VNI. So NVE has to do the static marking.
>>>
>>>         Hope this clarifies.
>>>
>>>         Regards,
>>>
>>>         Behcet
>>>
>>>         _______________________________________________
>>>         nvo3 mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/nvo3
>>>         Behcet Sarikaya <mailto:[e-mail]>
>>>         November 10, 2014 at 5:47 PM
>>>         On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
>>>         <[e-mail]>  <mailto:[e-mail]>  wrote:
>>>>         [resend with corrected address, sorry]
>>>>
>>>>         Hi,
>>>>
>>>>>           The first three bits (bits 5-7) are precedence bits. They are
>>>>>           assigned according to [RFC0791]. Precedence values '110' and '111'
>>>>>           are selected for routing traffic.
>>>>>
>>>>>           The last three bits (bits 8-10) are class selector bits. Thet are
>>>>>           assigned as follows:
>>>>>
>>>>>         001 - BK or background traffic
>>>>         ...
>>>>>         As can be seen the markings are the same as in IEEE 802.1p...
>>>>         This is not in any way compatible with RFC 2474, which also made the
>>>>         relevant part of RFC 791 obsolete.
>>>>
>>>>         If you want to be compatible with RFC 2474 you should not specify the
>>>>         bits at all - just say that they are exactly as defined in RFC 2474
>>>>         and the various PHB definitions that have been published.
>>>         I think that diffserv is less relevant in the context of VXLAN.
>>>
>>>>           If you
>>>>         want to be compatible with IEEE 802.1p that is a different matter,
>>>         Yes this is more relevant for VXLAN.
>>>
>>>>         but you cannot mix the two up in this way.
>>>         I now understand that we confused the two very different things.
>>>
>>>         Regards,
>>>
>>>         Behcet
>>>>              Brian
>>>>
>>>>
>>>>
>>>         _______________________________________________
>>>         nvo3 mailing list
>>>         [e-mail]  <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>     Benson Schliesser <mailto:[e-mail]>
>>     November 13, 2014 at 12:47 PM
>>     Hi, Behcet -
>>
>>     Stepping back from the conversation about bits... What is the
>>     problem that you're trying to solve, Behcet?
>>
>>     I see multiple existing QoS mechanisms both in the underlay and
>>     in the overlay, and I don't see any QoS gap that needs to be
>>     addressed in the overlap encap layer. I believe that my point of
>>     view is consistent with the WG consensus at this point.
>>
>>     Thanks,
>>     -Benson
>>
>>     Dino Farinacci <mailto:[e-mail]>
>>     November 12, 2014 at 8:06 PM
>>
>>     Exactly. Thanks Benson.
>>
>>     Dino
>>     Benson Schliesser <mailto:[e-mail]>
>>     November 12, 2014 at 9:34 AM
>>     Hi, Behcet -
>>
>>     Perhaps I'm confused about what comment (from Dino) that you are
>>     referring to... But in general, I think of it this way:
>>
>>     Assuming the encap stack looks something like: IP1 / Eth1 / VXLAN
>>     / UDP / IP2 / Eth2  (progressing L->R as inner->outer)
>>
>>     Then e.g. tenant VMs can mark the IP1 and Eth1 headers with
>>     whatever appropriate markings they desire. The NVE can mark the
>>     IP2 and Eth2 headers with whatever appropriate markings.
>>
>>     Specifically, one could imagine the NVE copying the IP1 DSCP
>>     codepoint into the IP2 header. Alternatively one could imagine
>>     the NVE imposing an underlay DSCP in IP2, e.g. to discriminate
>>     between tenants. Possibly, one could also imagine some kind of
>>     translation policy which maps IP1 codepoints into IP2 codepoints.
>>     And that's not even considering mechanisms that leverage the Eth
>>     headers, use different encap stacks, etc.
>>
>>     Cheers,
>>     -Benson
>>
>>     Behcet Sarikaya <mailto:[e-mail]>
>>     November 12, 2014 at 9:01 AM
>>     Hi Dino,
>>
>>     Regarding your comment on copying IP header QoS bits into VXLAN
>>     header,
>>
>>     note that IP packet is coming from the VMs.
>>
>>     Yes for dynamic marking these bits can be copied.
>>     However, VMs may not be configured to mark these fields.
>>
>>     For static marking these bits can not be used because VMs are not
>>     aware of the VNI. So NVE has to do the static marking.
>>
>>     Hope this clarifies.
>>
>>     Regards,
>>
>>     Behcet
>>
>>     _______________________________________________
>>     nvo3 mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/nvo3
>
>
> Benson Schliesser <mailto:[e-mail]>
> November 13, 2014 at 4:08 PM
> Hi, Behcet -
>
> Quoting from my previous message: "one could imagine the NVE imposing 
> an underlay DSCP in IP2, e.g. to discriminate between tenants."
>
> This seems so obvious to me that I doubt anybody has bothered to write 
> it down...
>
> It does seem like we should document a mechanism for configuration of 
> the NVE's QoS behavior. (E.g. as part of the NVO3 control plane and/or 
> in a YANG model for NVE management) But that's a different topic.
>
> So, back to my question: Is there actually a problem that you trying 
> to solve that cannot be solved with the existing mechanisms?
>
> If so, then I will reconsider my beliefs about WG consensus. But if 
> not, then I don't see why we're having this conversation.
>
> Thanks,
> -Benson
>
>
> Behcet Sarikaya <mailto:[e-mail]>
> November 13, 2014 at 4:00 PM
>
> On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi, Behcet -
>
>     Stepping back from the conversation about bits... What is the
>     problem that you're trying to solve, Behcet?
>
>     I see multiple existing QoS mechanisms both in the underlay and in
>     the overlay, and I don't see any QoS gap that needs to be
>     addressed in the overlap encap layer. I believe that my point of
>     view is consistent with the WG consensus at this point.
>
> I am not familiar with any QoS mechanism that is based on the tenant, 
> i.e static mapping.
> Let me know which document discusses it?
> Thx,
> Behcet
>
>     Thanks,
>     -Benson
>
>>     Dino Farinacci <mailto:[e-mail]>
>>     November 13, 2014 at 12:02 PM
>>>     Sorry there are no EXP bits mentioned in RFC 7348. MPLS is out
>>>     of scope.
>>>     EXP is 3 bits long, DSCP is 6 bits and dividing it into two 3 bit
>>>     pieces, I am not sure if David will like it.
>>
>>     I am referring to user-priority bits below:
>>
>>
>>     Dino
>>
>>     Benson Schliesser <mailto:[e-mail]>
>>     November 12, 2014 at 9:34 AM
>>     Hi, Behcet -
>>
>>     Perhaps I'm confused about what comment (from Dino) that you are
>>     referring to... But in general, I think of it this way:
>>
>>     Assuming the encap stack looks something like: IP1 / Eth1 / VXLAN
>>     / UDP / IP2 / Eth2  (progressing L->R as inner->outer)
>>
>>     Then e.g. tenant VMs can mark the IP1 and Eth1 headers with
>>     whatever appropriate markings they desire. The NVE can mark the
>>     IP2 and Eth2 headers with whatever appropriate markings.
>>
>>     Specifically, one could imagine the NVE copying the IP1 DSCP
>>     codepoint into the IP2 header. Alternatively one could imagine
>>     the NVE imposing an underlay DSCP in IP2, e.g. to discriminate
>>     between tenants. Possibly, one could also imagine some kind of
>>     translation policy which maps IP1 codepoints into IP2 codepoints.
>>     And that's not even considering mechanisms that leverage the Eth
>>     headers, use different encap stacks, etc.
>>
>>     Cheers,
>>     -Benson
>>
>>     Behcet Sarikaya <mailto:[e-mail]>
>>     November 12, 2014 at 9:01 AM
>>     Hi Dino,
>>
>>     Regarding your comment on copying IP header QoS bits into VXLAN
>>     header,
>>
>>     note that IP packet is coming from the VMs.
>>
>>     Yes for dynamic marking these bits can be copied.
>>     However, VMs may not be configured to mark these fields.
>>
>>     For static marking these bits can not be used because VMs are not
>>     aware of the VNI. So NVE has to do the static marking.
>>
>>     Hope this clarifies.
>>
>>     Regards,
>>
>>     Behcet
>>
>>     _______________________________________________
>>     nvo3 mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/nvo3
>>     Behcet Sarikaya <mailto:[e-mail]>
>>     November 10, 2014 at 5:47 PM
>>     On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
>>     <[e-mail]>  <mailto:[e-mail]>  wrote:
>>>     [resend with corrected address, sorry]
>>>
>>>     Hi,
>>>
>>>>       The first three bits (bits 5-7) are precedence bits. They are
>>>>       assigned according to [RFC0791]. Precedence values '110' and '111'
>>>>       are selected for routing traffic.
>>>>
>>>>       The last three bits (bits 8-10) are class selector bits. Thet are
>>>>       assigned as follows:
>>>>
>>>>     001 - BK or background traffic
>>>     ...
>>>>     As can be seen the markings are the same as in IEEE 802.1p...
>>>     This is not in any way compatible with RFC 2474, which also made the
>>>     relevant part of RFC 791 obsolete.
>>>
>>>     If you want to be compatible with RFC 2474 you should not specify the
>>>     bits at all - just say that they are exactly as defined in RFC 2474
>>>     and the various PHB definitions that have been published.
>>     I think that diffserv is less relevant in the context of VXLAN.
>>
>>>       If you
>>>     want to be compatible with IEEE 802.1p that is a different matter,
>>     Yes this is more relevant for VXLAN.
>>
>>>     but you cannot mix the two up in this way.
>>     I now understand that we confused the two very different things.
>>
>>     Regards,
>>
>>     Behcet
>>>          Brian
>>>
>>>
>>>
>>     _______________________________________________
>>     nvo3 mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/nvo3
>
>
> Benson Schliesser <mailto:[e-mail]>
> November 13, 2014 at 12:47 PM
> Hi, Behcet -
>
> Stepping back from the conversation about bits... What is the problem 
> that you're trying to solve, Behcet?
>
> I see multiple existing QoS mechanisms both in the underlay and in the 
> overlay, and I don't see any QoS gap that needs to be addressed in the 
> overlap encap layer. I believe that my point of view is consistent 
> with the WG consensus at this point.
>
> Thanks,
> -Benson
>
> Dino Farinacci <mailto:[e-mail]>
> November 12, 2014 at 8:06 PM
>
> Exactly. Thanks Benson.
>
> Dino