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

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

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.

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

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.






Dan Li <danli@huawei.com>
25/08/2006 03:59
 
        To:     ccamp <ccamp@ops.ietf.org>
        cc:     "Li, Han" <lihan@chinamobile.com>, "Fedyk, Don" 
<dwfedyk@nortel.com>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego 
Caviglia <Diego.Caviglia@marconi.com>, Igor Bryskin <ibryskin@movaz.com>, 
"Farrel, Adrian" <adrian@olddog.co.uk>, Lou Berger <lberger@labn.net>, 
"Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Drake, John E" 
<John.E.Drake2@boeing.com>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)


Hi all,

The main motivation for this work is MP->CP migration. Our objective is to 

be able to introduce a control plane into an existing network without 
disrupting user traffic.

We understand that there are operators who would not want to perform this 
function. They might prefer to set up parallel LSPs using the CP and swap 
trafic to them before tearing down the MP LSPs, but we believe that this 
will not be possible in many busy networks. Other operators may prefer to 
have a network outage, but this will not be acceptable for all other 
operators. 
Therefore, in order to ensure interoperability between different vendors' 
equipment, we believe that a GMPLS process is required for this function. 
We 
fully expect it to be quite a simple process.

Our main requirement for CP->MP migration is to handle "back-out" of the 
MP->CP migration process. If there is some problem, the operator would 
like 
to be able to return to how things were before hand (i.e. MP control), 
without disrupting user traffic. We regard this as highly desirable, but 
probably not a mandatory requirement.

Modifying and tearing down LSPs after control plane failure is also a 
possible motivation, but the detailed requirements will need further 
examination. As has been pointed out, tear-down may be achieved relatively 

simply. But modification (for example, re-routing, increase in capacity, 
etc.) may be more complicated.

Other uses of CP->MP migration are interesting, but are not our main 
motivation, but we would like to observe that if the features that meet 
our 
requirements can also be used for other purposes then that is OK.

Obviously, from the discussions on the mailing list, our I-D does not 
currently present a sufficiently focused description of the motivation for 

this work. We welcome further discussion of the requirements to help us 
improve the draft.

It would be helpful in your discussions if you could understand that we 
are 
describing the requirements. If it turns out that the requirements can be 
met without changing the protocols, then we are very happy. But if you 
believe that no changes to the protocols are needed, we still need to 
state 
the requirements. So perhaps our conversation should be about the 
functional 
requirements not about the solutions.

Best regards,


Dan Li