The MPLS WG Archive

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

In message <3549C09B853DD5119B540002A52CDD34012679ED@zcard0ka.ca.nortel.com>, "
David Allan" writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C1874C.E5A785B0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> 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
> ;-) 

I thought that is what I said.  It is attractive because deployed
equipement can support it and it has no technical drawbacks over the
alternative except perhaps religious objections.

Designing protocols to keep a level playing field for the clueless has
never been a goal.  Accommodating migrations from existing deployments
has always been a goal.

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

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

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

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

Good.

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

I didn't see any points outlined above that I did not address.

> cheers
> Dave

Curtis