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

[Dimitri.Papadimitriou@alcatel.be]

diego - 

i think this has been mentioned a couple of times - there is no need to 
make any assumption about MP whatsover in the context of CP capability 
we're discussing here - discussion deviated due to the context where the 
present i-d has been discussed

this i-d shall just focus on an import functionality of an already 
allocated resource (without making assumption on its current owner) this 
turns out that there is no possibility to have a revertive behaviour as 
from CP -> X, as the former won't keep track of this origin

the only thing this i-d could mention is that the previous owner Y may 
wish to provide from its own import functionality such as to allow CP -> Y 
transition

thanks,
- d.





"Diego Caviglia" <Diego.Caviglia@marconi.com>
Sent by: owner-ccamp@ops.ietf.org
25/08/2006 10:56
 
        To:     ibryskin@movaz.com
        cc:      "Don Fedyk" <dwfedyk@nortel.com>, "Lou Berger" 
<lberger@labn.net>, "Diego Caviglia" <Diego.Caviglia@marconi.com>, 
<ccamp@ops.ietf.org>
        Subject:        RE: CP-->MP Issue (was RE: Polling for new WG 
I-Ds)



Igor,
      what you say is exactly what we had in mind thinking about the ID.

Regards

Diego



"Bryskin, Igor" <ibryskin@movaz.com> on 24/08/2006 18.09.36

To:    "Don Fedyk" <dwfedyk@nortel.com>, "Lou Berger" <lberger@labn.net>,
       "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc:    <ccamp@ops.ietf.org>

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

Don,

> The other point that baffles me is there is not one "standard" MP that
> I'm aware of so really we are talking many variations of MP to a
> standard CP. So how do you define a CP to variations of MPs? The
> document currently oversimplifies this aspect IMHO.

I don't think we need to assume that MP is standard in the context of
CP->MP and MP->CP discussion. IMO it does not even have to be MP. 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..

Igor


> -----Original Message-----
>
> Diego,
>          In my experience in talking about this feature with
> carriers is that some (but not all) will require such
> symmetric behavior.  I think the other rational for this
> feature are irrelevant.  Again, the sole reason I've seen for
> this requirement is that to deploy MP->CP some will require
> that there be support for CP->MP.
>
> 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 SHOULD level requirement is sufficient for this
> capability, but I'd be interested if those representing
> carries on the list differ.
>
> Lou
>
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
>
>
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the
> community
> >is strongly against of CP->MP even in the form of a should/shall/may
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
>
>
>