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

[Behcet Sarikaya <[e-mail]>]

On Tue, Dec 16, 2014 at 4:26 PM, Black, David <[e-mail]> wrote:

>  Hmm, in http://www.ietf.org/mail-archive/web/nvo3/current/msg04211.html,
>
> one of our WG chairs wrote:
>
>
>

I talked offline with Benson on this.
The draft authors had not asked for WG adoption yet.
Where does the consensus issue come into picture, I don't understand.
I-Ds can be discussed freely and revised accordingly. This is what IETF
does.

I am asking Benson to clarify his statement on the consensus.
Some people may have expressed opinions on an earlier version but now we
have Erik's challenge on tenant-based QoS. The new version is on this, so I
request fair treatment of this new version.

 Benson, please clarify!

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

Would you be kind enough to reply Erik's mail? As a diffserv expert you
probably can answer this best.

Please do so.



>  If NVO3 is not interested in this draft, what’s the purpose of further
> work on it?
>
>
These are biased statements.

Regards,

Behcet

>
>
> Thanks,
> --David
>
>
>
> *From:* nvo3 [mailto:[e-mail]] *On Behalf Of *Behcet Sarikaya
> *Sent:* Tuesday, December 16, 2014 12:11 PM
> *To:* Erik Nordmark; Brian E Carpenter
> *Cc:* Benson Schliesser; [e-mail]; Dino Farinacci;
> [e-mail]
> *Subject:* Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt
>
>
>
>
>
> On Thu, Nov 13, 2014 at 9:06 PM, Erik Nordmark <[e-mail]> wrote:
>
> On 11/13/14 4:00 PM, Behcet Sarikaya wrote:
>
>
>
> 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?
>
>
> Google search points me at rfc2983, rfc6040; latter is for ECN.
>
> There might be other RFCs.
>
>
>
>
>
> Sorry for this belated reply.
>
>
>
> I agree that there doesn't seem to be another document on tenant-based
> QoS. I read RFC 2983, certainly it is not.
>
>
>
> This is possibly because multi tenancy is a new concept in IETF introduced
> by nvo3.
>
>
>
> Brian Carpenter once suggested to discuss this draft in tcpm, maybe this
> was the reason?
>
>
>
> We are ready to present it in tcpm and discuss this concept with QoS
> experts in tcpm.
>
>
>
> Having said that I don't take this comment as negative. I think it is a
> valid point.
>
>
>
> Regards,
>
>
>
> Behcet
>
>
>
>    Erik
>
>
>
>
>
>
> 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 list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
>
> _______________________________________________
>
> nvo3 mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>