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

From: Dan Li <[email-masked]>
Date: Fri, 25 Aug 2006 09:59:23 +0800

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

---

From: [email-masked]
Date: Fri, 25 Aug 2006 08:51:12 +0200

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 <[email-masked]>
25/08/2006 03:59
 
        To:     ccamp <[email-masked]>
        cc:     "Li, Han" <[email-masked]>, "Fedyk, Don" 
<[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego 
Caviglia <[email-masked]>, Igor Bryskin <[email-masked]>, 
"Farrel, Adrian" <[email-masked]>, Lou Berger <[email-masked]>, 
"Brungard, Deborah A, ALABS" <[email-masked]>, "Drake, John E" 
<[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

Hi all,

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.

MP->CP migration process. If there is some problem, the operator would 
like 

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.

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