The MPLS WG Archive

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



[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: "Shekhar, Ravi" <RShekhar@unispherenetworks.com>
  • Date: Thu, 12 Jul 2001 12:04:49 -0400
  • Cc: Ron Bonica <rbonica@mci.net>, mpls-list <mpls@UU.NET>, mpls-ops <mpls-ops@mplsrc.com>



> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Thursday, July 12, 2001 10:26 AM
> To: George Swallow
> Cc: Ron Bonica; mpls-list; mpls-ops
> Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] 
> 
> 
> 
> George> The mechanism is  intentionally tied to the control  
> plane to ensure
> George> that the source  is properly informed even if  the 
> reverse data path
> George> may be broken.  
> 
> If  the reply is  encapsulated in  a UDP  packet which  is 
> addressed  to the
> tunnel head and has router alert  set, isn't this just as 
> effective, without
> the dependence on the control plane? 

  In a pathological case, there might not even be vanilla IP hop-by-hop 
  (non-LSP) connectivity either in the reverse direction. So IP routing 
  these replies to tunnel head might not work. 
  Perhaps sending replies in the reverse direction of the way the request 
  for LSP came in by looking at the reservation state in the router (i.e. 
  the way current draft suggests for RSVP and something similar for LDP) 
  but sending it as UDP packet as you suggest will achieve both the goals - 
  signalling protocol independence and bypassing any IP hop-by-hop failure 
  in reverse direction. Besides, if (ever) LSPs are set up across LDP/RSVP 
  domain, this mechanism would still work.

  - Ravi Shekhar.