The MPLS WG Archive

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



[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: Sanjay Wadhwa <swadhwa01@yahoo.com>
  • Date: Fri, 13 Jul 2001 06:03:15 -0700 (PDT)
  • Cc: Ron Bonica <rbonica@mci.net>, mpls-list <mpls@UU.NET>, mpls-ops <mpls-ops@mplsrc.com>

See below:
> 
> 
> > -----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. 

Above seems like a good signalling independent solution. Couple of
points to note though. The echo response will need to carry some
signalling specific information. And this will not work if all LSRs on
the path do not implement the application that listens on a UDP port,
and consults the appropriate signalling state to decide upon the next
hop towards the ingress. 
OTOH, I think that one of the pros of the draft propasal is that the
LSRs on the path do not have to necessarily implement this. The
echo-response will be transparently passed along in the RESV (as an
unrecongnized object). Only LERs need to implement this. This might be
easier to deploy in the near term. Just a thought.

-Sanjay


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/