The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Curtis,

Minor or editorial comments may be left unanswered and be raised
again, but I had some pretty important comments that am not sure
has been resolved. They include:

1) In L2VPN or L3VPN do we need to push both inner and outer label?
if not then do people agree to add the inner label to the FEC TLV?
2) How do we return the label mapping TLV in case RSVP-TE is used
for the return path? (no such object is defined for RSVP-TE)
3) What should be the time stamp format, and should it include the
three time stamps similar to ICMP?
4) What happens if in an FEC stack ping, some of the FECs are confirmed
and some are not? Do we need more error codes? How many more?
5) How are the ATM/FR labels supported in Label-mapping TLV?


I think it is more constructive to answer protocol impacting questions
rather than leave them unanswered and wait for the 7th version (4 versions under draft-pan-lsp-ping and 3 versions under name draft-ietf-mpls-lsp-ping) of the draft.

Yours,
-Shahram

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, December 18, 2002 1:12 PM
> To: Shahram Davari
> Cc: 'curtis@fictitious.org'; Kireeti Kompella; Gray, Eric; mpls@UU.NET
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <4B6D09F3B826D411A67300D0B706EFDEB03BB0@nt-exch-yow.pmc-sierra.bc.ca
> >, Shahram Davari writes:
> > 
> > > > 
> > > > Before revising the document, I suggest answering all the 
> > > follow up comments.
> > > > 
> > > > -Shahram
> > > 
> > > 
> > > Shahram,
> > > 
> > > I suggest not.  It would be more productive to revise the document
> > > reflecting the (sometimes long and largely unproductive) threads
> > > rather than respond to every message.  After the document 
> is revised,
> > > provide an opportunity for new comments or for comments 
> to be repeated
> > > if clarifications didn't help or prior (valid) comments were not
> > > reflected in the revision.
> > > 
> > > Its clear this document wasn't ready for last call, but 
> at least the
> > > false start drew some useful dialog (and some less so) and could
> > > substantially improve the document if the comments are reflected.
> > > 
> > > Curtis
> > > 
> > 
> > Up to you, but that would leave the comments raised as 
> unresolved. And 
> > people will certainly repeat those comments that have not 
> been responded 
> > to, which would then require a couple of more last calls.
> > 
> > -Shahram
> >
> 
> 
> I'm not suggesting comments should be ignored.  For example:
> 
>    This document describes a mechanism that can be used to detect data
>    plane failures in MPLS LSPs.  The mechanisms described here are
>    intended to detect forwarding faults in an MPLS LSP which prevent
>    traffic from being delivered to its intended destination and
>    isolate the fault to the LSR at which traffic stops flowing.  No
>    attempt is made to determine that cause of the fault or diagnose
>    problems any further.  Enumeration of all possible fault types is
>    outside the scope of this document.
> 
> Removing "simple and efficient" in the first sentence addresses a long
> message voicing an objection.
> 
> The last two sentences address some diatribe on this list about
> lsp-ping != Y.1711 by agreeing that lsp-ping != Y.1711.  Its a
> feature.
> 
> I think a lot of comment resulted from a poor understanding of how
> traceroute mode was supposed to work.  I responded earlier by saying
> that "like IP tracroute" was sufficient for me but needed to be in the
> document.  So we'll put it there.
> 
> There was a lot of noise on this list.  If there were useful
> comments that were missed they can be repeated.
> 
> We don't want to repeat the bgp-17 experience where comments were made
> and the document remained unchanged for 10 months and no one was quite
> sure what had been agreed to and what was being reviewed.
> 
> Curtis
>