The MPLS WG Archive

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



[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: Wed, 11 Jul 2001 13:11:44 -0400
  • cc: Ron Bonica <rbonica@MCI.NET>, Yakov Rekhter <yakov@juniper.net>, Dave Cooper <dcooper@gblx.net>, mpls-list <mpls@UU.NET>, mpls-ops <mpls-ops@mplsrc.com>
  • 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)


Eric> I guess  I'm also having  some trouble understanding why  the LSP-ping
Eric> mechanism needs to be specific  to a particular control protocol.  Why
Eric> not just  use a  UDP packet to  send the  response back to  the tunnel
Eric> head?  It  won't necessarily travel  back along the control  path, but
Eric> does that really matter?

Robert> It may disappear the same way  as the original icmp test so the head
Robert> will assume that LSP is down while it is in fact up.

We just need  to invent a way to  ensure that the UDP packet  follows the IP
hop-by-hop  path,  rather  than  being  sent through  an  LSP.   That  would
eliminate  the  worry  about  MPLS   data  plane  problems  in  the  reverse
direction.  It does leave a hole  in the situation where the RSVP-TE control
plane is working  although there is no IP connectivity from  the tail to the
head, but that doesn't seem like too big of a hole.