The MPLS WG Archive

[Miya Kohno <mkohno@cisco.com>]

Satoru,

   The draft proposes how to validate the data plane of RSVP-TE LSPs. As for LDP LSPs, we need to discuss separately. It might be ideal if there's a generalized method, but it seems difficult because we will have to depend on the control plane anyway.

Miya
At 02:14 01/07/11 +0900, S.Matsushima wrote:
>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

----------------------------------------------------------
Miya Kohno, Sr. Consulting Engineer
Service Providers Market Developments, Cisco Systems Japan
Phone: +81-3-5219-6234, Email: mkohno@cisco.com