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

[Dimitri.Papadimitriou@alcatel.be]

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