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

WFM

Yours Irrespectively,

John

From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Benson Schliesser
Sent: Thursday, November 13, 2014 10:16 PM
To: sarikaya@ieee.org
Cc: nvo3@ietf.org; Dino Farinacci; draft-xia-nvo3-vxlan-qosmarking@tools.ietf.org
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

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

[cid:image001.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
November 13, 2014 at 4:23 PM
Hi Benson,
On Thu, Nov 13, 2014 at 8:08 PM, Benson Schliesser <bensons@queuefull.net<mailto:bensons@queuefull.net>> 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

[cid:image002.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
November 13, 2014 at 4:00 PM

On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <bensons@queuefull.net<mailto:bensons@queuefull.net>> 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

[cid:image003.jpg@01CFFF97.855357D0]
Dino Farinacci<mailto:farinacci@gmail.com>
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:

[cid:image004.png@01CFFF97.855357D0]

Dino
[cid:image005.jpg@01CFFF97.855357D0]
Benson Schliesser<mailto:bensons@queuefull.net>
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
[cid:image003.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
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
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3
[cid:image003.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
November 10, 2014 at 5:47 PM

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter

<brian.e.carpenter@gmail.com><mailto:brian.e.carpenter@gmail.com> 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

nvo3@ietf.org<mailto:nvo3@ietf.org>

https://www.ietf.org/mailman/listinfo/nvo3

[cid:image005.jpg@01CFFF97.855357D0]
Benson Schliesser<mailto:bensons@queuefull.net>
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
[cid:image002.jpg@01CFFF97.855357D0]
Dino Farinacci<mailto:farinacci@gmail.com>
November 12, 2014 at 8:06 PM

Exactly. Thanks Benson.

Dino
[cid:image005.jpg@01CFFF97.855357D0]
Benson Schliesser<mailto:bensons@queuefull.net>
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
[cid:image002.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
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
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3

[cid:image006.jpg@01CFFF97.855357D0]
Benson Schliesser<mailto:bensons@queuefull.net>
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

[cid:image001.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
November 13, 2014 at 4:00 PM

On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <bensons@queuefull.net<mailto:bensons@queuefull.net>> 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

[cid:image002.jpg@01CFFF97.855357D0]
Dino Farinacci<mailto:farinacci@gmail.com>
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:

[cid:image004.png@01CFFF97.855357D0]

Dino
[cid:image005.jpg@01CFFF97.855357D0]
Benson Schliesser<mailto:bensons@queuefull.net>
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
[cid:image002.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
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
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3
[cid:image002.jpg@01CFFF97.855357D0]
Behcet Sarikaya<mailto:sarikaya2012@gmail.com>
November 10, 2014 at 5:47 PM

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter

<brian.e.carpenter@gmail.com><mailto:brian.e.carpenter@gmail.com> 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

nvo3@ietf.org<mailto:nvo3@ietf.org>

https://www.ietf.org/mailman/listinfo/nvo3

[cid:image006.jpg@01CFFF97.855357D0]
Benson Schliesser<mailto:bensons@queuefull.net>
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
[cid:image001.jpg@01CFFF97.855357D0]
Dino Farinacci<mailto:farinacci@gmail.com>
November 12, 2014 at 8:06 PM

Exactly. Thanks Benson.

Dino

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

Attachment: image001.jpg

Attachment: image002.jpg

Attachment: image003.jpg

Attachment: image004.png

Attachment: image005.jpg

Attachment: image006.jpg