Subject: RE: Last call on LSP Ping

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Dec 2002 11:59:36 -0800 (PST)

Hi Shahram,

On Fri, 13 Dec 2002, Shahram Davari wrote:

> 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?

To be more precise, PLRs.

Do you have an alternative suggestion?

Note that PLRs testing detours can do so at a more leisurely pace.

Kireeti.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 13 Dec 2002 11:47:12 -0800

-Shahram

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Friday, December 13, 2002 2:22 PM
> To: [email-masked]
> Cc: Shahram Davari; [email-masked]; [email-masked]
> 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
>

---

From: George Swallow <[email-masked]>
Date: Fri, 13 Dec 2002 15:12:59 -0500

> need to be able to generate and process MPLS-ping and keep 

With regard to TE tunnels, just the ones that are supporting tunnels.

Though I will give all of my LSRs the ability to generate and process
MPLS-pings.

...george