[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dimitri,

We do need an action from CP: we need a way to signal differently normal graceful shutdown and "removal CP state only" shutdown,
We cannot overload or change semantics of the "D" bit at this point.

Igor

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, August 25, 2006 3:04 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;
owner-ccamp@ops.ietf.org
Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)


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. 





"Bryskin, Igor" <ibryskin@movaz.com>
25/08/2006 20:52
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <adrian@olddog.co.uk>, "ccamp" 
<ccamp@ops.ietf.org>, "Dan Li" <danli@huawei.com>, "Brungard, Deborah A, 
ALABS" <dbrungard@att.com>, "Diego Caviglia" <Diego.Caviglia@marconi.com>, 
"Don Fedyk" <dwfedyk@nortel.com>, "Drake, John E" 
<John.E.Drake2@boeing.com>, "Lou Berger" <lberger@labn.net>, "Li, Han" 
<lihan@chinamobile.com>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)


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: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
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;
owner-ccamp@ops.ietf.org
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" <ibryskin@movaz.com>
Sent by: owner-ccamp@ops.ietf.org
25/08/2006 20:37
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Farrel, Adrian" <adrian@olddog.co.uk>, "ccamp" 
<ccamp@ops.ietf.org>, "Dan Li" <danli@huawei.com>, "Brungard, Deborah A, 
ALABS" <dbrungard@att.com>, "Diego Caviglia" <Diego.Caviglia@marconi.com>, 

"Don Fedyk" <dwfedyk@nortel.com>, "Drake, John E" 
<John.E.Drake2@boeing.com>, "Lou Berger" <lberger@labn.net>, "Li, Han" 
<lihan@chinamobile.com>, <owner-ccamp@ops.ietf.org>
        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: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
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;
owner-ccamp@ops.ietf.org
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" <ibryskin@movaz.com>
25/08/2006 20:02
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" 
<lberger@labn.net>
        cc:     "Farrel, Adrian" <adrian@olddog.co.uk>, "ccamp" 
<ccamp@ops.ietf.org>, "Dan Li" <danli@huawei.com>, "Brungard, Deborah A, 
ALABS" <dbrungard@att.com>, "Diego Caviglia" <Diego.Caviglia@marconi.com>, 


"Don Fedyk" <dwfedyk@nortel.com>, "Drake, John E" 
<John.E.Drake2@boeing.com>, "Lou Berger" <lberger@labn.net>, "Li, Han" 
<lihan@chinamobile.com>, <owner-ccamp@ops.ietf.org>
        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: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
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;
owner-ccamp@ops.ietf.org
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 <lberger@labn.net>
25/08/2006 19:25
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Lou Berger <lberger@labn.net>, "Farrel, Adrian" 
<adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>, "Dan Li" 
<danli@huawei.com>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, 
"Diego Caviglia" <Diego.Caviglia@marconi.com>, "Don Fedyk" 
<dwfedyk@nortel.com>, "Bryskin, Igor" <ibryskin@movaz.com>, "Drake, John 
E" <John.E.Drake2@boeing.com>, "Li, Han" <lihan@chinamobile.com>, 
owner-ccamp@ops.ietf.org
        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, Dimitri.Papadimitriou@alcatel.be 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 <lberger@labn.net>
>25/08/2006 18:57
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     Lou Berger <lberger@labn.net>, "Farrel, Adrian"
><adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>, "Dan Li"
><danli@huawei.com>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
>"Diego Caviglia" <Diego.Caviglia@marconi.com>, "Don Fedyk"
><dwfedyk@nortel.com>, "Bryskin, Igor" <ibryskin@movaz.com>, "Drake, John
>E" <John.E.Drake2@boeing.com>, "Li, Han" <lihan@chinamobile.com>,
>owner-ccamp@ops.ietf.org
>         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, Dimitri.Papadimitriou@alcatel.be 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 <lberger@labn.net>
> >Sent by: owner-ccamp@ops.ietf.org
> >25/08/2006 18:32
> >
> >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> >         cc:     Lou Berger <lberger@labn.net>, "Farrel, Adrian"
> ><adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>, "Dan Li"
> ><danli@huawei.com>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
> >"Diego Caviglia" <Diego.Caviglia@marconi.com>, "Don Fedyk"
> ><dwfedyk@nortel.com>, "Bryskin, Igor" <ibryskin@movaz.com>, "Drake, 
John
> >E" <John.E.Drake2@boeing.com>, "Li, Han" <lihan@chinamobile.com>,
> >owner-ccamp@ops.ietf.org
> >         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, Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > >lou - isn't "remove" or "export" having the same meaning in the 
present
> > >context ?
> > >
> > >
> > >
> > >
> > >Lou Berger <lberger@labn.net>
> > >Sent by: owner-ccamp@ops.ietf.org
> > >25/08/2006 17:57
> > >
> > >         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > >         cc:     Lou Berger <lberger@labn.net>, "Farrel, Adrian"
> > ><adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>, "Dan Li"
> > ><danli@huawei.com>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
> > >"Diego Caviglia" <Diego.Caviglia@marconi.com>, "Don Fedyk"
> > ><dwfedyk@nortel.com>, "Bryskin, Igor" <ibryskin@movaz.com>, "Drake,
>John
> > >E" <John.E.Drake2@boeing.com>, "Li, Han" <lihan@chinamobile.com>
> > >         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, Dimitri.Papadimitriou@alcatel.be wrote:
> > >
> > > >lou - and why shall CCAMP provide a function to export states 
outside
> >of
> > > >its domain of competence
> > > >
> > > >thanks,
> > > >- d.
> > > >
> > > >
> > > >
> > > >
> > > >Lou Berger <lberger@labn.net>
> > > >25/08/2006 17:49
> > > >
> > > >         To:     "Don Fedyk" <dwfedyk@nortel.com>
> > > >         cc:     "Bryskin, Igor" <ibryskin@movaz.com>, Dimitri
> > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" <danli@huawei.com>,
>"Farrel,
> > > >Adrian" <adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>,
>"Brungard,
> > > >Deborah A, ALABS" <dbrungard@att.com>, "Diego Caviglia"
> > > ><Diego.Caviglia@marconi.com>, "Drake, John E"
> ><John.E.Drake2@boeing.com>,
> > > >"Lou Berger" <lberger@labn.net>, "Li, Han" <lihan@chinamobile.com>
> > > >         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