The MPLS WG Archive

["James R. Leu" <jleu@mindspring.com>]

Hello Shahram,

On Thu, Nov 23, 2000 at 11:32:39AM -0800, Shahram Davari wrote:
> Hi James,
> 
> When two peer LSRs are not directly connected to each other you should use
> per-platform label space. Also note that any label that has been drawn from
> the per-platform label space should not be used any more by the
> per-interface label spaces. By observing this rule, B can unambiguously
> interpret the per-platform label even in the presence of PHP.

I'm not sure I agree.  If I understand what your saying, every label that is
allocated from the per-platform label space is also marked as un-usable in the
per-interface label spaces? This defeats the purpose of a per-interface label
space.  One of the reasons that per-interface label spaces were introduced is
so that ATM and FR interfaces would only allocated label values for LSPs that
it was going to use.  Thus allowing them to stretch there limited number of
VCs or DLCIs farther.  By doing as you suggest your "wasting" label values.

I have a solution, which many will probably dis-agree with, but dis-agreeing
with Shahram and not providing an alternative is pretty foolish :-)

When allocating an N level label (where N is > 1) it should be allocated from
the same label space as all of the N-1 labels that may possible tunnel this
label.  When N = 1, the value should be allocated from the label space
associated with the set of possible interfaces that will receive this
label.

This assumes that any service allocating N level labels MUST know the set of
LSPs in which it's label values will have meaning.  When N = 1 the service
MUST know what set of interfaces its label values will have meaning.

In the current drafts the only way to have multiple interfaces sharing the
same label space is for them to all be assigned to the per-platform label
space.  To do this box wide though, could be opening the box up to
security issues (think spoofed MPLS packets).

I suggest adding a new label space type.  By allowing multiple interface that
are used to deliver the same service to share a label space you can
create per-service label spaces.  The more specific the service definition
the tighter control over labels and who uses them, thus decreasing the
security concerns, but still maintain varying levels of flexibility.

Of course the most flexible is the per-platform label space, but it also
carries the greatest security concern.  The least flexible is the per-interface
label space, but only minimal security concerns.  The per-service label
space fills in the middle ground.

Some examples may help to illustrate:
-All of the interfaces that will terminate backbone LSPs could be assigned
 to a per-service label space.  Any label allocated from this label space is
 valid on any of the interfaces in this set.  Therefore no mater how any of the
 LSPs re-routes within this set of interface no new allocations need to be made.
 Plus any N level service running over these backbone LSPs need only allocate
 labels from the same per-service label space.
-All of the interfaces that will terminate inter-VPN LSPs for a particular VPN
 would be assigned to a per-service label space.  BGP (for this VPN) would
 allocated labels in this same per-service label space.
-All of the interfaces facing the CEs for a VPN running MPLS would be
 assigned to the same per-service label space.

Anyone else have any suggestions?

Jim

> Regards,
> -Shahram
> 
> > -----Original Message-----
> > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM]
> > Sent: Wednesday, November 22, 2000 3:12 PM
> > To: mpls@UU.NET
> > Subject: Label space of a label advertised through MPLS-BGP
> > 
> > 
> > Hi  All,
> >      Suppose two LSRs A and B are BGP peers and are not 
> > directly adjacent.  When
> > the egress LSR (B) advertises a FEC and the corresponding 
> > lable to the ingree
> > LSR (A), in which label space should the advertised label 
> > reside?   Should B
> > always use its per-platform label space in this situation?  
> > When B receives a
> > labeled  packet in the FEC routed through A, how can B 
> > unambiguously interpret
> > the label (assuming PHP is used)?   See figure8.4 of Bruce 
> > Davie's book on MPLS
> > for example of this scenario.
> > 
> >      Thanks for your answer.
> > 
> > -- James Huang
> > 
> > 
> > 

-- 
James R. Leu