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

[Dimitri.Papadimitriou@alcatel.be]

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