Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Fri, 13 Dec 2002 06:16:55 -0800

Curtis,

I was more thinking in terms of how to make sure the backup/detour
paths are working fine, while the traffic is still on the working path.

Yours,
-Shahram

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 11:14 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <[email-masked]
> >, Shahram Davari writes:
> > Hi,
> > 
> > Would the authors comment on how the MPLS-ping applies when
> > Fast Reroute scheme exists? In other words how is the backup path
> > and/or detour paths tested from the ingress?
> > 
> > Thanks,
> > -Shahram
> 
> 
> In ping mode you should not know that the backup is in use.
> 
> Perhaps an error return in traceroute mode would be helpful or an
> indication that the next hop is part of a detour.
> 
> Keep in mind that once the detour is put into use it is usually a
> matter of seconds before a new primary is created with its own set of
> detours, none of which are in use.
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Dec 2002 13:56:11 -0500

In message <[email-masked]
> paths are working fine, while the traffic is still on the working path.

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.

There is no way to run a (non-intrusive) test that would determine
whether the traffic would be correctly diverted on failure.  That is
not a limitation of the protocol.  There is no way to test it other
than induce a failure.

Curtis

---

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

Hi Curtis, Shahram:

On Fri, 13 Dec 2002, Curtis Villamizar wrote:

> Currently you'd have to do that from each PLR.

Agreed.  One question is, do the PLRs do this autonomously, or should
this be triggered by LSP pings for the protected LSPs (to be more
accurate, LSP traceroutes)?  For now, I'm happy to go with the former.

> We also don't provide a

Having the PLR exercise (i.e., send pings along) its detours is up
to the implementation.  Right now, there is no LSP ping mechanism for
reporting back.  Should there be?  (If so, I would rather leave it to
a follow-up doc.)

> anything should be added or whether the intent is to require testing

You've heard from me (insofar as you can hear email) :-)

Kireeti.

---

From: George Swallow <[email-masked]>
Date: Fri, 13 Dec 2002 14:22:19 -0500

> anything should be added or whether the intent is to require testing

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: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Dec 2002 14:38:48 -0500

> head-end.  I do see a lot of complications...

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

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Dec 2002 14:41:34 -0500

In message <[email-masked]>, Kireeti Kompella 
> You've heard from me (insofar as you can hear email) :-)

I like the extension doc idea.  If there is a perceived need (from
those who deployed it) after MPLS-ping is deployed, an extention can
be added.

Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 13 Dec 2002 14:50:48 -0500

>accurate, LSP traceroutes)?  For now, I'm happy to go with the former.

         It is probably best to let them do this whether or not the LSR
is programmed to do so.

>reporting back.  Should there be?  (If so, I would rather leave it to

         I think this belongs in another document specific to FRR.

         --Tom

>You've heard from me (insofar as you can hear email) :-)

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