The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDEB03BBB@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
<snip>
> 
> A) In ping mode the egress LSR would in fact not look below the inner
> label and will forward the ping packet to the customer.

That was the point of the discussion that Alia started a while ago on
"S" bit handling and/or TTL expire on the TTL=1 labels.  The "S" bit
would never be clear on a PW label except MPLS ping.

> B) In you trace-route example how do you know that you have reached the
> egress LSR? Since you may not know that, it is possible to increment the
> TTL of top label beyond the egress LSR and cause the ping packet to be delive
> red to the customer.

I'll send that question to the authors.  

I'll give my guess.  For the common case where the LDP and PW labels
terminate at the same router send return code 3 "Replying router is an
egress for the FEC".  Its not clear what you do for the case where the
top label is popped but other FECs in the label stack continue.  One
clue for the ingress is that the responding router address is equal to
the top "RSVP IPv4 Session" IPv4 tunnel end point address.

It would help to have a stack of "FEC Egress Reached" TLV in the Echo
Reply so the ingress has a clear indication that it is time to take a
FEC TLV off the top of the FEC stack before incrementing TTL.

> So the inner label should not pushed for LSP-ping packet. Again my suggestion
> is to only push the transport label and encode the inner label in the
> echo-request message.

The set of labels is supposed to match the FEC stack.  If you just
wanted to confirm the path the transit LSP, then optionally add the
next label but don't include the next FEC.  If you want to confirm the
next label, you must add that label and add that FEC.  If you don't
add the label, at a MP branch point your packet may take a different
path than the VPN label you intend to test for label based MP.

Curtis