RE: Moving LSP ownership between control plane and management plane

["MEURIC Julien RD-CORE-LAN" <julien.meuric@francetelecom.com>]

Hello Diego, Adrian and all.

In my view, I feel that moving LSP ownership between MP and CP are very
useful functions for a carrier operational network, whether it be for
migration to GMPLS or for network maintenance.
As far as I understand, the I-D is a proposal for the signalling part
and does not pretend solving every associated issues. Some work will
probably be needed to implement the whole process, but this part looks
interesting to me.

I would be glad to discuss further this matter next week in Paris.

Regards

Julien 


Julien Meuric
France Telecom
Research & Development
Core Network
2, avenue Pierre Marzin
22307 Lannion Cedex - France
Tel : + 33 (0)2 96 05 28 28
Fax : + 33 (0)2 96 05 12 52
http://www.francetelecom.com/rd/


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Diego Caviglia

Hi Geroge,
           sorry but I don't see how the management effort is something
related to this ID and more in general with CCAMP.

There are already RFC ID that provide tools to signal LSP with ERO
filled
up to the Label level and of course this can be done only via
management, I
don't remeber any objections on that due to NMS impact.

I'd like to discuss here (I mean in the CCAMP ML) about the ID, that is,
if
it useful and if could work and not about the difficulties it implies
for
the NMS.

I'm open to discuss, and actually I did, NMS related issues on the ITU-T
ML.

Regards

Diego



George Newsome <gnewsome@ieee.org>@ops.ietf.org on 20/07/2005 11.03.00

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


To:    Adrian Farrel <adrian@olddog.co.uk>
cc:    ccamp@ops.ietf.org, Neil Harrison <neil.2.harrison@bt.com>, Dino
       Bramanti <Dino.Bramanti@marconi.com>

Subject:    Re: Moving LSP ownership between control plane and
management
       plane

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the
moment to argue the toss, so I'll reply as a note rather than
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly
those who would like to see just that. Related questions are how many
times in the life of the system might this be done for the same
connection? Is it cost effective to develop a highly reliable solution
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be
useful, but a technical discussion of whether changing a bit (and a slew
of procedures) in a signaling protocol actually provides the claimed
facility.

Because of the effort the management system needs to provide before
signaling might be involved, changing the signaling protocol gives the
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane
names, we can ask what happens to the cross connect object when it is
deleted as part of the hand off procedure? The behavior of this object
is that its deletion results in dropping the matrix connection, which is
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely
obfuscates the significant difficulties, which are glossed over by
stating that those difficulties occur at a different time.

Regards

             George



Adrian Farrel wrote:

