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

From: "Bryskin, Igor" <[email-masked]>
Date: Fri, 25 Aug 2006 09:47:06 -0400

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: [email-masked]
[mailto:[email-masked]]
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 <[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,

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: "Don Fedyk" <[email-masked]>
Date: Fri, 25 Aug 2006 10:40:01 -0400

Hi Igor

> 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 

> Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego 
> Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou 
> Berger; Li, Han
> 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>

---

From: [email-masked]
Date: Fri, 25 Aug 2006 17:49:17 +0200

igor

point a) i don't say that the CP import requires MP intervention - i just 
say this is the only case that requires specification from CCAMP 
perspective

point b) then operators askes to his new fashioned MP to implement an 
import function - why shall CCAMP care about exporting CP states ? 

-d.

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

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

thanks,
- d.

Hi all,

Best regards,

Dan Li

---

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

lou - and why shall CCAMP provide a function to export states outside of 
its domain of competence

thanks,
- d.

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

Don,

>stated assume too much of the solution. What is the real issue?

Per my previous e-mail:
At 01:01 PM 8/24/2006, Lou Berger wrote:

>At 10:48 AM 8/24/2006, Don Fedyk wrote:
>>[...]
>>If we were to ask could you live without the CP->MP feature what
>>response would we get versus asking if CP->MP is a soft requirement.
>
> From the discussions I've had on this with carriers, for some it's 
> a don't care, for others they won't deploy control plane without 
> this capability.
>
>Lou

AND
At 08:15 AM 8/24/2006, Lou Berger wrote:
>[...]I therefore think the definition of CP->MP *is* 
>required.  There are multiple options for meeting this requirement, 
>but the solution must provide the "fallback" capability for services 
>existing at the time of the initial MP->CP transition and those 
>created after the transition.
[...]

I think a capability to remove LSP state while leaving forward state 
untouched will meet the requirements of those I've talked with.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Aug 2006 11:49:26 -0400

Don,

Per my previous e-mail:

AND
[...]

Lou

---

From: [email-masked]
Date: Fri, 25 Aug 2006 18:48:47 +0200

lou,

like i replied to igor

"entity X wants to recuperate a CP state - just let it do - if so allowed

then send a PathTear since there is no resource anymore associate to that 
state (but this does not require any specific documentation)"

we would deleting a path/resv state for which no resource are allocated - 
we did already that exercise - GR deletion.

much thanks,
-d.

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

Dimitri,
         Removing state should be a simple process of deleting local 
control plane state while not impacting the data plane 
state.  Exporting, at least to me, implies a more complicated API or 
other information transaction processing, which is certainly not needed 
here.

I think we're talking about a mechanism that should require a single 
"preserve data plane" bit in a PathTear message.  Nothing more.

Lou

At 12:14 PM 8/25/2006, [email-masked] wrote:

>lou - isn't "remove" or "export" having the same meaning in the present
>context ?
>
>
>
>
>Sent by: [email-masked]
>25/08/2006 17:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <[email-masked]>, "Farrel, Adrian"
><[email-masked]>, "ccamp" <[email-masked]>, "Dan Li"
><[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
>"Diego Caviglia" <[email-masked]>, "Don Fedyk"
><[email-masked]>, "Bryskin, Igor" <[email-masked]>, "Drake, John
>E" <[email-masked]>, "Li, Han" <[email-masked]>
>Who said anything about exporting state?
>
>At 11:51 AM 8/25/2006, [email-masked] wrote:
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Aug 2006 12:57:23 -0400

Dimitri,

huh, why would there be no resources, i.e., data plane state, 
associated with the LSP?  If this were the case, I agree the whole 
discussion would be moot.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Aug 2006 11:57:08 -0400

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Aug 2006 13:25:41 -0400

Dimitri,
         I really don't understand your point.  Can you restate/rephrase?

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

>lou
>
>resource are present (data plane state remains) the operation we're
>discussing about is local and consist in associating that resource to
>another entity - you GR the path because you don't want to generate errors
>- but then that's it you just have to retrieve the CP state
>
>- d.
>
>
>
>
>25/08/2006 18:57
> > > > >I think there may be something here but I think even the
>requirements
> > >as

---

From: [email-masked]
Date: Fri, 25 Aug 2006 19:34:43 +0200

lou - i mean that in case an LSP for whatever reason needs to be moved 
from the control plane to another place

this is already covered in RFC 3473 - the LSP is signaled with graceful 
deletion bit set in admin_status, then on each node the resource is 
associated to that entity (which is not a CP business) and then the 
control plane state is removed

hope this clarifies,
-d.

25/08/2006 19:25

Dimitri,

Lou

At 01:03 PM 8/25/2006, [email-masked] wrote:

> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of

---

From: [email-masked]
Date: Fri, 25 Aug 2006 19:03:32 +0200

lou 

- d.

Dimitri,

Lou

requirements

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Aug 2006 12:32:06 -0400

Dimitri,
         Removing state should be a simple process of deleting local 
control plane state while not impacting the data plane 
state.  Exporting, at least to me, implies a more complicated API or 
other information transaction processing, which is certainly not needed here.

Lou

---

From: [email-masked]
Date: Fri, 25 Aug 2006 18:14:04 +0200

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Aug 2006 14:57:37 -0400

Dimitri,
         I agree that all is needed is a single bit.  Unfortunately, 
the bits you mention are used for other purposes.  (i.e., alarm free 
LSP deletion.)

Lou