Subject: RE: bug in draft-ietf-mpls-label-encaps-08

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 13 Oct 2000 21:59:36 -0700

I don't think that intended use of the Explicit NULL
labels is to get around the inability of a router
to pop labels, but I could be wrong.

The Explicit NULL labels are used when the penultimate
router doesn't want to do IP forwarding of data packets and
there is no label distribution protocol (RSVP, CR-LDP, LDP) 
running between the penultimate and ultimate hops for whatever 
reason.  In fact, earlier versions of the encaps draft
used to say that such a label is valid only when it is 
the sole entry in the label stack.  I don't know why 
that statement was removed.

-Anoop

> -----Original Message-----
> From: Puneet Agarwal [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 6:44 PM
> To: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'
> 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 otherwise it would just swap the incoming 
> label with
> label 0 and then the egress LSR would do the actual pop.
> 
> 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.
> 
> 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
>

---

From: Shahram Davari <[email-masked]>
Date: Sun, 15 Oct 2000 10:11:00 -0700

Hi Puneet,

> Sent: Friday, October 13, 2000 9:44 PM
> penultimate hop pop

Correct.

 otherwise it would just swap the incoming 
> 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.

> constraint should be removed from the draft for label 0.

Regards,

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Sun, 15 Oct 2000 10:16:58 -0700

Hi Anoop,

-----Original Message-----
From: Anoop Ghanwani [mailto:[email-masked]]
Sent: Saturday, October 14, 2000 1:00 AM
To: 'Puneet Agarwal'; [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Subject: RE: bug in draft-ietf-mpls-label-encaps-08

reason.   

 In fact, earlier versions of the encaps draft 
used to say that such a label is valid only when it is 
the sole entry in the label stack.  I don't know why 
that statement was removed.  

 As you said, the earlier versions of this draft required the explicit null
label to be the sole label entry in the stack. The reason it was removed was
due to hierarchical routing scenarios as shown below:

A-----B-------C-------D-------E

-      X1      X2      X3      -

Y1    0      0        0       -

Assume LSP1 is the outer tunnel: B-C-D-E, and its labels are X1-X2-X3. Now
assume LSP1 is carrying an inner LSP called LSP2 which consists of A-E link.
If "B" as the penultimate hop of LSP2 wants to use the explicit null label,
it could swap Y1 by 0, and then it could push label X1 on top of it. At the
egress "E", label X3 will be popped, because E knows it is the egress of
LSP1, and label 0 will also be popped and the packet will be routed as IPV4.
As you can see in this example label 0 is not the sole label entry. 

 Regards,

-Shahram

-Anoop 

> From: Puneet Agarwal [ mailto:[email-masked] <mailto:[email-masked]>
]

---

From: [email-masked]
Date: Mon, 16 Oct 2000 21:25:38 +0100

Eric Gray wrote (snipped):

> 	There is always a brute force negotiation
> mechanism: the upstream LSR that does not support
> PHP can simply refuse to do so - perhaps sending
> an appropriate error message.  The procedure for
> this is spelled out in section 4.1.1.2 of RSVP-TE
> 
NH=> I can think of one other brute force mechanism........PHP is not
allowed.  This also addresses this architectural conundrum:
Q - when is a trail not a trail?
A -  when PHP is used.
I have yet to hear some killer reason why PHP is so useful that we must have
it (other than the expedient 2 label look-up issue), but I can certainly see
some problems with it, eg where to site OAM functions to detect defects and
take consequent actions (eg send FDI/BDI and client/server adapatation of
FDI between nested LSPs), fix end-point for restoration, where to set
avial/QoS registers, etc.  All these functions need to know where the trail
termination point is and hence where the appropriate functional processing
is located.  To have an unclear datum for the trail termination function is
architecturally not acceptable.

In the mpls-arch ID it says (in section 3.16) 'From an architectural
perspective, this [ie PHP] is perfectly appropriate.'  I fundamentally
disagree with this statement *from an architectural perspective*.  One
cannot have LSP OH being arbitrarily assigned for processing at different
points - irespective of whether one agrees that the assigned OH is
appropriate/sufficient.  And this is clearly demonstated by the following
passage from Yakov's textbook (p 133) on MPLS that explains (I assume) the
initial rationale for these special labels:

"The explicit null labels are used in cases where a label encapsulation is
needed but no valid label is required.  This might be done, for example, to
retain the Exp fields for QoS purposes on the last hop of an LSP, even
though no label is required by the last hop."

neil

---

From: Puneet Agarwal <[email-masked]>
Date: Mon, 16 Oct 2000 16:47:13 -0700

Hi Shahram,

Please see comments below.

>From: Shahram Davari [mailto:[email-masked]]
>Sent: Sunday, October 15, 2000 10:11 AM
>To: 'Puneet Agarwal'; [email-masked]'; [email-masked]';
>[email-masked]'; [email-masked]'
 
"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

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Oct 2000 08:13:43 -0700

Puneet,

As was mentioned by Arch. draft and others:

"A LSR MUST NOT request a label distribution peer to pop the label stack
unless it is capable of doing so."

The explicit null label is not in any case a reply to implicit null label.

Regards,
-Shahram

> Sent: Monday, October 16, 2000 7:47 PM
> To: Shahram Davari; Puneet Agarwal; [email-masked]'; [email-masked]';