The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Dec> msg00229



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLSOAM BOF meeting draft minutes

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Mon, 17 Dec 2001 22:25:16 -0500
  • cc: mpls@UU.NET


In message <EB6D4918A175D311971E00204840E2820ABD3B88@whq-msgusr-01.pit.comms.ma
rconi.com>, "Rutemiller, John" writes:
> ICMP and MPLS-OAM are the same with regards to the basic
> characteristics of a DoS attack (or errant system).
> If overloading of the egress is a concern, due either to DoS or
> simply an errant source, then the processing should be performed
> at the egress. The egress is the only device that knows there is
> a problem and is the only one that can take corrective action.
> 
> 
> How does the ingress handle an overloaded egress? If it assumes
> that the egress is overloaded, it could backoff. But how does
> it tell the difference between an overloaded egress, and a problem
> with transmission somewhere dropping large numbers of packets?
> It can't.
> 
> The egress can make this distinct. It knows that it is being
> overloaded, and can possibly take corrective action. Even if it
> can't take corrective action, it can still distinguish between
> failed connections and overloads. It can also indicate the errant
> connection. An errant connection is unlikey to identify itself.
> 
> 	"Hello, I just wanted everyone to know I'm running a DoS attack"
> 		or
> 	"Hello, I just wanted everyone to know I'm broken"
> 
> 
> The alarm that needs to result from this is a problem at the egress,
> not that there are N failed connections. The egress still has
> the option of declaring the connections failed and sending defect
> indications back to the ingress.
> 
> John


John,

This makes no sense at all.  In the ICMP part of LSP Ping, there is no
load on the egress CPU because the forwarding card ASICs handle ICMP.
There is a one for one relationship between the number of packets any
ingress sends and the number it receives (minus any loss) so if an LSR
CPU is loaded too heavily, it can reduce its sending rate (and
expected reception rate) and reduce its own CPU load.

If an egress is overloaded with OAM, there may be *NO* errant LSP,
just too many perfectly fine LSPs each sending just a little too much
probe traffic.  There are limits to what you can get a microprocessor
to do in a given amount of time.

Curtis