RE: Moving LSP ownership between control plane and management plane

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

Hi Neil,
         it always a pleasure read your e-mail but I think I'm missing
something.

The basic purpose of the ID is to provide a simple mechanism to move LSPs
from a domain to another, I don't see any implication, with layering.
Better to say this ID have the same implication with layering as 'normal'
signalling.

Moreover I agree with you that NMS is the 'king' of the network and in fact
the ID forseen that is MNS to provide the right information to CP to move
the LSP from a domain to another one.

My basic question is: do someone think that having a mechanism to move
MP/CP created LSP under the CP/MP domain is useless?

My experience tell me that the answer is no, but I'm open to discuss this.

Regards

Diego



<neil.2.harrison@bt.com>@ops.ietf.org on 19/07/2005 23.36.27

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


To:    <gnewsome@ieee.org>, <adrian@olddog.co.uk>
cc:    <ccamp@ops.ietf.org>

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

Hi George....nice to hear from you...hope all is well with you,

This all sounds very reasonable to me.  At the end of the day, all a
signalling protocol is is a distributed agent of network
management.....in the types of large BW granularity networks being
discussed the NMS will always be king.   Sorry if that's a problem to
some folks, its just a fact for the way we see/implement it.

This also follows from a good understanding of the commercials at play
here.  That is, there is a major difference between:
-            a public service context (cf PSTN), or extending a similar
capability out to end-systems in the co-ps mode say, where
end-systems/applications drive trail set-up (ie SVCs across a UNI).
Here one hopes there could be a large population of users (think
peer-peer/BB) and that the trail holding-times are not 'too long'.  In
this environment there could be a viable business case based on a
providing a given GoS at some cost.....and it might solve some
(otherwise) hard QoS/pricing problems for operators....but I digress;
-            a private network builder service context where one is a
providing a (relatively long time-constant) traffic-engineering function
to a higher layer network, ie creating its topology.  This is a
client/server relationship and THE starting point for this must be
functional decoupling of the client and server layer networks because
they will often be owned by different parties.  We are talking
relatively long forecast/planning cycles here and long trail holding
times....esp when it comes to real physical build.  Further, the
potential population is rather small compared to the previous case.  If
folks look at whether there is a viable business case here based on a
providing a given GoS at some cost in an acceptable time period I
suspect they will be disappointed.

What this all means is that the control-plane is not such an important
topic as we move down the layered network stack towards the
duct....increasingly other factors like strong NMS and OAM assume a far
greater importance.  This is not to say a control-plane is not useful
but:
-            we should be clear there cannot be any common addressing and
routing functions across a set of nested layer networks, which is very
obvious when different parties own different layer networks....one can
(and should) re-use components (if they are the right ones), but they
will need to operate in different layer network spaces
-            signalling is a useful agent for functions like S-PVCs and
resilience.

Well that's our analysis anyway....if anyone knows different I'd be
happy to review their commercial assumptions with folks here.


regards, Neil

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of George Newsome
> Sent: 19 July 2005 12:44
> To: Adrian Farrel
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving LSP ownership between control plane and
> management plane
>
>
> Adrian,
>
> You asked for comments on this proposal, which was presented to ITU-T
> Q14 experts in January of this year.
>
> 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.
>
> 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.
>
> Appended is an excerpt of the meeting report detailing some of the
> issues that need to be resolved before signaling need be considered.
>
> Regards
>
>            George
>
> 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.
>
> - 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.
>
> - 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.
>
> - 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.
>
> - 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.
>
> 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).
>
>
>
>