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

From: [email-masked]
Date: Fri, 25 Aug 2006 11:25:46 +0200

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" <[email-masked]>
Sent by: [email-masked]
25/08/2006 10:56
 
        To:     [email-masked]
        cc:      "Don Fedyk" <[email-masked]>, "Lou Berger" 
<[email-masked]>, "Diego Caviglia" <[email-masked]>, 
<[email-masked]>
        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" <[email-masked]> on 24/08/2006 18.09.36

To:    "Don Fedyk" <[email-masked]>, "Lou Berger" <[email-masked]>,
       "Diego Caviglia" <[email-masked]>
cc:    <[email-masked]>

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
>
>
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 25 Aug 2006 10:56:35 +0200

Igor,

Regards

Diego

Don,

Igor