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

[Dan Li <danli@huawei.com>]

See my comments in line. Thanks! - Dan

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "ccamp" <ccamp@ops.ietf.org>; "Diego Caviglia" <Diego.Caviglia@marconi.com>
Sent: Thursday, December 08, 2005 6:29 PM
Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus


> 
> 
> 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

Partially agreed.

MP2CP ownership handover is not only the requirement of carriers' migration to ASON, 
it also can be used to handle the various failures of control plane. During the recent 
discussion, if the control states of control plane can not be recovered, what should we do? 
According to the principle "the transport plane should not be touched when there is a 
failure in the control plane", all the connections should be kept, this actually means CP2MP 
ownership handover, the MP will take over the control of these connections. Obviously, 
after the control plane is recovered, the MP2CP ownership handover may also be needed.

I think the procedure of MP2CP ownership handover belongs to control plane recovery 
process which is casued by some failures in the control plane, the only different is who 
triggers the control plane states recovery. For MP2CP ownership handover, this procedure 
is triggered by management plane. The process at the Ingress node maybe is a little bit different, 
but the process at all the following nodes should be same, so we can unify (via Recovery 
Label object) the processes of MP2CP ownership handover and control plane recovery. In 
another words, MP2CP ownership handover is the control plane recovery which is triggered 
by management plane.

Compared with the current Recovery procedure, MP2CP ownership handover includes 
looking up the cross-connection table in the transport plane, this is also compatible with the 
current recovery procedure.

CP2MP ownership handover is also similar to the control plane Graceful Shutdown. After 
the MP takes over the control of all the connections which previously are controlled by CP, 
the control plane can be gracefully shutdown.

> 
> 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
> >
> >
> >
> >
> >
> >
> >
> 
> 
>