Subject: Re: Last call on LSP Ping

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

In message <[email-masked]
>, Shahram Davari writes:
> 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:

I do sort of agree with you but if the document describes broken bits
of protocol, its not the time to look for missing commas.

I trust this list is here not because these things haven't already
been answereed but as a reminder to put them in the doc.

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

Depends on which LSP you are testing.  Is the inner label semirandom
payload to exercise load split or is it the LSP actually under test.

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

According to the instructions in section 5.  Use the RESV.  Add the
object specified in the doc.  What's not clear?

> 3) What should be the time stamp format, and should it include the
> three time stamps similar to ICMP?

"The time is expressed in seconds and microseconds since midnight (0
hour), January 1, 1970".  Type "man gettimeofday".  Kireeti answered
that.  I thought it was obvious enough but agree it is better stated.

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

Good question.  Let me answer that one separately in another message.
It is an ommision in the document.

> 5) How are the ATM/FR labels supported in Label-mapping TLV?

barf.^h^h^h^r  Yes - good point.
I don't care^h^h^r I don't know.

The amount of thought put into this seems proportional to the deployed
base of MPLS over ATM/FR in ISPs.

Someone who cares^h^h^r Someone who knows more about this may have to
pointlessly beat their head against the wall ^r contribute.

:-)		       [ just kidding - sort of ]

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

OK.  I still owe you an answer on point 4 and something intellegent on
point 5.

> Yours,
> -Shahram

Thanks for the reminders on these points.

Curtis

---

From: Shahram Davari <[email-masked]>
Date: Wed, 18 Dec 2002 10:40:25 -0800

Curtis,

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:[email-masked]]
> Sent: Wednesday, December 18, 2002 1:12 PM
> To: Shahram Davari
> Cc: [email-masked]'; Kireeti Kompella; Gray, Eric; [email-masked]
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <[email-masked]
> >, 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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Dec 2002 16:18:21 -0500

I'm replying to myself because I gave Shahram some overly short
answers.  Sorry.  I wanted to get out the part 2 message.

> It is an ommision in the document.

There are a couple of legitimate situations where this will happen.
With varying degrees of "legitimate".  Some have to do with TTL
processing with hierarchy.  Another is situation is an LSR that
doesn't decrement TTL (hopefully not on an LDP LSP that loops) or one
that doesn't understand lsp-ping.

What you'd see at the ingress is an error.  If you resent the Echo
Request without any of the prior mapping TLVs, then you'd see an Echo
Reply that confirmed the FEC and gave a downstream mapping TLV.  You
could then continue the traceroute.  Having reached the egress you
have a portion of the trace for which you aren't certain how the
packets go.  If the pings work and the area of uncertainty is outside
your administrative domain, you have to accept that delivery happens
by some undisclosed magic until delivery fails to happen.  If it is
within your administrative domain, you can MIB query until such time
as you can resolve the problem to get complete traces.

> > 5) How are the ATM/FR labels supported in Label-mapping TLV?
<snip>

Lets try again on this one.

AFAIK, an ATM or FR LSR doesn't decrement TTL.  Therefore this would
appear to to be a transparent couple of hops just like FSC, LSC, TDM.

This might be one of those situations in point 4 above where there is
a discontinuity in the sanity of the traceroute.  The downstream
mapping gives the next ATM LSR but incrementing TTL does to the end of
the VC if TTL isn't decremented.

Curtis

ps - IMHO - PHP is a thing of technical elegance and beauty compared
to MPLS over ATM (or anything over ATM).  :-)