The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

Dave -

> Been reading through section 4.3 of LSP-PING and IMO it needs some
> clarification and perhaps changes to the processing rules. The current read
> of the rules won't check the FECs if there are more FECs than label stack
> entries. Replacing "current stack depth" with "current depth" where depth is
> the larger of the two counts would be a simple fix (as far as text is
> concerned)....

The text is correct as written.  However, I'll admit that it would be
fairly easy to gloss over a very important phrase.  

That phrase is the following:

   X matches up the labels in the received label stack with the FECs
   contained in the FEC stack.  The matching is done beginning at the
   bottom of both stacks and working up.  For reporting purposes the
   bottom of stack is consided to be stack-depth of 1.  This is to
   establish an absolute reference for the case where the stack may have
   more labels than are in the FEC stack and the sender of the ping has
   not requested that a Downstream Verification TLV be sent.  If there
   are more FECs than labels, the extra FECs are assumed to correspond
   to Implicit Null Labels.  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^^^^^^^^^^ 

with that the processing never encounters the situation you are
concerned with, there are never fewer labels in the stack than FECs in
the FEC stack.  

Note also that the text you added

> - if there is no label in the label stack corresponding to the FEC at the
> current depth, then X checks that it is a valid egress LSR for the FEC.  If
> X is not a valid egress LSR, X MUST send an MPLS echo reply with a return
> code 4, "Replying router has no mapping for the FEC at stack depth" and a
> return code set to the current depth. If the current depth is 1, X MUST send
> an echo reply with a return code 3 "Replying router is a egress for the FEC
> at stack depth" and a return code set to 1 (current depth), otherwise
> proceed to step 5.

is covered in step 4 where you "pop" the implicit null and forward the
packet.

I'll work on the wording of the draft to make all this clear.

> There are some additional procedural clarifications that would help the
> document:
> 
> 1) All of the actions in 4.3 assume ping or traceroute mode. LSP-PING also
> provides for one way mode. One way traceroute mode would appear to have
> limited value and therefore we may want to specify MUST NOT and nodes
> receiving one way mode probes with TTL=1 should silently discard them (no
> processing).

Ok by me.  Is anyone planning on using oneway mode?

> 2) It would also be useful to indicate that there are restricted values for
> <RSC> depending on the function. <RSC> can be any value for any error, swap
> etc. but must be 1 for valid egress for FEC. Might be easier to rename the
> code as "LSR is valid egress for all FECs in FEC stack" as this can only be
> generated if the entire FEC stack has been verified.

I'll think about it.  Not sure it is needed.  Also note that a subcode
of 0 is valid, but not desired.

> 3) When a FEC stack is included, that the IP addresses in the LSP-PING
> message are assumed to be routable at the top MPLS layer implied by the FEC
> stack/received label stack. SO for example if I am inserting a ping message
> with a PSN and a VPN label and the FEC stack contains a PSN and a VPN FEC,
> then the reply should be sent to the src address in the PSN. If I am
> inserting a ping message with a FEC stack containing a VPN FEC only, it will
> arrive the same way at the egress PE, but I would reply to the VRF a the VPN
> level, not the PSN level.

I'm interested in hearing more opinions on this!  Seems useful to me.

> And some observations 
> 1) Carriage of the FEC stack with more than one entry in traceroute mode
> would appear to have no value. FEC stack being most useful in PING mode.

Totally disagree on this one.  If you are tracing a VPN FEC, having the
FEC for the bgp-next-hop is very useful.  It allows verification of both
the data and control planes at each hop.  Same with TE.

> 2) If we want to carry forward the "reply to" TLV it should move from
> LSR-SELF test to the ping document although I'd want to think through the
> security implications of this. (As I am not using real routable addresses in
> an LSP PING packet).

I'm ok with it in either place.  But the security issues are perhaps
more constrained in the Self Test case.  I'm officially neutral on where
it goes.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719