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

[lidan 37133 <danli@huawei.com>]

Hi Adrian,

Please see my comments below.

Regards,

Dan Li


----- 原邮件 -----
从: Adrian Farrel <adrian@olddog.co.uk>
日期: 星期二, 十二月 6日, 2005 下午8:40
主题: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus

> 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 
> reallylikely to be used repeatedly or whether we are describing a 
> "one shot"
> solution to an in-service upgrade.

MP2CP and CP2MP migration can be used for many scenarios, some cases are given 
here:
1) For control plane upgrade, after introduced the control plane, the services 
can be migrated from MP to CP.
2) For some reason, only partial functions of CP are used by the operators, 
like resource discovery, but services still provided by MP. Later they want 
such services be migrated from MP to CP, and MP to CP is also needed just in 
case they want to roll back.
3) This feature also can be used for CP graceful shutdown.
4) For some serious CP failure cases, when CP session can not be recovered
in time, the connections under control of CP can be migrated to MP, so the
service will not be interrupted.
5) More cases are welcome...
So this is not one time use feature for the carriers.

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

Dual views of resources is not the problem at all. When a resource is
under the control of CP, the MP should still have the visibility of the 
resource, because CP is connection focused and *NOT* for all the functions, 
so MP should response for "other functions" on the resource. If the 
resources under control of CP have dual visibility under both CP and MP, 
the resources under control of MP should also have dual visibility.

> resource.  Changing the responsibility of allocating/releasing 
> connectionsrequires more state for actions like rolling back a 
> migration action due to failures.

This is the issue of concurrent access to resources under the control of
both CP and MP, and it can be deal with some resource access locking
scheme. But it is a implementation-related issue, so it's out of scope
of this I-D.

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

These preconditions assume the resource is either controlled by control
plane or by management plane. But this is not true, as we mentioned before,
even the resource is under the control of control plane, the management
plane still has responsibility for many functions on the resource. So these
preconditions also can be applied to the resource which under the control
of management plane.
The current GMPLS can support the resource discovery (naming of resource),
the discovered resource also includes which under the control of MP.
It's doesn't matter which plane use it.Planning and establishing those
adjacencies are control plane bootstrap problem, so it's out of scope
of this I-D.

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

This already addressed in this I-D.

> Once this is done, connection state in the control plane can be 
> createdfor 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.

This already addressed in this I-D.

> 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 

No. The connection controllers should aware of this, because this
action is directed by the management plane, it's different with other
operations like connection creation.

> 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

The transport plane should not be touched. Please see I-D for details.

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

This should be done within the management plane before the migration
action be taken. So it's also out of scope of this I-D.

> 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 
> existingconnection. These procedures will only be invoked once in 
> the life time of

These problems actually are the issues of ASON architecture, not for GMPLS.
It is the time for these issues to be fixed in the ASON architecture.

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