Brian, I agree that diffserv alone would not address the condition if more granular QoS/CoS is required. If we think of NVE as PE a device then I believe we have the necessary components.
Ingress classification on the VAP as well as the potential to classify on the VNIF will handle mapping from header details to appropriate queue. Marking of outer tunnel header as we do today with exp bits or gre ip header will ensure end to end PHB. The missing link is how to handle the condition you describe; two streams, same traffic class, different tunnels. Maybe the provider should provide distinction of queue/class if there is an expectation of behavior differences. Or we will need to use the second VNID (briefly described in the framework doc) as a means to provide greater differentiation. Building a form of call admission control for tenant streams to the network is looking for a world of hurt. IntServ can be our testament to this truth. ;) Kind regards, Truman Boyes On Jul 12, 2012, at 3:04 AM, Brian E Carpenter <[email protected]> wrote: > Truman, > > On 12/07/2012 05:01, Truman Boyes wrote: >> Hi Selvam, >> >> >> Yes I agree this does need to be discussed. There could be a couple methods >> in achieving this: >> >> >> - The virtual bridge on the hypervisor of the NVE can handle the >> rate-limiting ingress or egress from the TES on the VAP. >> - If the encapsulation is IP between the NVE, we could ensure that >> appropriate DSCP/ToS markings are copied into the IP header based on >> configured mappings of tenant QoS priority. This way standard physical >> network devices can also appropriately provide the intended per hop >> behavior. >> - The IP ToS or DSCP values from packets generated from TES could be >> simply copied into encapsulation IP header; if a corresponding VAP or >> policy existed on the VNI. > > Diffserv alone cannot ensure sharing between two competing streams > of the same class of traffic that happen to occur in two different tunnels. > You would definitely need admission control of some kind at *all* tunnel > ingresses, as far as I can see. Whether that scales is another question. > > FYI, diffserv handling in tunnels is documented in RFC 2983. > > Brian Carpenter > >> >> Just some quick thoughts on this at midnight ... >> >> Kind regards, >> Truman >> >> >> On Wed, Jul 11, 2012 at 7:55 PM, Selvam Ramanathan < >> [email protected]> wrote: >> >>> Hi Truman, **** >>> >>> ** ** >>> >>> Lets Take a case where Tenant A and Tenant B are configured. **** >>> >>> Since Tenant A and Tenant B are using the same physical network over the >>> multiple overlay network , **** >>> >>> How do we make Sure Tenant A gets the bandwidth he needs & Tenant B is not >>> overwhelming the **** >>> >>> Network . **** >>> >>> ** ** >>> >>> Let’s take a case where Tenant A might be running Video Streaming Servers >>> on his VM/Endpoint & **** >>> >>> From Tenant A’s perspective its required for the Virtual DC to guarantee >>> his bandwidth requirements. **** >>> >>> ** ** >>> >>> Regards, **** >>> >>> Selvam **** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* Truman Boyes [mailto:[email protected]] >>> *Sent:* Tuesday, July 10, 2012 7:02 PM >>> *To:* Selvam Ramanathan >>> *Cc:* [email protected] >>> *Subject:* Re: [nvo3] bandwidth requirements of the tenants in >>> draft-narten-nvo3-overlay-problem-statement-02.txt**** >>> >>> ** ** >>> >>> What are these issues relating to bandwidth that you are referring to that >>> are specific to overlays or to the lack of overlays? **** >>> >>> ** ** >>> >>> Regards,**** >>> >>> Truman**** >>> >>> ** ** >>> >>> On Tue, Jul 10, 2012 at 7:40 PM, Selvam Ramanathan < >>> [email protected]> wrote:**** >>> >>> Hi , **** >>> >>> **** >>> >>> Should the overlay-problem-statement-02 also talk about the **** >>> >>> issues arising out of the bandwidth requirements of the tenants ? **** >>> >>> **** >>> >>> Regards, **** >>> >>> Selvam **** > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
