RE: Polling for new WG I-Ds

["Bryskin, Igor" <ibryskin@movaz.com>]

Hi,

I agree with Diego on this. One of the reasons why operators are so nervous about using CP is CP's unpredictability (because of its dynamic nature). I am sure they will be more confident if/when they know that there is a way to undo everything or something that might go wrong with migration to CP without breaking active services.

Besides I can see at least one quite real application for CP->MP. Imagine that an operator wants to perform some major software upgrade with a new software version significantly incompatible with the previous one. One way to perform such an upgrade:
a) CP->MP;
b) perform software upgrade on all controllers
c) MP->CP

Igor

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Diego Caviglia
Sent: Wednesday, August 23, 2006 10:12 AM
To: Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli
Subject: Re: Polling for new WG I-Ds



Hi Dimitri,
            in line.

Regards

Diego



Dimitri.Papadimitriou@alcatel.be on 23/08/2006 15.51.23

To:    "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc:    "ccamp" <ccamp@ops.ietf.org>, "owner-ccamp"
       <owner-ccamp@ops.ietf.org>, Adrian Farrel <adrian@olddog.co.uk>,
       danli@huawei.com

Subject:    Re: Polling for new WG I-Ds

hi diego -





[snipped]

> hence, it is strongly suggested to identify conditions when such CP->MP
is
> required (and not an alternative to existing CP mechanisms) b/f
> progressing that part
>
[dan] In order to make the carriers' life easy, when we provide the MP->CP
conversion feature, the reverse procedure (CP->MP) may also is needed just
simply in case the carriers want to withdraw their previous decision, and
they also feel more comfortable with this "undo" function; In order to
achieve this, we should have the working control plane.

[dp] concerning CP->MP input you provided would be helpful to have
carrier's speaking for themselves

[dc] I think they or some of them already did this.  Looking at the pool
seems that at least 4 carries voted yes to the ID.

[dp] not sure they express specific opinion on this aspect which is "shall
we take care about how to step back from GMPLS ?" it may be the case but
then the discussion has much fundamental impact than the discussion around
this specific i-d
[dc] I dont' think they said "we agree on moving this ID to WG" without
having read the doc, the point in the ID (we already agreed that is not a
mandatory requirement but only optional) is that should (or may or shall)
be possible to move back to NMS a circuit that was provisioned by the CP.
That is in the ID.
I was just pointing out that some carriers have already expressed their
opinion on the ID and thus on the CP->MP feature.  This is in line with the
Dan sentence.

The sentence "shall we take care about how to step back from GMPLS?" was
not in the intention of the ID.


 - now there is indeed a side question shall CCAMP take
care about operators that want to step back from GMPLS or more generally
any control plane technology (usually concern is how to move forward not
backward)
[dc] Of course I think we should.

[dp] if i well understand your conclusion putting both of your answers
toghether it would mean that CCAMP should take care about how "removing"
GMPLS CP ?
[dc] No the point is that IMHO could be useful for carriers to have the
possibility to move a CP created circuit to the NMS.  May be this operation
can be performed via CP. This does not means to remove the whole control
plane.

... interesting opinion, it took 6 years for CCAMP to have something more
or less workable now you and your co-authors are probably trying to init
an item to disband this work, if this is the case i don't even understand
how we are polling for this document on this list
[dc] I don't think this is in the ID.  If my previous answer suggested this
is my fault.

[snipped]