[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Adrian,
           please find response/comments in line.

Regards

Diego



"Adrian Farrel" <adrian@olddog.co.uk>@ops.ietf.org on 06/12/2005 13.40.34

Please respond to "Adrian Farrel" <adrian@olddog.co.uk>

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


To:    "ccamp" <ccamp@ops.ietf.org>, "Diego Caviglia"
       <Diego.Caviglia@marconi.com>
cc:

Subject:    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.
[dc] Ouch touched ;-) I apologize if I gave the impression of playing your
role, I was just trying to understand if there is interest in
this ID or not.

Before pushing this any further, I would be interested in your response to
the recent liaison from ITU-T SG15 (text below).
[dc] Ok I'll give an answer.

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.
[dc] This is a question that can be answered by Telco.  My feeling is that
it will be for sure used during the 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.
[dc] Agreed.

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

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

- Links must be pre-configured and made visible to control plane routing.
[dc] Agreed.

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

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.
[dc] Of course before migrate an LSP the control plane on the involved
resourse needs to be up and running.

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.
[dc] The only thing that the SC needs to know is that the data plane is
alredy configured, of course in case of failure of the signalling
date plane resources are not deleted.

A mechanism to create control state without
affecting transport plane state is needed in the connection controllers.
[dc] This is exatly, at least in our intention, what the ID proposes.

It is important to ensure that the connections are not deleted when the
management plane relinquishes control of the resources.
[dc] Agreed

Entities that initiate the connection (Call controllers) do need migration
awareness as
they need to obtain/derive service (call) identification from the
management plane.
[dc] Agreed, moreover also the intermediate TNEs do need migration
awarness, in the ID this is done using an Admin Status flag.

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.
[dc] Yes usually it is like this.

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.
[dc] Is that meaning that the CP impact is very low?  If yes I agree on
this and I'm also happy on this.
Actually I don't see any significative difference between the impact of
adding a control plane to an existing network and migrate the already
created circuit under the CP domain.

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.
[dc] This may be is correct but that once in the life is when the CP is
added to an alredy existing network.  So may be is only once in the life
but is during a very important and critic moment.

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