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

["Bryskin, Igor" <ibryskin@movaz.com>]

Hi Don,

> 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. 

IB>> One could argue that problems (and very serious ones) could be well hidden and could be discovered at any time. Also running production network is not the same as running test bed. Besides, to a large extent it could be purely psychological issue: as Diego put it "I always need a parachute when I try a new plane no matter how good is this plane: no parachute - no deal"

What is the difference between a MP based connection and CP based
connection with a static ERO and no backup? 

IB>> The difference is which plane owns the connection, meaning, what tools operator uses to, say, modify or release the connection. It is not about path computation, so whether ERO is static or not is irrelevant.

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?

IB>> The real issue (and I'd say the biggest GMPLS problem at the moment and for some time already) is operator's nervousness deploying the GMPLS and we need to do everything that could improve their comfort level and confidence.

Cheers,
Igor

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>