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

[Benson Schliesser <[e-mail]>]

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 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]
> 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]>  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]
> https://www.ietf.org/mailman/listinfo/nvo3