The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

>Are you saying that now all LSRs (even the intermediate ones)
>need to be able to generate and process MPLS-ping and keep
>MPLS-ping states?

         I will let George speak for himself, but to me it seems clear that
since the PLR is responsible for setting up the bypass that if it
is also interested in testing the bypass path's liveliness, that it
should be capable of generating and processing MPLS ping messages
too.  The only state being kept is by PLRs that wish to verify the liveliness
of their backup paths.  Those that do not wish to provide this sort
of functionality need not keep any state or provide such functionality.

         --Tom


>-Shahram
>
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: Friday, December 13, 2002 2:22 PM
> > To: curtis@fictitious.org
> > Cc: Shahram Davari; mpls@UU.NET; swallow@cisco.com
> > Subject: Re: Last call on LSP Ping
> >
> >
> > > 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
> >
> >
> > ==================================================================
> > George Swallow       Cisco Systems                  (978) 497-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> >

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto