The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Dec> msg00305



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

Last call on LSP Ping

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Fri, 13 Dec 2002 14:38:48 -0500
  • cc: curtis@fictitious.org, Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET


In message <200212131922.OAA18873@bifocal.cisco.com>, George Swallow writes:
> > Currently you'd have to do that from each PLR.  We don't provide a
> > means to tell the ingress of the existance of a detour (except the
> > local-protect-available bit in the signaling itself which one major
> > implementation wasn't using last I checked).  We also don't provide a
> > means to tell a specific PLR to exercise its detour and report back.
> > 
> > Let's wait and hear from Kireeti or other authors whether they think
> > anything should be added or whether the intent is to require testing
> > initiated at each PLR.
> 
> The PLR is responsible for the bypass.  It knows what sender-template
> it used, so it can form the proper FEC for the ping.  It can send a
> lsp-ping with the proper label stack.  So it is the natural place to
> do this.  If it fails, it should
> 
> a) report to network management
> b) reset the backup in place bit
> c) look for another way of establishing a backup
> d) if successful on c) set the backup in place bit.
> 
> You may want to put a hold-down on b) to avoid reporting to the
> head-end on a transient situation.
> 
> I don't see what advantage you would gain by moving all this to the
> head-end.  I do see a lot of complications...
> 
> ...George


I agree.  That is why I suggested we should ask the authors first
before suggesting more protocol gorp.

Curtis