On Tue, Dec 16, 2014 at 4:26 PM, Black, David <[email protected]> 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:[email protected]] *On Behalf Of *Behcet Sarikaya > *Sent:* Tuesday, December 16, 2014 12:11 PM > *To:* Erik Nordmark; Brian E Carpenter > *Cc:* Benson Schliesser; [email protected]; Dino Farinacci; > [email protected] > *Subject:* Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosmarking-01.txt > > > > > > On Thu, Nov 13, 2014 at 9:06 PM, Erik Nordmark <[email protected]> wrote: > > On 11/13/14 4:00 PM, Behcet Sarikaya wrote: > > > > On Thu, Nov 13, 2014 at 4:47 PM, Benson Schliesser <[email protected]> > 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* <[email protected]> > > 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* <[email protected]> > > 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* <[email protected]> > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > *Behcet Sarikaya* <[email protected]> > > November 10, 2014 at 5:47 PM > > On Mon, Nov 10, 2014 at 9:41 PM, Brian E Carpenter > > <[email protected]> <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
