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

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Nov 2014 21:47:33 -0600

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
<[email-masked]> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2014 13:01:03 -0600

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

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 12 Nov 2014 09:34:14 -1000

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:[email-masked]>
> November 12, 2014 at 9:01 AM
> Hi Dino,
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
> Behcet Sarikaya <mailto:[email-masked]>
> November 10, 2014 at 5:47 PM
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Osama Zia <[email-masked]>
Date: Wed, 12 Nov 2014 20:20:31 +0000

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:[email-masked]] On Behalf Of Benson Schliesser
Sent: Wednesday, November 12, 2014 11:34 AM
To: [email-masked]
Cc: [email-masked]; Dino Farinacci;
[email-masked]
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

 <mailto:[email-masked]> Behcet Sarikaya

Hi Dino,

Hope this clarifies.

Regards,

Behcet

_______________________________________________
nvo3 mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/nvo3

 <mailto:[email-masked]> Behcet Sarikaya

On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter
 <mailto:[email-masked]> <[email-masked]> wrote:

Hi,

 

...

 

 If you

 
Regards,
 
Behcet

    Brian

_______________________________________________
nvo3 mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 12 Nov 2014 20:26:32 +0000

+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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 12, 2014 10:20 AM
To: Benson Schliesser <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Dino Farinacci <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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:[email-masked]] On Behalf Of Benson Schliesser
Sent: Wednesday, November 12, 2014 11:34 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Dino Farinacci; [email-masked]<mailto:[email-masked]>
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

Behcet Sarikaya<mailto:[email-masked]>
November 12, 2014 at 9:01 AM
Hi Dino,

Hope this clarifies.

Regards,

Behcet

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3
Behcet Sarikaya<mailto:[email-masked]>
November 10, 2014 at 5:47 PM

<[email-masked]><mailto:[email-masked]> wrote:

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Black, David" <[email-masked]>
Date: Wed, 12 Nov 2014 20:43:50 +0000

Another +1, and please see RFC 2983, which is relevant to the DiffServ aspects here.

Thanks,
--David

From: nvo3 [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Wednesday, November 12, 2014 3:27 PM
To: Osama Zia; Benson Schliesser; [email-masked]
Cc: [email-masked]; Dino Farinacci; [email-masked]
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

+1

 - Larry

I would ask this question in another way...

Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2014 15:02:35 -0600

>  Another +1, and please see RFC 2983, which is relevant to the DiffServ

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:[email-masked]] *On Behalf Of *Larry Kreeger
> (kreeger)
> *Sent:* Wednesday, November 12, 2014 3:27 PM
> *To:* Osama Zia; Benson Schliesser; [email-masked]
>
> *Cc:* [email-masked]; Dino Farinacci;
> *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 <[email-masked]>
> *Date: *Wednesday, November 12, 2014 10:20 AM
> *To: *Benson Schliesser <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Dino Farinacci <[email-masked]>,
> "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt
>
>
>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Benson Schliesser
> *Sent:* Wednesday, November 12, 2014 11:34 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; Dino Farinacci;
> *Subject:* Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt
>
>
>
> Hi, Behcet -
>
> 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* <[email-masked]>
>
>   *Behcet Sarikaya* <[email-masked]>
>
> <[email-masked]> <[email-masked]> wrote:
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 12 Nov 2014 21:05:35 +0000

> 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?

Thanks,
--David

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

On Wed, Nov 12, 2014 at 2:43 PM, Black, David <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] On Behalf Of Larry Kreeger (kreeger)
Sent: Wednesday, November 12, 2014 3:27 PM
To: Osama Zia; Benson Schliesser; [email-masked]<mailto:[email-masked]>

+1

 - Larry

Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

---

From: Andrew Qu <[email-masked]>
Date: Thu, 13 Nov 2014 01:20:57 +0000

Ditto

+1

Thanks,

Andrew

From: nvo3 [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, November 12, 2014 12:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

Thanks,
--David

+1

 - Larry

Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2014 19:58:06 -0600

On Wed, Nov 12, 2014 at 3:05 PM, Black, David <[email-masked]> wrote:

> > 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.
>
>
>
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:[email-masked]]
> *Sent:* Wednesday, November 12, 2014 4:03 PM
> *To:* Black, David
> *Cc:* [email-masked]; [email-masked]
>
> 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: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2014 20:03:26 -0600

> of using VXLAN/Geneve/GUE header bits for QoS

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

>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Benson
> Schliesser

---

From: "Black, David" <[email-masked]>
Date: Thu, 13 Nov 2014 02:08:52 +0000

> 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:[email-masked]]
Sent: Wednesday, November 12, 2014 8:58 PM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt

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:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 12, 2014 4:03 PM
To: Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

RFC 2474 says that::

Regards,

Behcet
Thanks,
--David

+1

 - Larry

Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Nov 2014 20:06:20 -1000

> Specifically, one could imagine the NVE copying the IP1 DSCP codepoint into the IP2 header. Alternatively one could

Exactly. Thanks Benson. 

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Nov 2014 13:49:07 -0600

>> Specifically, one could imagine the NVE copying the IP1 DSCP codepoint into the IP2 header. Alternatively one could

Dino, yes, but this requires DPI at the NVE, as we already talked
about in the draft as well as configuration to use diffserv.
RFC7348 does not mention any requirement for NVE to look beyond Inner
Ethernet Header into the Original Ethernet Payload in order to make
its encapsulation.

