On Wed, Nov 12, 2014 at 3:05 PM, Black, David <[email protected]> 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:[email protected]] > *Sent:* Wednesday, November 12, 2014 4:03 PM > *To:* Black, David > *Cc:* [email protected]; [email protected] > > *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 protected]> 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 protected]] *On Behalf Of *Larry Kreeger > (kreeger) > *Sent:* Wednesday, November 12, 2014 3:27 PM > *To:* Osama Zia; Benson Schliesser; [email protected] > > > *Cc:* [email protected]; Dino Farinacci; > [email protected] > *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 protected]> > *Date: *Wednesday, November 12, 2014 10:20 AM > *To: *Benson Schliesser <[email protected]>, "[email protected]" < > [email protected]> > *Cc: *"[email protected]" <[email protected]>, Dino Farinacci <[email protected]>, > "[email protected]" < > [email protected]> > *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 protected] <[email protected]>] *On > Behalf Of *Benson Schliesser > *Sent:* Wednesday, November 12, 2014 11:34 AM > *To:* [email protected] > *Cc:* [email protected]; Dino Farinacci; > [email protected] > *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* <[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