> Thanks George,
>
> Useful input.
>
>
>>You asked for comments on this proposal, which was presented to ITU-T
>>Q14 experts in January of this year.
>
>
> Can you confirm that there were plenty of providers represented at the
> meeting.
>
>
>>There are so many issues involved in moving a connection from the
>>management plane to the control plane that involve intensive
management
>>action, that it is not evident that signaling need be involved at all.
>
>
> Interesting. It is certainly valuable to have a list of these issues
out
> in the open. I have made some comments in the appended meeting report.
>
> If the control plane is to take over the connection then we assume
that
> signaling state must be built so that the control plane could then
modify
> or tear down the connection. how would you propose that this be done
> without involving signaling?
>
>
>>As a personal opinion, it makes little sense to consider moving the
>>connection. It makes more sense to replace the connection with one set
>>up via the control plane, and to then delete the original management
set
>>up connection.
>
>
> The question arrises of how this would be done in a network with
limited
> resources. That is, if it is possible to set up a parallel conneciton
then
> the method you describe would be fine, but if there are not enough
> parallel resources then would you propose that a lambda (for example)
> could be used for the management-established connection and for the
> control-plane-owned connection at the same time? This might present
some
> difficulties as well.
>
> Do you have an opinion on my main question which is whether this tyoe
of
> change-over would ever be done in service?
>
> Thanks,
> Adrian
>
>
>>Excerpt of the meeting report of Q14 Experts, January 2005
>>
>>WD06 (Marconi) "G.7713 Modification in order to support Circuit
>>Migration" contains a modified version of draft G.7713 Revision as was
>>presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
>>contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to
extend
>>the concept of Call/Connection setup to setup/adopt and release to
>>release/de-adopt. In Connection Adoption both the SNC are not actually
>>created and the LC are not actually established due to the fact that
the
>>underlying physical resources are already in place. In the
>>Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
>>only the Control Plane information associated with then is removed and
>>the ownership is moved to Management Plane. Attributes for indicating
>>Adoption/Dis-adoption are proposed for the INNI Connection messages.
>>
>>The discussion was mainly on the Management plane and Control plane
>>actions required before signalling is involved. The group noted that
the
>>following issues need to be addressed:
>>
>>- Naming of transport resources to the control plane.  Before a call
can
>>be placed under signalling control, links that are involved in the
>>connection need to be given control plane names.  Without these, no
>>explicit route can be formed to match the resources of the connection.
>
>
> This is pretty obvious. But actually, this is an issue with moving the
> resources from one plane to another (or having them present in both
> planes). It is certainly a prerequisite for moving the connection, but
it
> is not functionally an element of moving the connection.
>
> The draft, as I read it, assumes that these operations have been
completed
> and then asks "how do I move the connection from one plane to the
other?"
>
>
>>- Resource state while under dual CP and MP views.  After resources
are
>>given control plane names, the resources are still viewed by the
>>management plane.  It may be necessary to create a new state for the
>>resource to indicate that the management plane cannot perform some
>>actions on the connection points as the control plane is about to take
>
> over.
>
> Yes. There is certainly scope for a race condition here. I believe
that
> the I-D proposes to (try to) make the transfer an atomic action from
the
> point of view of the change-over.
>
> Note, however, that it is wrong to assume that a resource belongs only
to
> the control or to the management plane at any moment in time. This may
be
> true with respect to the ability to provision/control connections, but
> resources that are available for use by the control plane can still be
> managed through the management plane. Thus, you take a laser out of
> service through the management plane, not through the control plane.
>
>
>>- Role of discovery functions (esp. CELA).  After control plane names
>>are allocated, distributed control plane functions need to be
associated
>>and communication adjacencies formed.  This too is a precursor to any
>>signalling procedures in migrating from the MP to CP.
>
>
> Note to CCAMP: CELA is Control Entity Logical Adjacency.
> This too is "obvious".
> But this discussion seems to be wide of the mark. Before deploying a
> control plane, it is clear that this type of operation needs to take
> place. Since (within the context of CCAMP) a control plane *is* going
to
> be deployed, we can assume this operation and move on to the
discussion
in
> the draft.
>
>
>>- Similarity of migration to synchronization after CP failure and
>>subsequent recovery.  Connection control procedures might be the same
in
>>migrating a call from the MP to the CP as the situation when the CP
has
>>failed and is recovering.  Here, the network connections are already
in
>>place, but connection and call state need to be created to match it.
>>Knowledge of the call and what the connection should be is obtained
from
>>the MP for migration, and from some reliable database in the recovery
>
> case.
>
> This is a valid point.
> Control plane failure, however, is unlikely to be total. That is, it
would
> be unusual for more than one control plane link or node to fail. Thus,
in
> the control plane, the "reliable database" is distributed and recovery
can
> follow the procedures outlined in
draft-ietf-ccamp-rsvp-restart-ext-03.txt
>
> It would certainly be worth considering whether the procedures used
for
> control plane recovery could be applied to transfer of ownership from
the
> management to control plane. at the moment, I suspect that they could
not
> because the restart extensions assume a specific period during which
> signaling is associated with recovery.
>
> We would also need to look at the reverse process (transfer from CP to
MP)
> that is not possible to cover by CP restart procedures.
>
>
>>- Call awareness of migration vs. connection being unaware of
migration.
>>  When connection state is being created to match an existing
>>connection, the connection controllers (CCs) do not require awareness
of
>>why this is happening as the context could be migration or recovery.
A
>>mechanism to create control state without affecting transport plane
>>state is needed in the CCs.  Call controllers though do need migration
>>awareness as they need to obtain/derive call identification from the
MP.
>
>
> I disagree.
> Connection controllers must be able to distinguish between resources
that
> are already in use and cannot be assigned to a new connection, and
those
> that are already in use and can be assigned to a new connection
because
> the connection is replacing an existing connection. If this were
happening
> entirely within the control plane we would use resource sharing, but
when
> the operation spans the control and management planes resource
> ownership/sharing is more complex and the conneciotn controller needs
to
> be able to issue the approriate instrucitons for the assignment of the
> resources.
> On the other hand, call controllers do not need awareness of the
details
> of the realisation of the connections.
>
>
>>In summary, the group decided that it is premature to consider
>>signalling procedure before the above issues, amongst other, have been
>>studied. However the contribution does enable the group to expose in a
>>larger context the interaction between CP and MP for connection
>>migration. The above issues were included in SP24 of the G.7713 Living
>>List (see WD22).
>
>
>