The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDEB03BB1@nt-exch-yow.pmc-sierra.bc.ca
>, 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