Re: Moving LSP ownership between control plane and management plane

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

Hi Geroge,
           I remember quite well that discussuion, but I also remember that
the common feeling was that the proposed feature is useful.

I can agree that this implies some discussion on the naming of the resource
and so on but the ID assumes that all this stuff has been resolved.

Some more comment in line.

Regards

Diego





George Newsome <gnewsome@ieee.org>@ops.ietf.org on 19/07/2005 13.44.29

Sent by:    owner-ccamp@ops.ietf.org


To:    Adrian Farrel <adrian@olddog.co.uk>
cc:    ccamp@ops.ietf.org

Subject:    Re: Moving LSP ownership between control plane and management
       plane

Adrian,

You asked for comments on this proposal, which was presented to ITU-T
Q14 experts in January of this year.

There are so many issues involved in moving a connection from the
management plane to the control plane that involve intensive management
action, that it is not evident that signaling need be involved at all.
[dc] I agree with the fisrt part of your sentence but not with the second.
From a CP point of view 'adopt' a LSP or create a new one is more or less
the same (in fact the ID basically adds only one bit to the already
existing signalling protocol) so saying that '...is not evident that
signaling need be involved at all' for an adoption can be extended to
signaling in general and that is why I disagree.

As a personal opinion, it makes little sense to consider moving the
connection. It makes more sense to replace the connection with one set
up via the control plane, and to then delete the original management set
up connection.
[dc] Sorry but seems that this is traffic affecting that is something that
usually operators wants to avoid.


Appended is an excerpt of the meeting report detailing some of the
issues that need to be resolved before signaling need be considered.

Regards

             George

Excerpt of the meeting report of Q14 Experts, January 2005

WD06 (Marconi) "G.7713 Modification in order to support Circuit
Migration" contains a modified version of draft G.7713 Revision as was
presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
the concept of Call/Connection setup to setup/adopt and release to
release/de-adopt. In Connection Adoption both the SNC are not actually
created and the LC are not actually established due to the fact that the
underlying physical resources are already in place. In the
Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
only the Control Plane information associated with then is removed and
the ownership is moved to Management Plane. Attributes for indicating
Adoption/Dis-adoption are proposed for the INNI Connection messages.

The discussion was mainly on the Management plane and Control plane
actions required before signalling is involved. The group noted that the
following issues need to be addressed:

- Naming of transport resources to the control plane.  Before a call can
be placed under signalling control, links that are involved in the
connection need to be given control plane names.  Without these, no
explicit route can be formed to match the resources of the connection.
[dc] This is outside the scope of the ID and probabily also from the scope
of the CCAMP/IETF.
We assume that this point has been resolved in the ID.

- Resource state while under dual CP and MP views.  After resources are
given control plane names, the resources are still viewed by the
management plane.  It may be necessary to create a new state for the
resource to indicate that the management plane cannot perform some
actions on the connection points as the control plane is about to take
over.
[dc] Again this is a NMS related issue that is uotside the scope of the
ID/CCAMP and may be IETF.

- Role of discovery functions (esp. CELA).  After control plane names
are allocated, distributed control plane functions need to be associated
and communication adjacencies formed.  This too is a precursor to any
signalling procedures in migrating from the MP to CP.
[dc] Yes but the ID assumes that this has been done.

- Similarity of migration to synchronization after CP failure and
subsequent recovery.  Connection control procedures might be the same in
migrating a call from the MP to the CP as the situation when the CP has
failed and is recovering.  Here, the network connections are already in
place, but connection and call state need to be created to match it.
Knowledge of the call and what the connection should be is obtained from
the MP for migration, and from some reliable database in the recovery case.
[dc] Adrian comment is also my comment

- 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.
[dc] As above.

In summary, the group decided that it is premature to consider
signalling procedure before the above issues, amongst other, have been
studied. However the contribution does enable the group to expose in a
larger context the interaction between CP and MP for connection
migration. The above issues were included in SP24 of the G.7713 Living
List (see WD22).