Re:

["Igor Bryskin" <ibryskin@movaz.com>]

Stephen,

Great to hear from you.

I agree with what you said. As you correctly pointed out, there are cases
already when provisioning of an LSP does not require operations in the data
plane (e.g. make-before-break). In these cases, however, the CP is aware
that necessary data plane related provisioning is in-place already. When we
move ownership from MP to CP, the procedures from the CP point of view are
almost the same  - one exception is that the CP is not aware of the fact
that the network resources are in place already, and with simple signaling
extensions it is possible to achieve the goal with very little pain and as
reliable as make-before-break procedure is.

One other similar example. When the CP on some controller is re-synched
(after the crash or software upgrade) the situation is almost identical -
the crossconnects are in place already, the only thing to do is to restore
the CP states. The only difference here. though, that the CP can figure out
by itself that resources are in-place

Igor

----- Original Message ----- 
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>
Sent: Wednesday, July 20, 2005 5:54 AM



Adrian, see comment below.

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 10:02
> To: George Newsome
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving LSP ownership between control plane and
> management plane
>
>
> Thanks George,
>
> Useful input.
<snip>

> > - Call awareness of migration vs. connection being unaware
> of migration.
> >   When connection state is being created to match an existing
> > connection, the connection controllers (CCs) do not require
> awareness
> > of why this is happening as the context could be migration or
> > recovery.  A mechanism to create control state without affecting
> > transport plane state is needed in the CCs.  Call
> controllers though
> > do need migration awareness as they need to obtain/derive call
> > identification from the MP.
>
> I disagree.
> Connection controllers must be able to distinguish between
> resources that are already in use and cannot be assigned to a
> new connection, and those that are already in use and can be
> assigned to a new connection because the connection is
> replacing an existing connection. If this were happening
> entirely within the control plane we would use resource
> sharing, but when the operation spans the control and
> management planes resource ownership/sharing is more complex
> and the conneciotn controller needs to be able to issue the
> approriate instrucitons for the assignment of the resources.
> On the other hand, call controllers do not need awareness of
> the details of the realisation of the connections.

I'm not sure if the difference between migration awareness and the
action of creating connection state for an existing transport connection
is clear in the original point.  I agree with your first sentence and
think that signalling could be extended to include the case where
connection details (in a complete ERO) are supplied with the attribute
that the cross connections are already in place.  Similarly, teardown of
connection state can occur where cross connections are not undone.  I
still agree though with the original point and note that it does not say
that call controllers are aware of connection details.  Call controllers
are aware that a migration action is the reason for triggering the
connection controller to establish state.

The point about awareness refers to an understanding of why LSP state is
being created.  If existing LSP state is being replaced by another one
(e.g., a recovery scenario or maybe a change of the extent of the
transport connection), then I think it's sufficient for the connection
controller to be told that it should not change the cross connection
(matrix level subnetwork connection).  If the overall action fails for
some reason, the call entity can then decide whether to try again,
and/or tell the management plane what happened.

I believe that this is consistent with what the existing protocol(s)
know when they are creating LSPs.  For example, a protocol instance is
not aware whether the connection being created is a result of a "break
before make" or "make before break" scenario, or that it is the 3rd
connection being created for a VCAT group. This understanding should
only be known by the initiator of the action.

Stephen