Hi Florin, The rules for matching/translating the QoS/CoS-related information when encapsulating and decapsulating between the virtual networks and the physical networks should definitely be mandated, and there are lots of existing docs addressing those. I am not so keen on defining yet another CoS/QoS scheme in the overlay header. Sure, the burden is on the physical infrastructure to respect the existing QoS/CoS marking when traversing devices bridging different technologies, but that problem exists today (or preferably has guidance already) independent of NVO3. Agree with David on this one.
Thanks, Yushun -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Balus, Florin Stelian (Florin) Sent: Thursday, June 28, 2012 11:06 AM To: [email protected]; [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
