The MPLS WG Archive

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

In message <3549C09B853DD5119B540002A52CDD3401267BCD@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_01C187CE.1B98DC60
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> 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.

Maybe it is.  The IETF does not like open ended protocol with no meas
of rate limiting.  This is in support of stability.

Network stability is more important goal than measurement accuracy.
Scalability is an important goal (see RFC1958 Architectural Principles
of the Internet).  Here's a sample:

   3.3 All designs must scale readily to very many nodes per site and to
   many millions of sites.

   3.4 Performance and cost must be considered as well as functionality.

   3.5 Keep it simple. When in doubt during design, choose the simplest
   solution.

   3.6 Modularity is good. If you can keep things separate, do so.

   3.7 In many cases it is better to adopt an almost complete solution
   now, rather than to wait until a perfect solution can be found.

If the design principles that have been used to build the Internet so
far is a religion in your view, so be it.

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

This is a similar argument to that used in 1992 to justify the coding
of a BGP implementation in which the sender would open TCP connections
as non-blocking and close the connection if it blocked.  The BGP
adj-in processing on the other side was a light weight CPU activity
which drained the BGP socket before any serious procesing occurred.  A
few meltdowns ended that argument.

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

In the event of a fault, the return path should heal quickly.  The
same should be true to the forward path.  Loss of a small number of
pings should be noted, but not acted on.  The failure that we are
trying to detect is persistent failure not transient loss.

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

It may need to do a hash and a lookup and even the hash can be avoided
by storing an index in the payload.  ICMP allows a payload.  Since the
sender is also the ultimate reciever, interoperability with regard to
this payload is not an issue but we'll probably be defining it in
detail to support a common interpretation.

>  <snip>
> 
> cheers
> Dave

Curtis