Dave, Just to make sure the requirement is understood correctly I added some clarification below...
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > David Freedman > Sent: Thursday, June 28, 2012 2:38 PM > To: [email protected] > Subject: Re: [nvo3] NVO3 Data Plane Requirements: QoS identifier in > overlay header? > > 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. [FB>] The current text in the document does not exclude the customer or core controlled service CoS. We are talking about a CoS field in the service tag that may be used for marking/transporting the service CoS. One may choose at every hop the header field used in the packet header to derive the CoS treatment: i.e. the tunnel header, the service tag or even the header from the customer payload - see my initial text for use cases. The requirement is tagged as a SHOULD not as a MUST anyhow. > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
