Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Wed, 18 Dec 2002 12:58:44 -0800

Curtis,

> >, 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.

Agree

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

1, 2, 4, 5 haven't been answered.

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

I want to test the inner LSP. Do I need to push both labels? or only the
transport label? In case I push both labels there is no way to detect
the ping packet at the egress. So my suggestion was to only push
the top label and add the inner label to the echo-request.
(This point was also raised by Eric Rosen)

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

Section 3.2 describes something called Downstream Mapping TLV. This
is defined for IP packets only. When the return path is the RSVP-TE,
how does the downstream mapping gets encoded in RESV message? May be the
answer is trace-route has no value when the return path is RSVP-TE ! or
may be a Downstream mapping Object needs to be defined.

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

OK.

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

OK.

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

OK.

Yours,
-Shahram

> 
> > Yours,
> > -Shahram
> 
> Thanks for the reminders on these points.
> 
> Curtis
>

---

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

In message <[email-masked]
> 1, 2, 4, 5 haven't been answered.

4 and 5 were deferred.

> (This point was also raised by Eric Rosen)

My interpretation is push both labels.  Both start at TTL=1.
Increment top, then next label.  If they both terminate at the same
egress LSR (normal for BGP VPN) then bottom TTL never gets past 1.

> may be a Downstream mapping Object needs to be defined.

Downstream is in the forward direction so this question doesn't make
sense.

The Downstream Mapping TLV never refers to the return path.

<snip to end - 4&5 in another message>

Curtis