The MPLS WG Archive

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Hello Curtis,

Perhaps I'm sporting more ignorance in this matter.  I had not
considered ping as a path continuity test.  The idea is to have
a test at the MPLS layer (OK ping is a bit above that...maybe 
not a problem) that would follow the data path (even through
LSRs) so it can detect disconnected and misconnected LSPs.

If the LSP egress expected ping's regularly from the ingress,
lack of pings would detect a broken connection.  If the ping 
contains data that identifies the ingress and path (path trace 
info), some (all?) misconnections can be detected.  (Is adding
specific data to a ping OK, or is this frowned upon?)

The remaining question is how to detect the location of the
dis-or-misconnection.  If intermediate LSRs can monitor this path
trace ping, that would help.  So here we're back to the question
of how to identify OAM packets in transit...  I don't know of
an existing mechanism for this.  (Router alert doesn't seem to 
fit the bill since, I assume, router alert packets follow
a different data path through an LSR from user packets and thus 
will not reflect all possible connection faults.)

In any case, I agree ping is worth considering.

I'm not trying to reinvent the wheel -- just trying to figure
out how to make the cart roll straight with all the varied wheels
we have to work with...

Regards,
Ben

curtis@avici.com wrote:
> 
> In message <393CF7D3.9338D95C@tellabs.com>, Ben Mack-Crane writes:
> >
> > I have been thinking about this from the viewpoint of the recovery
> > framework and protection switching drafts to which I have contributed.
> > In looking at MPLS based recovery, it becomes clear that a simple
> > and reliable path continuity test would be very useful.  Also a fast
> > communication path to convey a fault indication is useful if rapid
> > protection switching is required.
> 
> Pardon my ignorance but to what extent does ping and traceroute
> implemented by the LSR meet these particular OAM needs?
> 
> It might help to start by identifying which features the OAM needs to
> accomoddate that are currently missing (timestamp, record route,
> other?).
> 
> For example, ping with record route doesn't work unless the MPLS
> router alert and an ability to modify the underlying IP packet is
> implemented (which hasn't even been suggested, and I am not implying
> that it is a good idea).  Then we can consider whether a MPLS specific
> ping with record route (or OAM packet) is needed to prevent DOS
> attack, or whether one ping for all underlying layers is still OK (and
> if one ping is better, then whether LSRs should provide configurable
> ability to either rate limit or block setting of MPLS router alert
> based on presence of RR IP options).
> 
> We might want to ask ISPs how valuable RR IP option on ping has been
> and how valuable the equivalent ATM OAM cells have been.  We may find
> that the former is used occasionally at most and the latter even less
> or not at all for IP over ATM networks.
> 
> > A simple way to identify OAM packets, while allowing them to
> > follow the same data path as user packets (when required), is
> > essential to these functions.  If this can be done without disruption
> > to the embedded MPLS base, as Kireeti has indicated, this would be
> > ideal.  I think there are some promising possibliities being discussed
> > in the related thread on "OAM labels".
> 
> draft-ietf-mpls-icmp-01.txt ?
> 
> Lets not reinvent the wheel if we don't have to.
> 
> Curtis