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
