The MPLS-OPS Archive

[Eric Osborne <eosborne@cisco.com>]

See inline, look for EO#

...

> > > say in CSCO implem , is it possible at the head-end  to apply a policer 
> >to a
> > > TE tunnel ??
> > > (the logic :  a policer could be applied to an interface , a TE tunnel 
> >is
> > > treated as an interface at
> > > the head-end so :  a  policer could be applied to a TE-Tunnel at the
> > > head-end ) .
> >
> >Not currently; the architecture has been that you police what comes
> >in to your network (from the client side), since assumedly you've got
> >contracts and SLAs and the like.  To aggregate all this into some
> >small number of TE tunnels and then police on that tunnel seems far
> >more arbitrary than most people would be happy with.
> >
> >
> 
> 1- but why not :
> 
> A-control what comes to the network
> 
> AND
> 
> B- controlling what it sent over the tunnel
> 

EO#
because
1) if your second policer (the tunnel TX policer) is different from
the ingress policer, you have a good chance of being unfair to some
people who made it through the first policer because some others are
sending especially large bursts

2) it doesn't make sense.  If you're going to do work to enforce
   traffic (which you need to do to provide SLAs, unless your SLA is
   for clockrate on a TDM interface), do it once.  What do you gain by
   doing it more than once?

> ie: it should not be either .
> 
> the rational that an operator (mainly by the core group) based on the eng of 
> his netw will set the B.W of the tunnel's that the network core  could 
> handle without congestion .
> 
> if for what ever reason (extra provision by the group handling customer 
> connection ..etc ) their is excess traffic from customer's above the core 
> capacity the operator still have a measure in place
> preventing congesting all the network .

EO#  We already have a mechanism to do this; it's called DiffServ.
The IP QoS philosopy (and FR/ATM are similar) has always been to to
pass as much traffic as you can carry, and intelligently drop in some
order of preference when you have contention.  Since operators all
oversubscribe to some degree, you lose lots of multiplexing gain if
you police at the headend when you might actually have the capacity in
the network.

> 
> as an analogy , for the era before mpls where the operator run ATM core and 
> IP edge . the operator
> set parameter and police  the VCC's connecting the IP edge .
> 

EO#  Yes, because they were doing ATM QoS; look at different VC types
and the application of the CLP bit, and you start to see something
very, very similar to DiffServ and WRED.

> 2-Do CSCO plan to provide the feature of policing a TE tunnel at the 
> Head-end or simply
>    this requirement is seen as not sound/needed .

EO# I don't talk much about stuff that isn't public yet, especially on
a public list where some people make up names and use webmail
accounts, mainly because I like my job and I want to keep getting paid
to do it.  Talk to your cisco account team, or contact me offline and
convince me you're not a competitor, an analyst, or someone else with
whom I wouldn't discuss such things, and maybe you'll do better with
that sort of question. :)




eric

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml