The MPLS WG Archive

[Ken Nagami <ken.nagami@toshiba.co.jp>]

Hi Ping, Robert,

Thank you for your explanation. I understand your point.
A hop-by-hop control plane, which is a return path for the LSP-ping 
is needed on this mechanism.

Ping, 

Do you think that the mechanism is generalized?
I think a generalized mechanism for the LSP-ping is more useful.

>> Ken Nagami wrote:
>> 
>> Hi Ping,
>> 
>> >> You don't give a message type for the LSP-ping.  Were you thinking of
>> >> a new message?  Perhaps the Notify message could be used?
>> >>
>> 
>> >> For LSP-ping messages, the echo packets are encapsulated in UDP with a
>> >> well-known port number. At the egress, the LSR picks up the echo by
>> >> "listening" to the UDP port, and replies them back in Resv. I didn't
>> >> consider the Notify message.... Let me think about it.
>> 
>> Why do you use a RSVP RESV message for an LSP-ping reply?
>> I think it is better to use an UDP packet which is the same as
>> LSP-ping echo message. If you don't use an MPLS control
>> message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for
>> all kind of LSP, such as a static LSP and an LSP established by LDP.
>> 

>> Ken,

>> LSP-ping is used to probe the data path. There are cases where the data
>> path goes wrong, and you have no idea where the problem is (forwarding
>> LSP, reverse LSP, ...). Since the only operational path that you can
>> count is the control path, so you reply via RSVP.

>> If you use UDP to return the reply, what if the returning path is
>> broken? Should the user assumes the forwarding LSP is bad, or the
>> reverse?

>> At the same time, if you can come up with a simple, scalable, backward
>> compatible method to use for LDP (including the case where you can label
>> merging) as well, please do let us know. :-)

>> - Ping