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

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 24 Aug 2006 11:53:36 +0200

Dimitri,
         it depends if you use the parachute before the plane explode :-))

More seriously do you still have problems with the procedure if we move it
to a should/shall/may state?  I think that this would be enough for who
think is a good feture and wants to implement it and do not 'force' anyone
that disagree to implement it.

Regards

Diego

[email-masked] on 24/08/2006 10.18.28

To:    "Diego Caviglia" <[email-masked]>
cc:    [email-masked], [email-masked]

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

diego -

using your metaphore - if the plane explodes/crashes you can have the
nicer parachute it won't be of great help - meaning it is clear that is
not this process/parachute that is going to increase confidence in CP if
the problem is more fundamental and in part. not technical
(confidence/trust/etc.)

ps: operations are NOT symmetric (if you mean reflective since CP =/=
distributed MP)

"Diego Caviglia" <[email-masked]>
Sent by: [email-masked]
24/08/2006 09:09

        To:     [email-masked]
        cc:
        Subject:        CP-->MP Issue (was RE: Polling for new WG I-Ds)

In my mind the CP->MP feature can be useful for mainly two purposes:
1)    symmetricity with the companion feature (MP->CP)
2)    a sort of "parachute" in case something went wrong with the CP (Igor
made an example on this but another one could a foreseen problem with the
      signalling network, or may be the CP is not running well and its
restoration time are not in line with the expectation, or there is a merge
of    two different networks organizations and the resulting one is not
going to use -may be only at initial stage of merging process- the CP,
...)

We (the authors of the ID) agreed with Dimitri that CP->MP is not a must
and I have no problem to move it to should/shall/may state.

Is this in the scope of CCAMP? I think it is because is CP related and
imho
having such parachute can increase the confidence of carriers in CP.  I
mean I prefer to take a plane if I know I have a parachute on board.

However the focus of the ID is on MP->CP handover and if the community is
strongly against of CP->MP even in the form of a should/shall/may
requirement we can strip this out.

Regards

Diego

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 24 Aug 2006 08:30:30 -0700

> 
> The other point that baffles me is there is not one 
> "standard" MP that I'm aware of so really we are talking many 
> variations of MP to a standard CP. So how do you define a CP 
> to variations of MPs? The document currently oversimplifies 
> this aspect IMHO.

JD:  If you go back to the original MPL(ambda)S proposal, this was one
of the reasons given for building a standards based control plane.

> 
> Thanks,
> Don
> 
> > -----Original Message-----
> > 
> > Diego,
> >          In my experience in talking about this feature with
> > carriers is that some (but not all) will require such 
> > symmetric behavior.  I think the other rational for this 
> > feature are irrelevant.  Again, the sole reason I've seen for 
> > this requirement is that to deploy MP->CP some will require 
> > that there be support for CP->MP.
> > 
> > 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 SHOULD level requirement is sufficient for this
> > capability, but I'd be interested if those representing 
> > carries on the list differ.
> > 
> > Lou
> > 
> > At 03:09 AM 8/24/2006, Diego Caviglia wrote:
> > 
> > 
> > >[...]
> > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> > >must and I have no problem to move it to should/shall/may state.
> > >
> > >[...]
> > >However the focus of the ID is on MP->CP handover and if the
> > community
> > >is strongly against of CP->MP even in the form of a 
> should/shall/may

---

From: "Bryskin, Igor" <[email-masked]>
Date: Thu, 24 Aug 2006 12:09:36 -0400

Don,

> The other point that baffles me is there is not one "standard" MP that
> I'm aware of so really we are talking many variations of MP to a
> standard CP. So how do you define a CP to variations of MPs? The
> document currently oversimplifies this aspect IMHO.

I don't think we need to assume that MP is standard in the context of CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP..

Igor

> >is strongly against of CP->MP even in the form of a should/shall/may

---

From: "Bryskin, Igor" <[email-masked]>
Date: Fri, 25 Aug 2006 11:21:26 -0400

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 

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

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Fri, 25 Aug 2006 13:53:48 -0400

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, August 25, 2006 1:01 PM
> To: Bryskin, Igor
> Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, 
> ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; 
> Li, Han; [email-masked]
> i totally disagree you constantly referring to the MP while 
> CCAMP has NEVER linked control operations to MP operations - 
> these MP operations assumptions are outside scope of CCAMP 
> 

I agree with Dimitri. Also Don mentioned a good point that there is no
standard MP. I am not sure why we should pursue this any further. 

Thanks

Regards.. Zafar 

