The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jan> msg00070



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Some suggestions for LSP Ping

  • From: "Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com>
  • Date: 15 Jan 2003 15:39:34 -0500
  • Cc: curtis@fictitious.org, "'mpls@UU.NET'" <mpls@UU.NET>

George,
> > [Note: If you use the payload header & Router Alert option method, that
> > method exercises the test packet on the path data traffic would take]
> 
> If what you are trying to accomplish is to diagnose one single VPN
> flow it might work if:
> 
> 1. you set the source address to the address of the flow.
This has been noted in this thread.

>    (this raises some issues on getting the Ping Reply back to where it
>     is needed)
Good point. Perhaps the return address could be specified in the LSP
Ping message.

> 2. the hash includes no other fields than source and dest
Agree, I noted this in the first email I sent on this thread, and
suggested some additional features.

> 3. the hash has not been reseeded or changed by some topological event
>    since the problem occurred.
If you do another ping after this event, then the test packet should
traverse the path data take. 

> I believe that once an operator discovered a problem they would want
> to  explore all the paths to determine the health of their network.
> 
> The use of RA also raises three further issues.  
> 
> 1.  If a 127/24 addressed packet were to escape from a provider, it
> would be eaten by the first router it encouters.  If you send a ping
> with RA and it escapses, if the customer's routers don't recognize
> LSP-Ping, the message will be delivered all the way to the host.
Agree, this has been noted in the thread.

> 2.  If an LSP-Ping were to escape from a broken LSP at a node that did
> not recognize LSP-Ping, it could end up being successfully forwarded
> to the destination node causing you to *not* detect the break.
Wouldn't the destination node/customer node drop it if it is not LSP
Ping aware?

> 3.  If you eliminate use of the 127/24 range, you don't have a set of
> addresses that you can employ to explore the EMCP paths of an LSP.
If we look at the problem this way, yes.

> So I think there is little benefit and many drawbacks to your proposal.
I think we should not ignore the advantages of this approach or the
disadvantages of the other proposal in drawing the above conclusion.

In any case, these suggestions are meant to be helpful and the authors
did ask for suggestions. If the consensus is they are not useful, then I
am fine with that.

Thanks,
Cheng-Yin