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

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Diego 

In Line as well

> -----Original Message-----
> Hi Don,
>         in line.
> 
> Regards
> 
> 
> 
> "Don Fedyk" <dwfedyk@nortel.com>@ops.ietf.org on 24/08/2006 16.48.48
> 
> Sent by:    owner-ccamp@ops.ietf.org
> 
> 
> To:    "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)
> 
> Lou and Diego, all
> 
> Two points.
> 
> 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.
> [dc] I think that the poll request from Adrian was trying to 
> solve this point.
> 
> 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.
> [dc] This is not clear to me.  Could you please clarify?

[DF] Where do we find the standard MP representation of a Path? What
MIBS etc. Many legacy systems have differnet MP representations of this
and may use extra attributes or objects. It varies by which Optical or
packet based system GMPLS is to control. When moving to GMPLS we can
rationalize these objects to GMPLS objects but without
generation/storage and possibily signaling of these MP objects the
CP->MP mapping is incomplete.  

Regards,

Don  


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