The MPLS-OPS Archive

[Santiago Alvarez <saalvare@cisco.com>]

Many different (bad, not so bad and not bad) things could happen
depending on your network design.  A fact remains, per-user/per-flow
policies on the gw router would face scalability issues in most real
cases, but would give you very granular control.  Moving
per-user/per-flow policies as close as possible to the customer
sacrifices control, but takes care of the scalability issues in most
real cases.  It's a tradeoff between control and scalability.  Based on
my experience, a scalable solution would be preferred by SPs.  However,
there valid designs where scalability wouldn't be an issue at the gw.
Cheers.

SA
--

Bruce wrote:
> 
> Hello,
> 
> What happens in case some one UDP floods a customer?
> 
> Does it mean the entire network gets choked by the "flood"?
> 
> ----- Original Message -----
> From: Santiago Alvarez <saalvare@cisco.com>
> To: Eddy Tedjasaputra <eddyt@sistelindo.com>
> Cc: <mpls-ops@mplsrc.com>; <saalvare@cisco.com>
> Sent: Thursday, January 16, 2003 11:19 PM
> Subject: Re: [MPLS-OPS]: QoS
> 
> > If you're looking for _min_bw_guarantees_during_congestion_, you need to
> > have output policies on the gw and the internet router and have
> > customers queued separately.  Not a scalable solution since the number
> > of customers can go beyond the queuing/scheduling capabilities of those
> > two nodes (e.g. 10,000 customers).  Aside from mgmt issues (e.g. you may
> > not have control over the two nodes, you may not want to touch those
> > routers every time you add a customer).  You could also try to implement
> > a solution policing individual customers, but your SLA would be
> > different (no _min_bw_guarantees_during_congestion_ kind of guarantee).
> > In that case, you could implement all your policies on the gw, but
> > you'll also hit scalability issues as the customer base grows and you
> > might face similar mgmt issues.  If you really want to have per-customer
> > SLAs for internet traffic, you're best bet it to implement all policies
> > (upstream/downstream) on the PE (for unmanaged service) or on the CPE
> > (for managed service).  Some downstream bandwidth will be wasted since
> > it'll be dropped right before reaching the customer and after having
> > consumed backbone bandwidth, but that's the price you'd have to pay.
> > Should I say, the customer would have to pay...
> > Cheers.
> >
> > SA
> > --
> > Eddy Tedjasaputra wrote:
> > >
> > > Hello everybody,
> > >
> > > I'm setting up the following configuration.
> > > An MPLS cloud with 3 PEs :
> > >    PE1 is connected to CPE A (customer A)
> > >    PE2 is connected to CPE B (customer B)
> > >    PE3 (Internet Gateway) is connected to an Internet router
> > >
> > > [Image]
> > >
> > > I tried to use a policy map below to guarantee the b/w (32K) is
> > > available to Cust A during congestion period.
> > > This policymap is applied on the incoming interface of PE3 (interface
> > > X)
> > > >>>
> > > policymap Test
> > > class CustA
> > >      police cir 32000 bc 4000 pir 128000 be 4000 conform-action
> > > transmit exceed-action set-prec-transmit 2 violate-action drop
> > > >>>
> > > Can someone please advise me the best way how to guarantee a minimum
> > > thruput (ie. CIR) for every customer when
> > > a CONGESTION is occured between Internet G/W and Internet router ?
> > >
> > > Appreciate for any comments.
> > > Thanks, Eddy
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> >
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

--

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