The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

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.