Subject: RE: Label space of a label advertised through MPLS-BGP

From: Shahram Davari <[email-masked]>
Date: Mon, 27 Nov 2000 13:16:42 -0800

Hi James,
 
> Which draft makes this assertion?  I consider hierarchy to 
> include the case
> where the top label is ATM/FR and the rest of the label stack 
> is composed of
> generic labels under the require "NULL" label.

The main reason of having per-platform label space is that when an egress node of a hierarchical tunnel distributes an inner label to its remote peer, it does not know from which interface that LSP will arrive (this might be due to the use of TE that changes the outer LSP). In other words the label below the top label needs to be from the per-platform label space not the top level label that is VPI/VCI.

Regards,
-Shahram

---

From: "James R. Leu" <[email-masked]>
Date: Mon, 27 Nov 2000 15:43:58 -0600

Hello Shahram,

On Mon, Nov 27, 2000 at 01:16:42PM -0800, Shahram Davari wrote:
> The main reason of having per-platform label space is that when an egress
> node of a hierarchical tunnel distributes an inner label to its remote
> peer, it does not know from which interface that LSP will arrive (this
> might be due to the use of TE that changes the outer LSP). In other words
> the label below the top label needs to be from the per-platform label space
> not the top level label that is VPI/VCI.

We just stated earlier that all of the values in the label stack must be from
the same label space. (I believe that this is also stated in the architecture
draft) If we ignore this, then anytime we allocate an inner label from the
platform label space we need to search for a value which does not conflict
with the label spaces of the interfaces that this label could arrive on.

Also, what was once a outer label could become an inner label due to
protection switching/path protection.

The blanket statement of: "All inner labels are allocated from the platform
label space" does not fit every case.  I think there is a better solution then
this.  Per-service label spaces is my (obviously failed) attempt at a
solution.

Regards,
Jim
-- 
James R. Leu