The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: MPLSOAM BOF meeting draft minutes

Comments below...

<snip>
> >
> > - I'm actually doubling the message handling load
> processing wise, as the
> > ingress becomes a proxy fault detection point. I can view
> this as taking the
> > LSP sink and splitting this function between the sink and
> the source.
> > Effectively an extra interface is added to the function.
>
> The egress processes at wire rate so the processing is not doubled,
> just moved to the ingress where it belongs.  The sender burdens its
> own processor.

This sounds like religion. The doubling I refer to is the number of messages the network needs to handle simply to determine that a LSP is suspect. LSP path and return path. There is then a non-hardware assisted confirmation that there is a real problem that also burdens the control plane of every router esp. if the recommendation of expediting LSP-ping responses is implemented. I'm not clear on why you think that handling a simple heartbeat cannot be done at wirespeed compared to recongnizing a ICMP directed to a specific interface and formatting a response.

As much as I understand your argument about the sender burdening itself, this principle would only seem to make sense for complex functions. I'm actually very suspect of the notion of adaptive criteria for failure detection, any higher levels/layers recovery schemes cannot be orchestrated with arbitrary criteria that takes a variable amount of time to make a failure determination. e.g. client layers will detect failure at more or less the same time, but they won't have a clue how long to wait for the layer busy being smart to take action before they bail and do it themselves.

>
> > - the return path is not reliable, and subject to
> congestion, and may fail
> > separately, hence the follow on transactions with UDP to
> figure out exactly
> > what went wrong. So instead of authoritatively knowing in
> the first place, I
> > have this two step process. The actual failure test (UDP
> message) I doubt is
> > H/W assisted today. You seem to be concerned about having
> the sender police
> > itself in order to avoid unintented DOS attacks on the
> receiver (or itself),
> > I'd argue the reverse of the coin, the ICMP then LSP-PING
> process requires a
> > much higher rate of messages to achieve reliable fault detection in
> > comparable time frames to a unidirectional transaction. I
> would be less
> > concerned about this issue using a unidirectional
> transaction as proposed.
> > In other words I can significanlty lower the network burden
> bandwidth and
> > processing wise by using a properly designed transaction,
> than overloading
> > ICMP.
>
> The loss rate is for control traffic on today's IP backbones is close
> to zero if not zero.  The loss rate for plain old data on most
> backbones is also zero.  Closer to the edges "very high loss rates" of
> as much as a couple of percent might be encountered.  A statistics
> probe can have the egress count packets but would have to be an
> optional extension to LSP Ping because it would not be handled by
> existing ICMP processing.
>
> The UDP packets are only a second step that occurs after a failure is
> detected and effectively traces the LSP. 

Actually no failure has been detected at the point when you stopped getting ping responses, and because the return path may be (and most likely is) topologically disjoint from the LSP that has become suspect, failure to receive ping really means very little, hence the second step that is not hardware assisted.

It is not used for
> detection, and it can be slow.  Note:
>
>    When the ingress LSR suspects that the LSP may have failed and the
>    RSVP control plane shows the LSP as operational, the
> ingress LSR MUST
>    send LSP-ping messages to the egress over the LSP,
> periodically.  The
>    value of the time interval should be configurable.
>
> ICMP is sent to detect failure.  UDP based LSP Ping is sent after an
> failure is detected using ICMP.  Why we need the latter is somewhat of
> a mystery to me, apparently to either distinguish a data plane from
> control plane failure or to to circumvent anti-ICMP religion.

See above.

>
> > - If a unidirectional heartbeat simply refreshes a timer at
> the egress, the
> > suggestion that too many messages will overload the
> reveiver is specious at
> > best. The processing is minimal compared to recognizing an
> ICMP packet,
> > reformatting it into a reply (however few shifted bits and
> swapped addresses
> > it takes) popping up to the IP level, determining the
> FEC-NHLFE mapping for
> > the return path and sending the packet back. I'd agree that
> this is all
> > there today, but I'd also argue with the folks who claim
> MPLS is "Simple".
> > My board would dissapate less heat and achieve higher port density.
>
> Very large access boxes can have on the order of 1,000 interfaces,
> with virtual interfaces (channelized, VC, or Ethernet VPN based vifs).

Yes....

> If each VIF is a BGP VPN customer and each VPN has on the order of 10
> remote members, numbers get large quickly.  If monitoring is backbone
> only, then a BGP-VPN LSP could go down and not be notices.  If
> monitoring is a fixed one per second, this could be a lot of timers to
> process.  At least if the sender of the probes does the work, then the
> sender can directly regulate its own work and it can account for
> changes in the send rate when the receive rate drops.
>
There are lots of ways to simplify the implementation of a heartbeat that is associated with an LSP. If the sender can receive heartbeats on an arbitrary interface possibly disjoint from the interface carrying the LSP under test, it needs to do orders of magnitude more work to figure out what the ICMP reply maps to and means. Only if you burden the network with this architecture do your arguments make sense. This function just isn't that complicated.

 <snip>

cheers
Dave