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

[Behcet Sarikaya <[e-mail]>]

Hi Benson,
On Thu, Nov 13, 2014 at 8:08 PM, Benson Schliesser <[e-mail]>
wrote:
>
> Hi, Behcet -
>
> Quoting from my previous message: "one could imagine the NVE imposing an
> underlay DSCP in IP2, e.g. to discriminate between tenants."
>
>
No it is not the issue of coping DSCP from IP1 to IP2 especially in tenant
based QoS.
How can a DC operator apply QoS on each tenant separately when IP1 is
created by a VM that does not know the VNI?


> 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?
>
>
Yes there is. For example, tenant based QoS can only be done at the time
the NVE receives VM packet because it is the NVE that adds VNI value.

I suggest people to please read Rev. 02 of our draft.

In this version we also address QoS framework in VXLAN or the overlay
network as you call it.



> 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.
>
>
I think this should be reconsidered in view of Rev. 02 and the above
arguments.


Regards,


> Thanks,
> -Benson
>
>
>   Behcet Sarikaya <[e-mail]>
>  November 13, 2014 at 4:00 PM
>
> On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <[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 <[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 <[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 <[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]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>   Behcet Sarikaya <[e-mail]>
>>  November 10, 2014 at 5:47 PM
>>
>> On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter<[e-mail]> <[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 [e-mail]://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>   Benson Schliesser <[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 <[e-mail]>
>  November 12, 2014 at 8:06 PM
>
> Exactly. Thanks Benson.
>
> Dino
>   Benson Schliesser <[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 <[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]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>