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

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 24 Aug 2006 17:24:00 +0200

Hi Don,
        in line.

Regards

"Don Fedyk" <[email-masked]>@ops.ietf.org on 24/08/2006 16.48.48

Sent by:    [email-masked]

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

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?

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

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 24 Aug 2006 11:44:21 -0400

Hi Diego 

In Line as well

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

[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  

> >          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.
> >
> > 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.
> >
> capability, 
> > but I'd be interested if those representing carries on the list 
> > differ.
> >
> > Lou
> >