The MPLS WG Archive

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

Hi George:

The reason I suggested the text is that there is a converse situation to
what you underlined where you can have more labels in the stack than FECs if
you insert the PING (for example) in an LDP network, and due to uniform mode
TTL handling, a traceroute terminates in a TE trunk then the P LSR in the
trunk has no knowledge of any FECs in the stack. The procedure as described
will break. You could get similar effects in CSC if the ping originated at a
CE (although the addesses in the ping header in that case are probably not
routable, although you could use the ICMP PING type trick of inserting the
Echo reply into the LSP in the downstream direction...).

If noone is planning on using one-way mode, lets remove it now and save our
developers time.

On item 3 below, inferring whom to reply to based on the depth of the FEC
stack means we may be able to traceroute PWs in the presence of ECMP "some
day". As I can insert a ping with the PW PID and a FEC stack containing the
PW FEC and the PSN FEC, and PSN addresses in the IP header. TTL exhaust at a
P-LSR that "can" parse the PW PID, can generate a reply at the PSN layer but
as we are using the PW PID and PW label stack, THE TRACEROUTE PROPERLY
TRACES THE PW. IMHO this beats the VPN ICMP hack as it does not depend on
the downstream LSP working for a return path and can be used to isolate
specific PSN problems that impact PWs.

On item 4, my reason for saying the FEC stack has limited utility in
traceroute mode is that when tracing a VPN or PW, the P LSRs have no
knowledge of the VPN or PW FECs anyway, and the processing rules would halt
on matching the first FEC in the stack. So as written, the extra FEC stack
elements would not be examined at LSRs where TTL exhausts. ergo, not really
useful.

Hope that makes things clearer....

cheers
Dave

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com] 
> Sent: Thursday, February 12, 2004 11:31 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'kireeti@juniper.net'; mpls@UU.NET; swallow@cisco.com
> Subject: Re: Comments on LSP Ping 04 
> 
> 
> 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
> 
>