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

From: "Bryskin, Igor" <[email-masked]>
Date: Fri, 25 Aug 2006 12:39:44 -0400

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)

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]>
Sent by: [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]>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)

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

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

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
> >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
>
> >Regards,
> >Don

---

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

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.

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

-d.

Agree with Lou.

"We are

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,

as