> in part. we are going to enter into a discussion for which we 
> won't get the bird out of the bush: addressing space between 
> CP and MP it took us more or less 4 years to disambiguate the 
> DP address space relationship with the CP and there is no 
> reason to start an endless debate now with the MP
> 
> -d.
> 
>  
> 
> 
> 
> 
> 
> "Bryskin, Igor" <[email-masked]>
> 25/08/2006 18:39
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "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]>, "Drake, John E" 
> <[email-masked]>, "Lou Berger" <[email-masked]>, 
> "Li, Han" 
> <[email-masked]>, <[email-masked]>
> Approximate scenarios:
> a) MP->CP scenario:
> MP provides CP with complete ERO (including labels) CP 
> signals SETUP with an IN-PLACE attribute, this causes 
> provisioning operations on each node without re-programming 
> cross-connects MP releases resource ownership after the 
> operation by some means
> 
> b) CP->MP scenario:
> 
> MP receives from CP complete RRO (including labels) MP 
> assumes resource ownership operation by some means CP signals 
> TEARDOWN with an IN-PLACE attribute, this causes release by 
> CP resources on each node without re-programming cross-connects
> 
> Igor
> 
> Sent: Friday, August 25, 2006 12:18 PM
> To: Bryskin, Igor
> Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, 
> ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; 
> Li, Han; [email-masked]
> you are asking for something outside the scope of ccamp
> 
> 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)
> 
> -d.
> 
> 
> 
> 
> 
> "Bryskin, Igor" <[email-masked]>
> 25/08/2006 18:06
>         To:     "Lou Berger" <[email-masked]>, Dimitri 
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "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]>, "Drake, John E" 
> <[email-masked]>, "Li, Han" <[email-masked]>
> Agree with Lou.
> Can I also quote my own email? :=)
> 
> "We are
> talking here about a capability of CP to acquire network 
> resources and build CP state for an LSP without actually 
> re-programming crossconnects (case MP->CP). Likewise, we are 
> talking about capability of CP to release resources and 
> destroy CP state for an LSP without re-programming 
> crossconnects (case CP->MP). It is out of scope of those 
> mechanisms how MP (or any other plane) assumes or yields the 
> ownership of resources of the LSP whose ownership is 
> transferred from/to CP."
> 
> So I think we are talking about two relatively simple and 
> very symmetrical 
> 
> CP functions.
> 
> Igor
> 
> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, August 25, 2006 11:57 AM
> To: [email-masked]
> Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, 
> Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; 
> Drake, John E; Li, Han
> Who said anything about exporting state?
> 
> At 11:51 AM 8/25/2006, [email-masked] wrote:
> 
> >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,
> >
> >At 10:40 AM 8/25/2006, Don Fedyk wrote:
> > >I think there may be something here but I think even the 
> requirements
> as
> >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
> >
> > >Regards,
> > >Don
> 
> 
> 
> 
> 
> 
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 08:42:13 +0200

Lou,

Lou Berger <[email-masked]> on 25/08/2006 17.49.26

To:    "Don Fedyk" <[email-masked]>
cc:    "Bryskin, Igor" <[email-masked]>,
       <[email-masked]>, "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]>

Don,

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

>>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:
>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.
[dc] This is exactly what we have in mind.
Lou

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 08:48:43 +0200

Lou,
     you are right the first version of the ID (that was about the protocol
solution) used a bit in the Administrative Obj in order to inform the TNE
to not remove the data plane state but just the control plane.

As you said is a very little and very simple modification.

Regards

Diego

Lou Berger <[email-masked]> on 25/08/2006 18.32.06

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

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 ?
>
>
>
>
>25/08/2006 17:57
>         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]>
> >lou - and why shall CCAMP provide a function to export states outside of
> >its domain of competence
> >
> >thanks,
> >- d.
> >
> >
> >
> >
> >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <[email-masked]>, "Farrel,
> >Adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Brungard,
<[email-masked]>,
> >"Lou Berger" <[email-masked]>, "Li, Han" <[email-masked]>

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 09:30:54 +0200

Dimitri,
         from my point of view the possibility to specify link components
and labels in ERO foreseen the existence of a MP that knows that
information so I can say that there are CP opertarion linked to MP.

Regards

Diego

[email-masked] on 25/08/2006 19.01.14

To:    "Bryskin, Igor" <[email-masked]>
cc:    "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]>,
       "Drake, John E" <[email-masked]>, "Lou Berger"
       <[email-masked]>, "Li, Han" <[email-masked]>,
       [email-masked]

i totally disagree you constantly referring to the MP while CCAMP has
NEVER linked control operations to MP operations - these MP operations
assumptions are outside scope of CCAMP

in part. we are going to enter into a discussion for which we won't get
the bird out of the bush: addressing space between CP and MP
it took us more or less 4 years to disambiguate the DP address space
relationship with the CP and there is no reason to start an endless debate
now with the MP

-d.

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "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]>, "Drake, John E"
<[email-masked]>, "Lou Berger" <[email-masked]>, "Li, Han"
<[email-masked]>, <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
I-Ds)

Approximate scenarios:

a) MP->CP scenario:

MP provides CP with complete ERO (including labels)
CP signals SETUP with an IN-PLACE attribute, this causes provisioning
operations on each node without re-programming cross-connects
MP releases resource ownership after the operation by some means

b) CP->MP scenario:

MP receives from CP complete RRO (including labels)
MP assumes resource ownership operation by some means
CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP
resources on each node without re-programming cross-connects

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 12:18 PM
To: Bryskin, Igor
Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego
Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han;
[email-masked]
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

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)

-d.

        To:     "Lou Berger" <[email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "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]>, "Drake, John E"
<[email-masked]>, "Li, Han" <[email-masked]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
I-Ds)

Agree with Lou.

"We are
talking here about a capability of CP to acquire network resources and
build CP state for an LSP without actually re-programming crossconnects
(case MP->CP). Likewise, we are talking about capability of CP to release
resources and destroy CP state for an LSP without re-programming
crossconnects (case CP->MP). It is out of scope of those mechanisms how MP
(or any other plane) assumes or yields the ownership of resources of the
LSP whose ownership is transferred from/to CP."

So I think we are talking about two relatively simple and very symmetrical

CP functions.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, August 25, 2006 11:57 AM
To: [email-masked]
Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,
ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)

At 11:51 AM 8/25/2006, [email-masked] wrote:

><[email-masked]>, "Drake, John E" <[email-masked]>,

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 28 Aug 2006 08:45:16 +0200

Dimitri,
         removing the control plane state of a crossconnection without
touching the data plane imho is in the scope of CCAMP.

Also because, but this is in the scope of a solution document, can be done
via Control Plane.

Regards

Diego

[email-masked] on 25/08/2006 17.51.38

To:    Lou Berger <[email-masked]>
cc:    "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]>, "Lou Berger" <[email-masked]>, "Li,
       Han" <[email-masked]>

thanks,
- d.

Don,

Per my previous e-mail:

AND
[...]

Lou