First part - you answer yourself. The packet will be IPv4. Therefore, you'll
use IPv4 (e.g. normal) QoS here.
For Q2, if you have policed it on the way in, then you already know the
maximum rate the traffic will incur, correct?
Unless you are getting latency sensitive traffic, and unless you have done
something to get to a point where latency may be messed with over your 10G
links, then you have nothing to worry about. Would any further points of QoS
actually accomplish anything for you?
We try not to make things any more complicated than necessary! So ask
yourself at each point you have an urge to add something - "Is this
necessary?" or "What am I gaining by doing this?" If the answer is "no" or
"nothing" then don't do it. :)
HTH,
Scott
---- Message from adam gibs <adamgibs7_at_gmail.com> at 2009-09-27 00:32:24
------
>The Connection is as below
>
>CE---DS/PE-----CoreP/PE----ISP/PE,
>
>The link between distribution and the core is fiber 10 gig i dont want to
>implement any bandwidth limitation on the links between distribution and the
>core i want let the customer use the 10 gig link upto the core but on core
>VRF sub-interfaces facing to ISP which QOS i have to apply traditional QOS
>or MPLS QOS ????.The packet will be a IPV4 am having a back to back vrf
>connection with ISP.
>
>question 2:
>The traffic which i will recieve from ISP definately i will police that
>traffic according to CLient demand bandwidth but when it will travel towards
>the distribution switch i should implement QOS towards the distribution
>switch???? or i shld implement MPLS QOS or i shld leave that traffic as
>default,because i want the 10 Gig link between core and distribution shld be
>utilize as much as can.Can u advise me what are the drawback for this.
>
>
>Blogs and organic groups at http://www.ccie.net
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sat Sep 26 2009 - 19:56:05 ART
This archive was generated by hypermail 2.2.0 : Sun Oct 04 2009 - 07:42:04 ART