RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Igor

> -----Original Message-----
> 
> Dimitri,
> 
> My understanding of the MP->CP migration process failure and 
> it's "back-out" requirement is as follows:
> 
> a) immediate failure of creating CP state for the services 
> provisioned by MP. This failure does not require CP->MP feature
> b) initial migration MP->CP succeeded, however, after some 
> time (say, 1 month) of provisioning via CP (and possibly 
> creating many services solely via CP), provider decides that 
> CP is not good or mature enough and wants go back to 
> old-fashioned MP provisioning. I don't see how the operator 
> will not loose these new services without the CP->MP function.

I get the feeling we are grasping here.  The providers usually have a
staging and evaluation phase in a test bed before deploying a new
feature like a control plane.  If they decide they don't want it never
goes live. 

What is the difference between a MP based connection and CP based
connection with a static ERO and no backup? I would think a better goal
would be to make such a static version as good as a management plane
version. 

> 
> With all due respect the call on CP->MP function is 
> provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing.

So the providers should be writing the requirement document rather than
us trying to reverse engineer the root of the problem.  

I think there may be something here but I think even the requirements as
stated assume too much of the solution. What is the real issue?

Regards,
Don 


> 
> Igor
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Friday, August 25, 2006 2:51 AM
> To: Dan Li
> Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego 
> Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou 
> Berger; Li, Han
> Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)
> 
> 
> hi - here below a couple of comments
> 
> o) the first point and i think i mention this already is that 
> at the end speaking about MP in the present context restricts 
> applicability of the "migration", the purpose of this draft 
> is to create a control plane state when the same resources 
> are already in use by an entity external to the control plane 
> - call this an "import" function
> 
> o) the second when you write "Our main requirement for CP->MP 
> migration is to handle "back-out" of the MP->CP migration 
> process." is on itself confusing; what are you dealing with ? 
> that the transition fails during its instantiation or that 
> once LSP has a control plane state you want to move back 
> where it used to belong - the former is a real issue that has 
> never been discussed - the second is a non-issue (the other 
> entity takes care to rapatriate the state in case, i don't 
> think there is any need for an "export" function simple 
> because we are not going to tell to which entity the LSP 
> shall be brought back as we can have many of those)
> 
> o) the third point is when you mention "Modifying and tearing 
> down LSPs after control plane failure" i pointed already that 
> a migration from CP to somewhere else is impossible if you 
> don't get access to the CP iself in particular if it is under 
> failure - doesn't seem to be understood by authors (yet)
> 
> thanks,
> - d.
> 
> 
<snip>