Subject: RE: Last call on LSP Ping

From: "Gray, Eric" <[email-masked]>
Date: Fri, 13 Dec 2002 15:02:34 -0500

Shahram,

	They would need to be able to process Ping requests
in order to support the trace-route capability, anyway.
It is not so bad a thing to add this to the list of new
features required to support continuity checks for a PLR.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, December 13, 2002 2:47 PM
> To: 'George Swallow'; [email-masked]
> Cc: [email-masked]
> Subject: RE: Last call on LSP Ping
> 
> 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?
> 
> -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: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Dec 2002 13:52:16 -0800 (PST)

> 23) The last paragraph in section 8 ...
  ^^^

Thanks, Eric!

All I need now is two counts: (a) the number of emails for this Last
Call; (b) the number of individual comments/nits/fixes that were made.

Loa, George, what are the current records for these?  :-)

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Dec 2002 10:12:55 -0500

In message <[email-masked]>, Kireeti Kompella 
> Loa, George, what are the current records for these?  :-)

Kireeti,

You clearly need to revise this document and present it for comment to
the list again.  Its useful in its current form but as a draft that
can be advaced to the IESG, its half baked.  After initial comments on
the revision, then redo the last call and keep track of the comments.

Curtis