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

From: "Bryskin, Igor" <[email-masked]>
Date: Fri, 25 Aug 2006 14:52:07 -0400

Dimitri,

No, it is not. D-bit was designed for a normal release. In normal release CP is responsible for breaking cross-connects (for example to avoid mis-connections during subsequent setups).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:46 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)

igor - but it is exactly what happens the resource reservation disappears 
from the control plane viewpoint (after which a pathtear is sent to remove 
the control plane state)

-d.

"Bryskin, Igor" <[email-masked]>
Sent by: [email-masked]
25/08/2006 20:37
 
        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)

Dimitri,

We use D-bit for graceful shutdown. D-bit means prepare for delete. We do 
graceful shutdown normally. We need another bit for this exceptional 
release (without breaking cross-connects).

Igor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, August 25, 2006 2:29 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)

igor 

but you don't need more than what's in RFC 3473 than disabling alarms 
during the move of the resource associated to the CP to another enitity 
and the send a pathtear to remove the control plane state (you don't need 
to involve the CP in moving the data plane resource on each node)

-d.

"Bryskin, Igor" <[email-masked]>
25/08/2006 20:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "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]>, "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)

Dimitri,

graceful deletion bit set in admin_status you mentioned about is sent in 
Path and Modify messages and is meant for disabling alarms before you 
starting LSP teardown.

What we are talking about is nothing but a bit in PathTear message 
instructing resource manager on each node not to break cross-connects 
while LSP resources are removed.

Igor

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

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.

Lou Berger <[email-masked]>
25/08/2006 19:25
 
        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,
         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.
>
>
>
>
>Lou Berger <[email-masked]>
>25/08/2006 18: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]>,
>[email-masked]
>         Subject:        RE: CP-->MP Issue (was RE: Polling for new WG
>I-Ds)
>
>
>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
>
>At 12:48 PM 8/25/2006, [email-masked] wrote:
>
> >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 ?
> > >
> > >
> > >
> > >
> > >Lou Berger <[email-masked]>
> > >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]>
> > >         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 21:03:44 +0200

igor

you are hanging on "breaking cross-connection" ... what i am telling to 
you is that there is no action required from the CP viewpoint beside 
preventing any error/alarm and removing the control plane state (for a 
data plane state that doesn't exist anymore from the CP perspective) there 
is no difference from the presence or absence of cross-connection ... 
otherwise we would have already a PathTear error of some kind.

you have in mind to involve the CP signaling in this move - which is 
totally beyond scope - 

-d. 

25/08/2006 20:52

Dimitri,

No, it is not. D-bit was designed for a normal release. In normal release 
CP is responsible for breaking cross-connects (for example to avoid 
mis-connections during subsequent setups).

Igor

-----Original Message-----

the control plane state)

-d.

Dimitri,

Igor

-----Original Message-----

igor 

-d.

Dimitri,

Igor

-----Original Message-----

hope this clarifies,
-d.

Dimitri,

Lou

errors
allowed
that

-
John
present
WG
outside
it's
requirement,
state