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

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 6 Dec 2005 12:34:47 +0100

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" <[email-masked]>@ops.ietf.org on 29/11/2005
08.08.59

Sent by:    [email-masked]

To:    [email-masked]
cc:    "Dino Bramanti" <[email-masked]>, "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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Dec 2005 12:40:34 -0000

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.

---

From: Loa Andersson <[email-masked]>
Date: Tue, 06 Dec 2005 14:19:17 +0100

Diego,

why did this consensus call not come from the wg chairs. I'm
afraid that under the current circumstances you need to
interpret non-responsiveness as non-interest.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]