Subject: Ships in the Night operation on ATM-LSRs

From: "Chetan Pinto" <[email-masked]>
Date: Fri, 21 Jun 2002 17:48:52 -0700

There are ATM LSRs that support Ships in the Night operation
on ATM interfaces. Thus these ATM interfaces are also LC-ATM interfaces

The vpi/vci range on an ATM interface is shared between MPLS and other
applications and each application is aware of the range available to it.

The label [vpi/vci] range in case of LDP is
negotiated during the LDP initializaion phase between
two LDP peers on the ATM link connecting the two.

As far as the LDP session state machine is concerned
negotiation of parameters is restricted to the Initialization phase.

Considering a case wherein one of the ATM applications relinquishes
it's label range [i.e. the user no longer needs to use that
application]. The user then has a choice of lending the freed range
to another ATM application. When doing so, MPLS could also be one of
those candidate applications. At the same time it is assumed that a
similar action  is taking place on the other end of the ATM link.

Hence, LDP could get a larger share of the vpi/vci range than
it was previously using. This could solve the scarce label resources
[if any at that time] issue under this scenario.

But at the same time it is to be noted that the above mentioned
situation is encountered relatively rare or is it that there no user
bothered about such a scenario.

Is it worthwhile considering this case, as this might be a one time
migration scenario?
If not, this can be rested to oblivion

Else there are two cases of solving this.
In the first case, the LDP session between the two peers is shutdown
and they are re-configured so as to accomodate the increased vpi/vci
label range. This involves unnecessary disruption in already established
LSPs passing thro' the two peers. Albeit there is a solution proposed
that intends to maintain LSPs across LSR restarts

In the second solution, can we think of a new message "Re-init" message
that needs to be exchanged by the two peers periodically until
both of them ACK each others increased label range via a new Status code
added to the Notification message. This can then be applied generally
to newer negotiations without having to re-start the LDP session.

Obviously, a decrease in the label range allocated to MPLS cannot be taken
care of until those labels in the range removed from LDP have been released

Thanks
chetan

############################################################
Chetan Francis Pinto
Phone : Res : 408-244-1352
############################################################

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: David Charlap <[email-masked]>
Date: Mon, 24 Jun 2002 11:00:44 -0400

> similar action  is taking place on the other end of the ATM link.

This presumes that the label space is partitioned.  This isn't really a 
requirement.

Every MPLS protocol can advertise the full label range without fear of 
the two stepping on each other.  The neighbor router will always know 
what labels are in-use, since ATM labels (VCIDs) are always 
per-interface, so you won't ever see one label assigned to two protocols.

Label space partitioning for SIN is for administrative purposes, not 
technical ones.  Similarly for anybody who wants to partition the label 
space among several MPLS protocols.  Given this, it is unlikely that 
this space will re-partition very often.  If the overhead of 
repartitioning is unacceptible, I'd look at the LDP graceful restart 
draft (draft-ietf-mpls-ldp-restart-02.txt and consider using that to 
minimize the impact of restarting LDP, rather than changing LDP.

-- David