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

["Black, David" <[e-mail]>]

> Because using diffserv at the host level or VM level in our case is a local policy issue. Hosts or VMs are not required to
> diffserv mark the packets be it at the outer IP header or VXLAN header.

As noted in a response to another message, the outer IP header suffices, so just use that and don’t modify VXLAN:

> This I think makes sense. We can change the marking place and move it to IP or Ethernet header.

Thanks,
--David

From: Behcet Sarikaya [mailto:[e-mail]]
Sent: Wednesday, November 12, 2014 8:58 PM
To: Black, David
Cc: [e-mail]; [e-mail]
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt


On Wed, Nov 12, 2014 at 3:05 PM, Black, David <[e-mail]<mailto:[e-mail]>> wrote:
 > A differentiated services boundary may be co-located with a host, subject to local policy.
 >
> So using diffserv is an option that needs to be set in VXLAN, so far we did not say anything on this in the draft.

How does that conclusion follow from the first statement?

Because using diffserv at the host level or VM level in our case is a local policy issue. Hosts or VMs are not required to diffserv mark the packets be it at the outer IP header or VXLAN header.



Thanks,
--David

From: Behcet Sarikaya [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, November 12, 2014 4:03 PM
To: Black, David
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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


On Wed, Nov 12, 2014 at 2:43 PM, Black, David <[e-mail]<mailto:[e-mail]>> wrote:
Another +1, and please see RFC 2983, which is relevant to the DiffServ aspects here.



RFC 2474 says that::

A differentiated services boundary may be co-located with a host, subject to local policy.

So using diffserv is an option that needs to be set in VXLAN, so far we did not say anything on this in the draft.

Regards,

Behcet
Thanks,
--David

From: nvo3 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Larry Kreeger (kreeger)
Sent: Wednesday, November 12, 2014 3:27 PM
To: Osama Zia; Benson Schliesser; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; Dino Farinacci; [e-mail]<mailto:[e-mail]>
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

+1

I don't ever see a case where packets are being forwarded with only the VXLAN header and not the outer IP header, or IP/Ethernet headers.

 - Larry

From: Osama Zia <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 12, 2014 10:20 AM
To: Benson Schliesser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Dino Farinacci <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

I would ask this question in another way…

At what point do we need to make QoS decisions based on VXLAN header? I do not see any.

From VM to NVE it can be done in IP/Ethernet. From NVE to rest of the network again it can be based on IP/Ethernet header. I do not see a value of using VXLAN/Geneve/GUE header bits for QoS

From: nvo3 [mailto:[e-mail]] On Behalf Of Benson Schliesser
Sent: Wednesday, November 12, 2014 11:34 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Dino Farinacci; [e-mail]<mailto:[e-mail]>
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

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

[cid:[e-mail]160]
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
[cid:[e-mail]160]
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