The MPLS WG Archive

[Puneet Agarwal <puneet@pluris.com>]

Hi Shahram,

Please see comments below.

>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Sunday, October 15, 2000 10:11 AM
>To: 'Puneet Agarwal'; 'erosen@cisco.com'; 'mpls@uu.net';
>'tappan@cisco.com'; 'yakov@cisco.com'
>Subject: RE: bug in draft-ietf-mpls-label-encaps-08
>
>
>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.
 
"normal label swapping" cannot be done in the case you described at
the penultimate LSR as there is no legal label to swap. The penultimate
LSR cannot swap label 3 (as it is forbidden) onto the packet.
At the time of the LSP setup, the penultimate LSR has no knowledge if
there will be an inner LSP or not - so it does not know whether to reject
the
PHP request (signalled via reception of label 3) during LSP setup.

One way out of this conundrum would be a change to the signaling
protocol(s).
The egress LSR could send two labels to the penultimate LSR for the same
LSP:
(a) label 3 - this is to inform the penultimate LSR to do the PHP if it can
pop.
    Alternatively, instead of sending "label 3" to ask for PHP, the
signaling
    protocol could use other means to ask for PHP.
    
(b) swap label - To be used in the case that penultimate LSR cannot pop.

This would actually eliminate the need for labels 0 and 2 as label (b)
should
have all the information needed by egress LSR to determine the enscapsulated
protocol type. 
 
Thanks.

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