RE: Moving LSP ownership between control plane and management plane

[<neil.2.harrison@bt.com>]

Hi Diego.....No I don't think what you are saying is useless, and I'm
sorry if that was the impression I conveyed .......in fact you MUST
consider these aspects (eg the ones George flagged) when you add a CP.
What I was trying to point out is the IMPORTANCE of a CP here relative
to other stuff.  Let me just play out the logic again as briefly as I
can.

As we move towards the duct the importance/value of the control-plane
diminishes.  So for addressing S-PVCs and resilience issues its
fine......where I have grave doubts are those who think they can create
'topology on the fly' (for other client layer networks).  A key factor
here is acceptable GoS/business models....our studies indicate that to
be viable one would need a waiting time (post demand epoch) of at least
the same order as the expected holding time.....now figure out what that
really means.  And of course this still assumes everything BELOW this
SVC level is already provisioned.  

Then there is the issue of 'who owns which layer?'.....and this means
the overriding requirement that must be addressed 1st is client/server
functional decoupling.  Closely related to this 'who owns which layer'
issue is how the 3 planes of one layer network are provided over the
*traffic plane* of another/lower layer network....and I gave a very
detailed response to Igor on this recently.

And once you piece it all together then you realise we can't have full
convergence from IP to Optics....and a smart observer at this point
might ask 'so why are folks being prescriptive about the choice of
functional components, eg addressing, signalling, routing?'  For example
I could postulate that PNNI is a better signalling protocol than RSVP
...and why would anyone in their right minds start with v4 addressing
when they already know its problems? Should at least use v6 here IMO.
Maybe I only need static routing and this should be a centralised
function?  

And finally...even when you add the CP it is fact of life, with which I
see you agree, that the MP is still king here.....a CP without a good MP
is rather useless.

regards, neil

> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: 20 July 2005 08:52
> To: Harrison,N,Neil,IKM1 R
> Cc: <gnewsome; <adrian; <ccamp
> Subject: RE: Moving LSP ownership between control plane and 
> management plane
> 
> 
> 
> 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).
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
>