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

["Zafar Ali \(zali\)" <zali@cisco.com>]

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> Dimitri.Papadimitriou@alcatel.be
> Sent: Friday, August 25, 2006 1:01 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)
> 
> 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 
> 

I agree with Dimitri. Also Don mentioned a good point that there is no
standard MP. I am not sure why we should pursue this any further. 

Thanks

Regards.. Zafar 

> 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.
> 
>  
> 
> 
> 
> 
> 
> "Bryskin, Igor" <ibryskin@movaz.com>
> Sent by: owner-ccamp@ops.ietf.org
> 25/08/2006 18:39
>  
>         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)
> 
> 
> 
> 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: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> 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; owner-ccamp@ops.ietf.org
> 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" <ibryskin@movaz.com>
> Sent by: owner-ccamp@ops.ietf.org
> 25/08/2006 18:06
>  
>         To:     "Lou Berger" <lberger@labn.net>, 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>, "Li, Han" <lihan@chinamobile.com>
>         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:lberger@labn.net]
> Sent: Friday, August 25, 2006 11:57 AM
> To: Dimitri.Papadimitriou@alcatel.be
> 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, 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
> 
> 
> 
> 
> 
> 
>