The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi:

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

I'd suggest the following (which includes the change, and modifications.....
mainly to step 3, plus noting that the current depth should be minus one
when reporting a pop and switch, and adding PHP to step 4): 
===============================================================
X sets a variable, call it current depth, which is the larger value of the
labels in the received label stack, and the number of FECs in the FEC stack.
Processing now continues with the following steps:

1) Check if there is a FEC corresponding the the current depth. If there is
go to step 2. If not check that the label is valid on interface I. If it is,
continue with step 4. Otherwise X MUST send an MPLS echo reply with a return
code 11. "No entry at stack depth" and a return subcode set to the current
depth.

2) Check the FEC at the current depth to determine what protocol was used to
advertise it. If X can determine that no protocol associated with interface
I would have advertised a FEC of that FEC-type, X MUST send an LSP-PING echo
reply with a return code of 12 "Protocol not associated with interface at
FEC stack depth" and a return subcode sent to the current-stack-depth.
Otherwise proceed to step 3.

3) Check that the mapping for the FEC at the current depth is valid:

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

- if there is a label in the label stack corresponding to the FEC at the
current depth, then:
	- if the label is not valid on interface I then X MUST send an MPLS
echo reply with a return code 11 "No entry at 	stack depth" and a return
code set to the current depth. 
	- if no mapping for the FEC exists, X MUST send an echo reply with
the return code 4 "replying router has no mapping 
	for the FEC at stack depth" and a return subcode set to the curent
depth.
	- if a mapping is found, but the mapping is not the corresponding
label, X MUST send an echo reply with a return code  	10 "Mapping for this
FEC is not the given label at stack depth" and a return subcode set to the
current depth.

4) X determines the label operation:
- If the operation is to pop and continue processing, X checks the current
depth. 
	- If it is one, X MUST send an MPLS echo reply with a return code 3
"replying router is an egress for the FEC at 
	stack depth" and a return subcode set to one. 
	- Otherwise decrement the current depth and go back to step 1.
- If the operation is pop and switch based on the popped label, X then
checks that it is valid to forward a labelled packet. If it is not valid to
forward a labelled packet or the current depth is one, X MUST send an MPLS
echo reply with a return code 9 "label switched but no MPLS forwarding at
stack depth" and a return subcode set to the current depth. Otherwise X MUST
send an MPLS echo reply with a return code 8, "Label switched at stack
depth" and a return code set to current depth minus one.
- If the label operation is a swap or a "pop and go (PHP)", X MUST send an
MPLS echo reply with return code 8, "label switched at stack depth", and a
return subcode set to the current depth.

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

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.

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.

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.

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

Cannot comment on how this would impact "existing implementations", although
it would primarily appear to focus on use oor non use of the return subcode
field.....

cheers
Dave