The MPLS WG Archive

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

Hi George:

Shouldn't shoot from the hip, esp on old emails written a while ago. Since
we're talking at MPLS WC, this is mainly for the list's benefit....

Proposed changes to section 4 were to:

1) Put some meat on the sentence "If there are more FECs than labels, the
extra FECs are assumed to correspond
   to Implicit Null Labels." by adding processing rules for those extra
FECs. That is the intent of changing stack depth to larger of the depth of
the label stack and the FEC stack, and the more detailed procedures in step
3.

2) Slight additional logic in step 4, if "pop and switch" and label depth is
1 (no label to switch) would appear to be an error condition (although the
code may not be sufficiently descriptive). ALso added the mention of PHP (as
it did not appear to be explicitly covered).

And not yet covered is:

1) removing one way mode

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com] 
> Sent: Thursday, February 12, 2004 12:59 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'kireeti@juniper.net'; mpls@UU.NET; swallow@cisco.com
> Subject: Re: Comments on LSP Ping 04 
> 
> 
> Dave -
> 
> > 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.
> 
> Correct.
> 
> > The procedure as described
> > will break.
> 
> Could you explain how?  I'm not seeing a problem.
> 
> > 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.
> 
> Yes, but you should never get that far if things are working 
> properly. If you have 
> 
>      FEC Type     Label Stack    FEC Stack
> 
>      TE                57           ...
>      LDP               22         10.10.10.10
>      VPN               45         192.27.168.1
> 
> Then the rules say look at first label.  
> 
> In step 1. Is there a FEC (stack entry) corresponding to
> this label etc, if not go to step 4.
> 
> Then you find that you are label switching at depth 3.  The 
> originator of the ping will be notified that you are doing 
> something at a layer below 
> 
> I'll make it clearer that you are looking for a stack entry 
> in step one.  In step 4 if you can determine the label 
> operation, ostensibly you also know that the label is valid 
> on the interface and what the FEC is (although this last 
> piece is not really necessary for the processing)
> 
> ...George
> 
> ==============================================================
> ==========
> George Swallow             Cisco Systems                  
> (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719
> 
>