Regards,

Behcet

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Nov 2014 12:02:10 -0800

> Dino, yes, but this requires DPI at the NVE, as we already talked

No it doesn't.

> Ethernet Header into the Original Ethernet Payload in order to make

This is very simple. Let me sequence the steps on the encapsulator as well as the decapsultor:

(1) A 802.1Q frame arrives at an encapsulator.
(2) The encapsulator will encapsulate the frame with an outer IP header. It copies the EXP bits from the frame to the outer IP header TOS bits.
(3) The decapsulator receives the IP packet, it strips the outer IP header and DOESNOT copy the TOS bits to the EXP bits of the frame because the TOS field could have been changed in transit. The EXP bits, set by the originating source are perserved.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Nov 2014 15:03:50 -0600

> (3) The decapsulator receives the IP packet, it strips the outer IP header and DOESNOT copy the TOS bits to the EXP bits of the frame because the TOS field could have been changed in transit. The E…

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.

See also Brian Carpenter's comments.

Regards,

Behcet

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Nov 2014 14:02:53 -0800

> pieces, I am not sure if David will like it.

I am referring to user-priority bits below:

Dino

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 13 Nov 2014 12:47:05 -1000

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:[email-masked]>
> November 13, 2014 at 12:02 PM
> Benson Schliesser <mailto:[email-masked]>
> November 12, 2014 at 9:34 AM
> Hi, Behcet -
>
> Assuming the encap stack looks something like: IP1 / Eth1 / VXLAN / 
> UDP / IP2 / Eth2  (progressing L->R as inner->outer)
>
> 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
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Nov 2014 20:00:06 -0600

On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <[email-masked]>
wrote:

> Hi, Behcet -
>
> Stepping back from the conversation about bits... What is the problem that
> you're trying to solve, Behcet?
>
> 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 <[email-masked]>
>   Benson Schliesser <[email-masked]>
>   Behcet Sarikaya <[email-masked]>
>   Behcet Sarikaya <[email-masked]>
> On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter<[email-masked]> <[email-masked]> wrote:
>
> nvo3 mailing [email-masked]://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 13 Nov 2014 16:08:15 -1000

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

> November 13, 2014 at 4:00 PM
>
> On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser 
> <[email-masked] <mailto:[email-masked]>> 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.
>>     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
>>     <[email-masked]>  <mailto:[email-masked]>  wrote:
> November 13, 2014 at 12:47 PM
> Hi, Behcet -
>
> overlap encap layer. I believe that my point of view is consistent 
> with the WG consensus at this point.
>
> Thanks,
> -Benson
>
> November 12, 2014 at 8:06 PM
>
> Exactly. Thanks Benson.
>
> Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Nov 2014 20:23:02 -0600

Hi Benson,
On Thu, Nov 13, 2014 at 8:08 PM, Benson Schliesser <[email-masked]>
wrote:

> 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.

> Please do so.

Regards,

Behcet

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Nov 2014 17:06:42 -1000

> Let me know which document discusses it?

Google search points me at rfc2983, rfc6040; latter is for ECN.

There might be other RFCs.

    Erik

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 13 Nov 2014 17:16:27 -1000

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

> November 13, 2014 at 4:23 PM
> Hi Benson,
> On Thu, Nov 13, 2014 at 8:08 PM, Benson Schliesser 
>     Quoting from my previous message: "one could imagine the NVE
>     imposing an underlay DSCP in IP2,
>
> 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.
>
>     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
>
>
>>         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.
>>>         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)
>>>
>>>         whatever appropriate markings they desire. The NVE can mark
>>>         the IP2 and Eth2 headers with whatever appropriate markings.
>>>
>>>         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
>>>
>>     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
> 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."
>
> 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
>
>

---

From: John E Drake <[email-masked]>
Date: Fri, 14 Nov 2014 04:14:10 +0000

WFM

Yours Irrespectively,

John

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

Hi, Behcet -

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:[email-masked]>
November 13, 2014 at 4:23 PM
Hi Benson,
On Thu, Nov 13, 2014 at 8:08 PM, Benson Schliesser <[email-masked]<mailto:[email-masked]>> 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."
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.

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

On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <[email-masked]<mailto:[email-masked]>> 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:[email-masked]>

Dino
Benson Schliesser<mailto:[email-masked]>
November 12, 2014 at 9:34 AM
Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

Benson Schliesser<mailto:[email-masked]>
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:[email-masked]>
November 12, 2014 at 8:06 PM

Exactly. Thanks Benson.

Dino
Benson Schliesser<mailto:[email-masked]>
November 12, 2014 at 9:34 AM
Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Benson Schliesser<mailto:[email-masked]>
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

On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <[email-masked]<mailto:[email-masked]>> 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:[email-masked]>

Dino
Benson Schliesser<mailto:[email-masked]>
November 12, 2014 at 9:34 AM
Hi, Behcet -

Cheers,
-Benson

Hope this clarifies.

Regards,

Behcet

Hi,

 assigned as follows:

...

 If you

Regards,

Behcet

    Brian

nvo3 mailing list

Benson Schliesser<mailto:[email-masked]>
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:[email-masked]>
November 12, 2014 at 8:06 PM

Exactly. Thanks Benson.

Dino