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
