The MPLS WG Archive

[Eric Gray <ewgray@mindspring.com>]

Igor,

    Where the issue you raise would be of concern is
when the platform label space is used.  If the label
space is interface specific, the fact that a label may
have been issued to another LSR is not relevant.

    In the applications where an upstream LSR may
wish to suggest a label (notably, optical switches
that incur some delay in making the physical change
that corresponds to a new "label"), only the interface
specific label space would apply.

--
Eric Gray

ibryskin@movaz.com wrote:

> Kireeti,
>
> How the upstream node can be sure that released label is not advertised by
> the downstream node to some other upstream node? I mean, the upstream node
> just can keep track of labels that have higher level of probability to be
> granted.
>
> Igor.
>
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, December 20, 2000 2:17 PM
> To: mpls@UU.NET
> Subject: RE: [IP-Optical] RE: GMPLS - Lable
>
> > RSVP uses downstream-on-demand for label assignment. The upstream LSR
> > does not keep free labels for downstream LSR.
>
> "Does not keep" is different from "cannot keep".  On point-to-point
> links, the upstream LSR can easily do this.  If the upstream LSR is
> motivated enough to use suggested labels, it makes sense to track
> which are available.  Note that unlike "data labels", lambdas and
> ports usage will be tracked carefully; i.e., the upstream LSR should
> know which labels (ports) are free in any case.
>
> Kireeti.