The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00141



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

bug in draft-ietf-mpls-label-encaps-08

  • From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
  • Date: Sun, 15 Oct 2000 10:11:00 -0700

Hi Puneet,


> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Friday, October 13, 2000 9:44 PM
> To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com';
> 'yakov@cisco.com'
> Subject: bug in draft-ietf-mpls-label-encaps-08
> 
> 
> Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with
> hierarchical tunnels.
> 
> On pg 5 it states:
>               i. A value of 0 represents the "IPv4 Explicit 
> NULL Label".
>                  This label value is only legal at the bottom of the
>                  label stack.  It indicates that the label 
> stack must be
>                  popped, and the forwarding of the packet must then be
>                  based on the IPv4 header.
> 
>  My understanding was that when a LSR got a label 3 from the 
> egress LSR
> during signaling, if the LSR was able to do a pop then it 
> would perform a
> penultimate hop pop

Correct.

 otherwise it would just swap the incoming 
> label with
> label 0 and then the egress LSR would do the actual pop.

This is only true if the label is the bottom most label in the stack.
Otherwise a normal label swapping will be done at penultimate hop, and since
the ultimate (egress) LSR knows it is the egress LSR, it could pop the
swapped label. 

The reason is that in case the label is the bottom most label, the egress
LSR could possibly use the explicit null label to determine the L3PID (i.e.,
0 -> IPV4, 2-> IPV6). While this property is not needed when the LSR is not
the terminating point of all LSPs.

> 
> However, the draft states that the label 0 is only valid at 
> the bottom of
> the stack. This implies that to support hierarchical tunnels one of 2
> conditions have to be true:
> 
> (a) All LSRs supporting hierarchical tunnels, need to support 
> PHP (so they
> never swap label 0 on the stack)
> 
> OR
> 
> (b) The "label value is only legal at the bottom of the label stack"
> constraint should be removed from the draft for label 0.

Regards,

-Shahram

>
 
> Since support for PHP is not a requirement for LSRs, the 
> draft should be
> updated to remove the constraint for label 0, to support hierarchical
> tunnels.
> 
> -Puneet
>