Subject: RE: [IP-Optical] RE: GMPLS - Label

From: [email-masked]
Date: Wed, 20 Dec 2000 16:56:29 -0500

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:[email-masked]]
Sent: Wednesday, December 20, 2000 2:17 PM
To: [email-masked]
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.

---

From: Eric Gray <[email-masked]>
Date: Wed, 20 Dec 2000 17:13:36 -0500

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