The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jul> msg00084



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

[Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

  • From: Eric Rosen <erosen@cisco.com>
  • Date: Tue, 10 Jul 2001 10:44:44 -0400
  • cc: Ken Nagami <ken.nagami@toshiba.co.jp>, Ping Pan <pingpan@juniper.net>, George Swallow <swallow@cisco.com>, mpls-list <mpls@UU.NET>, mpls-ops <mpls-ops@mplsrc.com>, Nischal Sheth <nsheth@juniper.net>, Dave Cooper <dcooper@gblx.net>
  • User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1(Nishinokyō) Emacs/20.6 (sparc-sun-solaris2.5.1)MULE/4.0 (HANANOEN)
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id JAA14681


I'm still confused about what this actually tells you. 

>From the failure  of the ICMP pings, you already know  that either the LSP's
data plane is failing, or else  there is no operational return path for data
packets.  However, there  is apparently an operational path  for the forward
and reverse control traffic.

If you send the LSP-ping down the LSP itself, then it "ought to" fail if and
only if the LSP's data plane  is failing.  So presumably, if it succeeds you
know that the failure is in the reverse data path.

If you  do not send the  LSP-ping down the  LSP itself, then it  will likely
succeed, but you don't learn anything. 

So the most you can learn from this is that the failure of the original ICMP
ping is  due to  a problem  in the return  path for  data packets.   Is that
correct? 

But if all you want to know is whether the reverse data path is working, why
not just do ordinary ICMP ping in the reverse direction? 

What am I missing?