The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

> >         I agree with Curtis; please keep the original text in
> >the draft.
> >
> >         --Tom
>
>Tom,
>
>Could you please clarify why you think LSP-ping is Simple and efficient?
>
>The reasons that I think it is not simple and efficient are:
>
>1) Before sending Echo request, you need to run a complicated traceroute 
>to determine the
>hash keys (127/8 addresses) that covers all the ECMP points in the path. 
>Also all intermediate nodes need to assign a series of 127/8 addresses to 
>their ECMP path selections.

         I think you are confused about how it works.  You don't need to do 
a trace
before you can send an Echo request nor do you need to know the hash
keys a priori.

>2) The fact that there are many TLVs defined, means processing the 
>ping/traceroute messages
>requires lots of processing power.

         That is an incorrect assertion. Ask anyone who has implemented
it.

>3) It is not clear in the event of a failure how can the Pinged node 
>process all the incoming echo or traceroute messages simultaneously. In 
>other words it seems that it is not scalable.

         I think you need to be more specific (i.e.: give a detailed example).
Throwing around the "not scalable" flag doesn't cut it.

>4) LSP ping is a bidirectional transaction and therefore requires 2x BW 
>compared to
>a unidirectional transaction. So it is not BW efficient either.

         So. MPLS is unidirectional inherently connection-less,
thus LSP ping mirrors this behavior nicely.  There may not be
a reverse path from any node to the one in question because
no reverse path (via MPLS) may exist.  I think you are assuming
that a bi-directional LSP exists, in which case I assert that you
should test both.  In this way it is simple and elegant.

         --Tom


>Yours,
>-Shahram


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X