The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

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?