Wearing a cloud provider hat, I have to agree with David, Whilst I can think of a number of uses for marking the overlay, I wouldn't want to limit us to not being able to do customer or core controlled service CoS should we want to.
Dave. On 28/06/2012 21:46, "[email protected]" <[email protected]> wrote: >Ok, but NVO3 is applicable to (and the overlays will be deployed in) >a lot more than just cloud provider environments. > >Thanks, >--David > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >>Balus, >> Florin Stelian (Florin) >> Sent: Thursday, June 28, 2012 4:14 PM >> To: Black, David; [email protected] >> Subject: Re: [nvo3] NVO3 Data Plane Requirements: QoS identifier in >>overlay >> header? >> >> >> We can consider changing in the next version SHOULD to a MAY if that is >>the WG >> consensus. Would like to hear though on the list or during the session >>in >> Vancouver from more people, ideally from a cloud provider environment. >> >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] >> > Sent: Thursday, June 28, 2012 12:34 PM >> > To: Balus, Florin Stelian (Florin); [email protected] >> > Subject: RE: [nvo3] NVO3 Data Plane Requirements: QoS identifier in >> > overlay header? >> > >> > Florin, >> > >> > I think I see where our views diverge. If one considers a service >> > provider environment running a VPN technology that supports both >> > service and underlay CoS, then one has three CoS layers, especially >> > when the underlay CoS field has expressibility limits (e.g., MPLS >> > support for DiffServ is constrained by the 3-bit size of the EXP field >> > and other competing uses for those bits). >> > >> > OTOH, there are plenty of other environments for nvo3 overlays where >> > there aren't three CoS layers and there aren't serious expressibility >> > problems in the outermost CoS field (e.g., the DSCP field in the IP >> > header imposes no limits on DiffServ expressibility beyond those in >>the >> > basic DiffServ architecture). Enterprise environments are among those >> > that provide examples. >> > IPsec VPNs also provide examples under the assumption that the tunnels >> > are end-to-end wrt boundaries between service provider networks. >> > >> > So while I agree that there are environments in which the CoS field >>can >> > be "useful", that's as far as I would go. Specifically, I don't think >> > the across-the-board "SHOULD" in the draft is justifiable or >> > appropriate in general. >> > >> > Thanks, >> > --David >> > >> > > -----Original Message----- >> > > From: [email protected] [mailto:[email protected]] On Behalf >> > > Of Balus, Florin Stelian (Florin) >> > > Sent: Thursday, June 28, 2012 2:06 PM >> > > To: Black, David; [email protected] >> > > Subject: Re: [nvo3] NVO3 Data Plane Requirements: QoS identifier in >> > > overlay header? >> > > >> > > >> > > David, >> > > >> > > Sorry about the delay, was out in vacation for a while and I missed >> > > your email. >> > > >> > > In section 3.3.1.2 the text above the paragraph you mention below is >> > > describing why this is required. Let me try a practical explanation. >> > > When using different overlay/VPN technologies Service Providers have >> > > available CoS indicators at 3 levels: >> > > - customer/tenant controlled CoS (e.g. DSCP/dot1p bits in the inner >> > > payload) >> > > - service CoS visible in the NVE/PE (e.g. 3 exp bits in the VPN >> > > label/dot1p bits in IEEE ISID) >> > > - tunnel/core CoS visible in the NVE and Core Nodes (e.g. 3 exp bits >> > > in the tunnel label/dot1p bits in IEEE BVLAN) >> > > >> > > The last two are under the control of the Service Provider and may >>be >> > > used for different CoS schemes. For example 6 service CoS may be >>used >> > > in the NVE/PEs while only 4 may be used in the core. This could be >> > > because of available queuing/different oversubscription/number of >> > > flows/operational requirements in different network devices/admin >> > domains. >> > > >> > > CoS usage may change as the packet transitions between different SP >> > > administrative domains. At the handoff between domains there are >> > rules >> > > to map one SP CoS definition to the one for the next domain. The >> > > presence of these fields is useful because there is no need to be >> > > aware about customer CoS definitions to map to the next CoS domain: >> > > i.e. if I am domain 2 network admin I just need to understand domain >> > 1 >> > > CoS definition not how their individual customers marked their CoS. >> > > Also there is no need to dig on the next encap level. >> > > >> > > I hope this helps clarify the text... >> > > >> > > Florin >> > > >> > > > -----Original Message----- >> > > > From: [email protected] [mailto:[email protected]] On >> > Behalf >> > > > Of [email protected] >> > > > Sent: Monday, June 18, 2012 5:05 PM >> > > > To: [email protected] >> > > > Subject: [nvo3] NVO3 Data Plane Requirements: QoS identifier in >> > > > overlay header? >> > > > >> > > > Catching up ... >> > > > >> > > > In draft-bl-nvo3-dataplane-requirements-00.txt, the last paragraph >> > > > in Section 3.3.1.2. Service QoS identifier says: >> > > > >> > > > Support for NVE Service CoS SHOULD be provided through a QoS >> > field, >> > > > inside the NVO3 overlay header. Examples of service CoS >>provided >> > > > part of the service tag are 802.1p and DE bits in the VLAN and >> > PBB >> > > > ISID tags and MPLS EXP bits in the VPN labels. >> > > > >> > > > Why "inside the NVO3 overlay header"? Earlier in the section, IP >> > > > DSCP and Ethernet 802.1p are mentioned as examples of CoS (Class >>of >> > > > Service) indicators and QoS fields - when used between NVEs, these >> > > > (obviously) belong in the outer IP and outer Ethernet headers >> > respectively. >> > > > >> > > > What's the rationale for an additional QoS field in the overlay >> > header? >> > > > >> > > > Thanks, >> > > > --David >> > > > ---------------------------------------------------- >> > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South >> > > > St., Hopkinton, MA 01748 >> > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> > > > [email protected] Mobile: +1 (978) 394-7754 >> > > > ---------------------------------------------------- >> > > > >> > > > >> > > > _______________________________________________ >> > > > 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 > >_______________________________________________ >nvo3 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
