The MPLS WG Archive

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

In message <4B6D09F3B826D411A67300D0B706EFDE84A47A@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> Curtis,
> 
> Like you I see many common functions between Harrison and Ping drafts. 
> 
> 1)Both use a periodic hello type of message to detect connectivity failure. S
> o from the state processing point of view, they have almost the same complexi
> ty.
> 
> 2) In Ping's proposal, the ingress-LSR evaluates the connectivity, while in
> Harrison's proposal the egress-LSR evaluates the connectivity. The Ping's 
> proposal has the advantage that the detection is done right at the LSR that
> should perform corrective action such as protection switching. While the 
> Harrison's proposal has the advantage of consuming only half of the BW consum
> ed by
> Ping's proposal (since there is no loop back).


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.

If the egress does the hard work, adding one more sender (ingress)
could destabilize the egress.  An errant sender (wrong send rate)
could also destabilize the egress.  A stable situation could turn
unstable if the egress got busy with other things and it might be a
lot harder to reduce the sender rates at that point.


> 3) Ping's proposal uses the Explicit Null Label(essentially a reserved label)
>  + A unique UDP port number to identify the OAM packets, while Harrison's pro
> posal uses another reserved label 
> (label 14) to identify the OAM packets. Ping's proposal has the advantage of 
> not requiring the
> Null label for IP carrying LSPs, while Harrison's proposal has the advantage 
> of faster OAM detection (just by looking at the OAM label).


MPLS-OAM offers no technical advantage here.  Exposing an IPv4
Explicit Null label and then an IP and ICMP header costs little enough
that it will have negligible impact on wire rate memory fetch and
processing budget (which must already be quite well pipelined to work
at all).  The recipient of the data collection has to either process
ICMP echo responses or MPLS-OAM packets.  It is not clear that either
is easier or harder to process.


> 4) Ping's proposal depends on the RSVP-TE return path, while Harrison's propo
> sal does not depend on
> any specific MPLS control plane.


If two LSRs can't talk to each other using the IGP routes and IP
forwarding except during a brief IGP convergence transient if the IGP
routes just changed (which would imply a recent link failure) the ISP
will have plenty of "hints" to indicate that something is very
seriously wrong.


> So I think the main issue is whether the state processing needs to be kept at
>  the ingress-
> LSR or egress-LSR. 


Good.  If that's the only issue, we are in great shape.

The sender must have feedback to avoid an unintended DoS attack on the
egress, so LSP Ping was a distinct advantage.  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.


> In summary, I would say they achieve the same objective, with different set o
> f trade-offs. Except that the Ping's proposal covers only a subset of Harriso
> n's proposal, and therefore needs other tools for other MPLS control planes.
> 
> Yours,
> -Shahram


I hope you seriously consider the technical points I've made.

I thought the objections would be to LSP Ping being too RSVP-TE
centric in the UDP response.

Curtis