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

From: Shahram Davari <[email-masked]>
Date: Thu, 23 Nov 2000 11:32:39 -0800

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.

Regards,
-Shahram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 3:12 PM
> To: [email-masked]
> 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
> 
> 
>

---

From: "James R. Leu" <[email-masked]>
Date: Fri, 24 Nov 2000 17:39:25 -0600

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

-- 
James R. Leu

---

From: Eric Rosen <[email-masked]>
Date: Mon, 27 Nov 2000 14:59:21 -0500

Shahram> When two  peer LSRs  are not directly  connected to each  other you
Shahram> should use per-platform label space.  Also note that any label that
Shahram> has been drawn from the per-platform label space should not be used
Shahram> any more by the per-interface label spaces. By observing this rule,
Shahram> B can  unambiguously interpret the  per-platform label even  in the
Shahram> presence of PHP.

James> I'm not sure I agree. 

Shahram's statement seems impeccable to me.  

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

In fact, there is no such thing as a per-platform label space of VPI/VCIs or
DLCIs.  So  there is  no way  a per-platform label  space could  take values
away from a per-interface label space in an ATM-LSR. 

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

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

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

One problem  with this proposal  is that  there is no  such notion as  an "N
level label". 

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

The fact that  all interfaces use labels from the same  label space does not
imply that an incoming packet with a label from that space must be accepted,
irrespective of  the interface on which  it arrives.  If  a particular label
has not been distributed to any  label distribution peer that can be reached
out interface I, then packets arriving  over interface N with that label can
be discarded as bogus. 

Perhaps  this is exactly  what you  are getting  at above  -- that  for each
label, it is  helpful to know the set of interfaces  over which traffic with
that label may be validly received.  

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

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

Unless you  have some reason  for using the  same label value  for different
services, there  is no difference  between having per-service  label spaces,
and having a per-platform label space where you know that certain labels may
not be validly  received over certain interfaces.  What you  need to know is
that a  particular label has been  used for a particular  service, you don't
really need a per-service label space.

---

From: "James R. Leu" <[email-masked]>
Date: Mon, 27 Nov 2000 14:44:45 -0600

Hello Eric,

<snip>
> away from a per-interface label space in an ATM-LSR. 

This question is slightly tangential, but:

How does one handle the case where you have ATM and POS interfaces terminating
"tunnels" which carry traffic with a label value for the same service?

<snip>
> One problem  with this proposal  is that  there is no  such notion as  an "N

If the stack consists of 2 labels.  The bottom label is is the 2nd level label.
When allocating that bottom label, the service should take into consideration
which set of top labels could be used to "tunnel" traffic with that label
value to this LSR.

> out interface I, then packets arriving  over interface N with that label can

So you are saying that even though interface I,N are members of the
platform label space, the contents of their ILMs may be different.
Agreed.  There are cases though when the labels allocated from the platform
label space need to be added to the ILMs of multiple interfaces.  How will
the user specify _which_ interfaces should be included?  Most likely by
creating a group of interfaces, and associating that group with a service.
Why not use the label space for the grouping and the association?

> that label may be validly received.  

<snip>
> really need a per-service label space.

I'm assuming we will need more then 20 bits to represent all of the label
values allocated by a given LSR.

Jim
-- 
James R. Leu

---

From: Eric Rosen <[email-masked]>
Date: Tue, 28 Nov 2000 11:44:53 -0500

Eric> In  fact, there  is no  such thing  as a  per-platform label  space of
Eric> VPI/VCIs  or DLCIs.  So  there is  no way  a per-platform  label space
Eric> could take values away from a per-interface label space in an ATM-LSR.

James> This question is slightly tangential, but:

James> How does  one handle the case  where you have ATM  and POS interfaces
James> terminating "tunnels" which carry traffic  with a label value for the
James> same service?

I'm not quite sure what you  are asking.  For a labeled packet arriving over
an LC-ATM interface, the top label will always be a VPI/VCI; labels lower on
the stack will never be VPI/VCIs.

Eric> One problem with  this proposal is that there is no  such notion as an
Eric> "N level label".

James> If the  stack consists of 2 labels.   The bottom label is  is the 2nd
James> level label.   When allocating that bottom label,  the service should
James> take  into consideration which  set of  top labels  could be  used to
James> "tunnel" traffic with that label value to this LSR. 

I think what you  mean is that for each label you  allocate, you should keep
track of the set of interfaces  from which traffic carrying that label might
(validly) arrive.  I  don' think that this set, "the  set of interfaces from
which traffic carrying  that label might validly arrive",  can be identified
by a set of labels.

James> So you are  saying that even though interface I,N  are members of the
James> platform label  space, the contents  of their ILMs may  be different.
James> Agreed.  There  are cases though  when the labels allocated  from the
James> platform  label  space need  to  be added  to  the  ILMs of  multiple
James> interfaces.  How  will the user specify _which_  interfaces should be
James> included?   Most  likely  by  creating  a group  of  interfaces,  and
James> associating that group  with a service.  Why not  use the label space
James> for the grouping and the association? 

You could do this, it just isn't the only way to do it.

Eric> Unless  you  have some  reason  for using  the  same  label value  for
Eric> different services, there is  no difference between having per-service
Eric> label spaces,  and having  a per-platform label  space where  you know
Eric> that  certain  labels  may   not  be  validly  received  over  certain
Eric> interfaces.  What you need to know is that a particular label has been
Eric> used for  a particular  service, you don't  really need  a per-service
Eric> label space.

James> I'm assuming we  will need more then 20 bits to  represent all of the
James> label values allocated by a given LSR.

More than one  million label values per LSR?  What  applications do you have
in mind?