The MPLS WG Archive

["S.Matsushima" <satoru@japan-telecom.co.jp>]

From: Ping Pan <pingpan@juniper.net>
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
Date: Tue, 10 Jul 2001 08:34:24 -0700

> 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?

Ping,

I can't understand why do you use RSVP msg for reply LSP-ping.
It is only way to LSP using RSVP or other DoD/Orderd label
distribution mode.
Isn't it same thing that simply IP reachability from egress to
ingress for other label distribution mode?
(For example, DU/Independent label distribution)

LSP is unidirectional path besically. Thus, I suppose LSP-ping reply
scheme will be done by only have to simply IP reachability from egress
to ingress.

> 
> 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

How about Section.4 in draft-satoru-mpls-1hop-lsp-00.txt?
It can use not only "KeepAlive" purpose but also LSP-ping.


> 4. The Possible to LSP "KeepAlive" using 1-hop LSP
>
> 4.1  Background
>
>     This "LSP KeepAlive" ability is extremely important for the
>    applications which use LSP but cannot know the state of LSP itself
>    (for instance, consider the situation where BGP / MPLS VPNs are
>    used; they will recognise the network as "available" only if the
>    possibility of the IP accessibility to the PE exits, whatever the
>    state of the LSP).
>
> 4.2  Method of "LSP KeepAlive" process
>
>    The "KeepAlive" of LSP is possible by the use of IP Packet
>    transmission to FEC from the ingress LER with the minimum IP TTL
>    (minimum value=1) through 1-hop LSP. This is because if there is a
>    cut within LSP then there will be no reply.
>
>    In order to carry out "KeepAlive" of LSP, the expansion process is
>    also require for the core LSR such that IP TTL will not be replaced
>    by MPLS TTL, just like in the egress LER. This is because, if there
>    is a cut within LSP the core LSR will "pop" the label. This means
>    that the original core LSR will be made to act as an egress LER.
>
>    The reply can be expected from the entire installed, if, such as
>    ICMP ECHO is used for setting of the IP Packet in this situation.
>
>    The TTL does not have to, or more precisely, should not have a value
>    of 1 for reply. In case of TTL value on the reply message being 1,
>    it will go to the opposite side of LSP "KeepAlive" since the LSP is
>    a one-way path. This LSP "KeepAlive" cannot be "KeepAlive" for each
>    LSP.
>
>    The TTL value on the LSP KeepAlive's reply message should have large
>    enough value. Also, if there is no route for the reply message to
>    return, it will look as though the healthy LSP does not exit.


--
Satoru Matsushima