The MPLS WG Archive

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

Title: RE: MPLSOAM BOF meeting draft minutes

Curtis:

Comments in line.....

<snip>
> >
> I have no idea what "playing field levelling upgrade" you are talking
> about.  Did some MPLS equipment fail to implement IP or ICMP?

No, exactly the opposite, ICMP is the incumbent and implemented solution, which is why some folks who've already implemented it find it so attractive ;-)

>
> Can you please elaborate on what "customers requirements" are not met.
>
> Can you also explain whether the lack of flexibility is in the ICMP
> echo request and response, where the sender gets back the variable
> length it sent, or in the UDP LSP Ping response which is being defined
> and is still sufficiently in flux to have no limitations whatsoever.

Well to borrow some points you raised:

You suggest that closing the feedback loop directly with ICMP adds a lot of benefits. I'm not so sure:

- 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 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.

- 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.

I agree that use of explicit IP vs. OAM alert label is a wash.

So ICMP with hardware assist may exist today, but I consider LSP-PING undesirable in the longer term for the reasons outlined above, on top of the usual control plane dependency and other stuff we've discussed.

cheers
Dave