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

["Drake, John E" <John.E.Drake2@boeing.com>]

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

JD:  If you go back to the original MPL(ambda)S proposal, this was one
of the reasons given for building a standards based control plane.

> 
> Thanks,
> Don
> 
> > -----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
> > 
> > 
> > 
> 
>