Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

[Dimitri.Papadimitriou@alcatel.be]

hi adrian, diego, all

the scope of the mechanism should have been limited to create a control
plane state when the corr. data plane resources have already been
provisioned for the same connection by local config., MP, MPLS (for PSC
LSP), whatever ... all the specifics in terms of migration from MP to CP
and vice-versa are NOT to be standardized and falls outside the scope of
the GMPLS protocol work per se; on the other side, if we need to initiate a
work item on the migration to GMPLS *CONTROL PLANE* and come out with some
operational guidelines, i strongly recommended to link this work with the
item already started on this specific topic

note: each time we include a bit in the ADMIN_STATUS object that refers to
an operation which is not limited to a control plane related operation we
should not "standardize" that behaviour; reason is because jumping in the
bandwagon of standardizing usability and applications of the GMPLS control
plane mechanism has as many profiles as users (we have had the same
discussion during the p&r discussion loop); in the present case, we would
be in a situation where we would be std'ing the usability of a CP mechanism
assuming a that a) the MP <-> CP interaction is known (and hence also
std'ized ?) but in a case where the following config is to considered we
would also need to make assumptions about MP_1 <-> MP_2

MP_1 ---- MP_2
  |         |
CP_1 ---- CP_2


---



Hi Diego,

Thanks for taking some of the burden of WG chair from my shoulders.

Before pushing this any further, I would be interested in your response to
the recent liaison from ITU-T SG15 (text below).

I would also like to understand whether this type of function is really
likely to be used repeatedly or whether we are describing a "one shot"
solution to an in-service upgrade.

Cheers,
Adrian
===
Text of liaison from SG15

At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that
CCAMP is discussing the issue of migration of connections under the
management plane to the control plane.  This topic has been discussed in
previous SG15 meetings and some of the conclusions are offered that may be
helpful to CCAMP.
The motivation for migrating calls and connections includes applying a
control plane to an existing transport network, and/or combining a
transport network whose connections are managed by an OSS and one whose
connections are established by a control plane.
Two broad issues with connection migration are dual views of a resource,
and the preconditions before protocol state is created for a connection.
Dual views of a resource concerns the need for a resource to be in both
management and control plane view the same time.  This is because although
the control plane may have responsibility of allocating/releasing
connections in subnetworks (a node is a smallest subnetwork), the
management plane still has responsibility for other functions on the
resource.  Changing the responsibility of allocating/releasing connections
requires more state for actions like rolling back a migration action due
to failures.
Preconditions for migrating from the management plane to control plane are
extensive and may involve much planning because the context for the
control plane has to be in place.  This includes:
- Naming of resources.  Both node and link naming are required before
signalling protocols can run.  Without this, no explicit route can be
formed to match the resources of the connection.  Naming of multiple nodes
and links has to be planned ahead of time.
- Control plane component adjacencies must be established.  In GMPLS the
control adjacencies are separate from bearer adjacencies and do not have
to coincide.  Planning and establishing those adjacencies is needed before
migration can be initiated.
- Links must be pre-configured and made visible to control plane routing.
- For each service and the associated connections to be migrated, the
service name, connection names, and explicit resource lists (in the
control plane name space) need to be passed from the management plane to
the control plane.
Once this is done, connection state in the control plane can be created
for an existing connection and the resources placed under the view of the
control plane.  Taken together, the preparation for migrating even one
connection suggests that a whole set of the transport resources be
prepared at the same time.
Finally, when connection state is being created to match an existing
connection, the connection controllers (signalling entities) should not
require awareness of why this is happening as the context could be
migration or other operation.  A mechanism to create control state without
affecting transport plane state is needed in the connection controllers.
It is important to ensure that the connections are not deleted when the
management plane relinquishes control of the resources. Entities that
initiate the connection (Call controllers) do need migration awareness as
they need to obtain/derive service (call) identification from the
management plane.  This is because the identity of connections created by
management planes are typically stored in OSS inventory systems, as well
as the identity of the service to which the connection is associated with.
The general conclusion is that the preparation for, and operational
impacts of, connection migration are much larger and more complex than the
actual control plane procedures to create signalling state for an existing
connection. These procedures will only be invoked once in the life time of
the network. For these reasons, Q12/15 and Q14/15 have decided not to
pursue a solution to this problem.


----- Original Message -----
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
To: "ccamp" <ccamp@ops.ietf.org>
Sent: Tuesday, December 06, 2005 11:34 AM
Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus


>
> Folks,
>        a week has passed from the below e-mail, there has been only one
> replay from a carrier the answers were for yes for both question 2 and
3.
>
> Now I'll try to put the question in a different way.
>
> Do anyone think that the ID should not be moved to WG status?
>
> Regards
>
> Diego
>
>
>
>
>
> "Diego Caviglia" <Diego.Caviglia@marconi.com>@ops.ietf.org on 29/11/2005
> 08.08.59
>
> Sent by:    owner-ccamp@ops.ietf.org
>
>
> To:    ccamp@ops.ietf.org
> cc:    "Dino Bramanti" <Dino.Bramanti@marconi.com>, "Dan Li <danli"
>
> Subject:    Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus
>
>
> Hi all,
>            during the last IETF meeting unfortunaltely there was not
enough
> thime to present and discuss the ID in the subject, nevertheless I think
> (but I'm an authour) the ID satisfy a real request from the Carries
> community.
>
> I'd like to ask you some questions
>
> 1.        Are there any comments on the ID?
>
> 2.        Mainly for the carriers. Do you think the ID describes an
useful
> tool?
>
> 3.        Should the ID moved to the WG status?
>
> Of course my answer for 2 and 3 are Yes and Yes ;-)
>
> Regards
>
> Diego
>
>
>
>
>
>
>