The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDE84A47D@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> Curtis,
> 
> > The sender (ingress) does the hard work in Ping's proposal (the LSP
> > Ping proposal, aka Ping's Ping proposal - I hope we've been friends
> > long enough that I can get away with that :) ).  The egress uses some
> > existing bits of hardware (and/or microcode, implementations will
> > vary) to turn ICMP echo responses into ICMP echo replies.  The need to
> > either do ICMP processing at wire rate or (slightly less preferable)
> > rate limit ICMP has been known for about 5 years so hardware is in
> > place (btw- some ICMP, such as destination unreachable must be rate
> > limited even if processing could be done at wire rate).
>  >The sender
> > may not process the ICMP response at wire rate.  Hopefully the sender
> > implementation will be smart enough to slow down its own rate of
> > sending if it is overloading its own CPU processing the responses.
> 
> 1) You don't need wire rate OAM processing. We are talking about a very small
> fraction of traffic being OAM.

Experience with ICMP dictates otherwise.  Wait until someone decides
to implement treno for MPLS using LSP ping or MPLS-OAM and a
priviledged customer takes your network down.  

[Can't happen?  I know of a certain OC12c customer that took their
provider router down with excessive SNMP queries, despite being
warned.  Before that they were angry that they did not get SNMP access
to the whole backbone.  When the investigation of a significant outage
(affecting them only) revealed that their tech caused it, they better
understood the reason for restricting their SNMP access.  btw- SNMP
should not take a router down.  I didn't design that router.]

> 2) Slowing down the connectivity probe is a bad idea, because it could increa
> se your
> failure detection time to unacceptable range.  

If the operator is not smart enough and sets the send rate to 1 msec
per LSP and there are lots of LSPs, there could be a problem (probably
will be).  If so, it would be better to slow the rate of sending than
to have the router become unstable.  Do you disagree?

> > The sender must have feedback to avoid an unintended DoS attack on the
> > egress, so LSP Ping was a distinct advantage.
> 
> Since Harrison's proposal requires a fixed rate of 1 CV packet per second,
> it is in fact very easy to detect DOS attacks.

Fixed rate is not adequate.  Some will find this too frequent.  Others
will need finer granularity.

> >The fact that the probe
> > mechanism is implemented in most router hardware and runs at wire rate
> > is an additional technical reason to go with LSP Ping.
> > 
> 
> We don't need wire rate OAM processing.

Exactly how many PPS of this type of traffic and associated interval
timers to detect lack of reception do you think a off the shelf
microprocessor will be able to process?  1,000?  Will fixed rate
transmission and software processing be adequate?  I don't think so.
Do you think that perhaps this microprocessor might also have some
other work to do?

> > I thought the objections would be to LSP Ping being too RSVP-TE
> > centric in the UDP response.
> 
> This is one of the main objections.

Rumor has it Ping already agreed to fix it if he isn't inuntated with
this mail thread.

> -Shahram 

Curtis