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

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

In my mind the CP->MP feature can be useful for mainly two purposes:
1)    symmetricity with the companion feature (MP->CP)
2)    a sort of "parachute" in case something went wrong with the CP (Igor
made an example on this but another one could a foreseen problem with the
      signalling network, or may be the CP is not running well and its
restoration time are not in line with the expectation, or there is a merge
of    two different networks organizations and the resulting one is not
going to use -may be only at initial stage of merging process- the 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.

Is this in the scope of CCAMP? I think it is because is CP related and imho
having such parachute can increase the confidence of carriers in CP.  I
mean I prefer to take a plane if I know I have a parachute on board.

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: [email-masked]
Date: Thu, 24 Aug 2006 10:18:28 +0200

diego -

using your metaphore - if the plane explodes/crashes you can have the 
nicer parachute it won't be of great help - meaning it is clear that is 
not this process/parachute that is going to increase confidence in CP if 
the problem is more fundamental and in part. not technical 
(confidence/trust/etc.)

ps: operations are NOT symmetric (if you mean reflective since CP =/= 
distributed MP)

"Diego Caviglia" <[email-masked]>
Sent by: [email-masked]
24/08/2006 09:09
 
        To:     [email-masked]
        cc: 
        Subject:        CP-->MP Issue (was RE: Polling for new WG I-Ds)

going to use -may be only at initial stage of merging process- the CP, 
...)

Is this in the scope of CCAMP? I think it is because is CP related and 
imho
having such parachute can increase the confidence of carriers in CP.  I
mean I prefer to take a plane if I know I have a parachute on board.

Regards

Diego

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Aug 2006 08:15:50 -0400

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:

>[...]
>[...]

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 24 Aug 2006 10:48:48 -0400

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.

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.

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Aug 2006 13:01:13 -0400

>response would we get versus asking if CP->MP is a soft requirement.

 From the discussions I've had on this with carriers, for some it's a 
don't care, for others they won't deploy control plane without this capability.

Lou