Subject: Re: Polling for new WG I-Ds

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 16 Aug 2006 08:48:05 +0200

Hi All,
        yes to all.

Regards

Diego

"Adrian Farrel" <[email-masked]>@ops.ietf.org on 12/08/2006 16.56.02

Please respond to "Adrian Farrel" <[email-masked]>

Sent by:    [email-masked]

To:    <[email-masked]>
cc:

Subject:    Polling for new WG I-Ds

Hi,

As discussed in Montreal, we need to poll for a couple of new WG drafts.

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt

has been updated by the authors to provide further details and
clarification.

http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt

has been updated since the version discussed in Montreal.

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt

has been updated as Zafar says in his previous email.

Please send yes or no for these I-Ds.

Reasons and opinions are also welcomed.

Thanks,
Adrian

---

From: [email-masked]
Date: Mon, 21 Aug 2006 05:21:52 +0200

Yes to ALL.

Regards

Jing Ruiquan

China Telecom BRI

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Mon, 21 Aug 2006 00:54:33 -0400

Hi Dimitri, 

Please see my reply inline. 

Thanks for your support for Graceful Shutdown ID. 

Regards.. Zafar  

<snip> 

> informational imho - in its current version 
> 
> - not sure to understand why the PathErr/Notify can be 
> processed by the 
> head-end only (what about segment recovery and stitching 
> case) - why only 
> MBB is possible upon reception (pls use E2E recovery/Segment recovery 
> capabilities as you address GMPLS networks)
> 

This is a good point and we can address these scenarios in the next
version of the ID. 

> - compared to path-reopt, error description is identical for 
> the TE link 
> case which leads to the following point - if errors 
> code/value are the 
> same how to distinguish them (assuming that the query 
> procedure described 
> in path-reopt is used during the setup of that LSP) ? - 
> comment is more 
> for the path-reopt draft than yours but since there is an 
> overlap ... 

In that case I will let authors of the path-reopt draft to reply/
comment on this point. 

> it 
> must be addressed in a way or another (note that when fully head-end 
> driven operations look similar but there is a major 
> difference role of 
> timing and severity of the error code/value) 
> 
> - in case shutdown of a protected component link (of a bundle) is 
> initiated why can't link protection be used ?
> 

I think this also comes under the category of scenario you mentioned
above. We can address it and share the ID with you for further comments,
before publishing.

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 21 Aug 2006 09:46:01 +0200

Hi,

Yes to all

Regards,

JL 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : samedi 12 août 2006 16:56
> À : [email-masked]
> Objet : Polling for new WG I-Ds
> 
> Hi,
> 
> has been updated by the authors to provide further details 
> and clarification.
>

---

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Mon, 21 Aug 2006 09:36:06 -0700

Yes to all. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, August 12, 2006 7:56 AM
> To: [email-masked]

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Aug 2006 16:12:11 +0200

Hi Dimitri,
            in line.

Regards

Diego

[email-masked] on 23/08/2006 15.51.23

To:    "Diego Caviglia" <[email-masked]>
cc:    "ccamp" <[email-masked]>, "owner-ccamp"
       <[email-masked]>, Adrian Farrel <[email-masked]>,
       [email-masked]

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]

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 10:43:23 -0400

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: [email-masked] [mailto:[email-masked]]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

hi diego -

[snipped]

is

[snipped]

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 11:54:59 -0400

John.

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

JD:  Except that we go to great pains to ensure that this situation
never occurs. 

You are right, we do. In theory such situations should not happen, however, we all know that in practice there are always cases when original (especially proprietary) protocol solutions are not thought through enough, and it is impossible to maintain backward compatibility between the software releases. That's why I am talking about *major* upgrades. Furthermore, sometimes there is a need to actually downgrade software, for instance, when one wants to add to the network some older equipment. Again, the ability to do the CP->MP->CP trick would help

Igor

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Aug 2006 09:08:45 -0700

> 
> JD:  Except that we go to great pains to ensure that this 
> situation never occurs. 
> 
> You are right, we do. In theory such situations should not 
> happen, however, we all know that in practice there are 
> always cases when original (especially proprietary) protocol 
> solutions are not thought through enough, and it is 
> impossible to maintain backward compatibility between the 
> software releases. That's why I am talking about *major* 
> upgrades. Furthermore, sometimes there is a need to actually 
> downgrade software, for instance, when one wants to add to 
> the network some older equipment.

Why would anyone want to do this, especially without upgrading this
equipments' software?

> Again, the ability to do 
> the CP->MP->CP trick would help

Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has
perils of its own.

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 12:16:16 -0400

IB>> Because the new software was developed on the assumption that it will work on the new hardware. Your customer, on the other hand, purchased your old equipment and you want to protect his investment.

IB>> Except that they were not specific what those perils are.

Igor

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Aug 2006 09:27:05 -0700

> 
> Have you been in a situation when you just performed a 
> software upgrade and a network operator tells you that your 
> new release sucks and he wants the network in the state of 
> this morning prior to the upgrade? No? Than you are lucky.

JD: This means reverting to the previous version of control plane
software,
not the CP->MP->CP detour.

> 
> Besides, what is the problem with moving "hundreds/thousands 
> of LSPs from CP->MP"? 
> 
> Igor
> 
> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 11:43 AM
> To: Drake, John E; Bryskin, Igor; Diego Caviglia; 
> Dimitri.Papadimitriou
> Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian 
> Farrel <adrian; danli
> Subject: RE: Polling for new WG I-Ds
> 
> 
> Agree with John, and control plane failures don't (should 
> not/hope not) impact the data plane state. And before doing 
> such a sw upgrade, I would not want to have to move 
> hundreds/thousands of LSPs from CP->MP.
> 
> I'm not sure myself on what is meant by CP->MP, need to discuss more.
> 
> (chair hat off)
> Deborah 
> 
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: Wednesday, August 23, 2006 11:13 AM
> To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
> Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian 
> Farrel <adrian; danli
> Subject: RE: Polling for new WG I-Ds
> 
> Snipped
> 
> >

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Aug 2006 09:34:55 -0700

Snipped

> > Furthermore, sometimes there is a need to actually 
> Why would anyone want to do this, especially without 
> upgrading this equipments' software?
> 
> IB>> Because the new software was developed on the assumption that it 
> IB>> will work on the new hardware. Your customer, on the other hand, 
> IB>> purchased your old equipment and you want to protect his 
> IB>> investment.

This is not what you said initially.  You said 'add to 
the network some older equipment.'

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 13:44:07 -0400

IB>> I am talking about the situation when simple reverting is not possible due to incompatibility of the new and old software releases.

Furthermore, on more general note, if we decide that we need to be capable of doing MP->CP, just from the simmetricity point of view it makes a lot of sense to me to have CP->MP capability for debugging and testing the MP->CP move (if for nothing else) 

Igor

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 13:58:12 -0400

Ben,

> Deborah.
> (My hat off since I am talking to a lady)
> 

I'm not sure I understand the relevance of this.

IB>> Imagine the situation when a major software upgrade was performed on all network controllers. The new software is significantly different from the old release. After the upgrade a serious problem was discovered. The operator wants to go back to the old software. Simple software reversion is not possible. The operator does not want to loose any of active services. So what do you do in this case? I say, do CP->MP->CP

> Besides, what is the problem with moving "hundreds/thousands

The operating tenet is "if it aint broke don't fix it" so it'd likely
have to be a very good reason in order to make an operator move
hundreds/thousands of LSPs from CP->MP or MP->CP.  It'd also have to be
something forseeable as I can't see operators moving their LSPs from
CP->MP routinely when doing a software change.

IB>> From my remark above it should be obvious that I am not talking about routine CP->MP procedures. I am talking about "Don't stand, do something" kind of situation.

Igor

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Aug 2006 12:39:19 -0700

> 
> JD: This means reverting to the previous version of control 
> plane software, not the CP->MP->CP detour.
> 
> IB>> I am talking about the situation when simple reverting is not 
> IB>> possible due to incompatibility of the new and old software 
> IB>> releases.

JD:  This is the first time you have mentioned that you are assuming
that this reversion is not possible.  I think this is total nonsense for
two reasons.  1) I don't believe technically that this reversion would
ever *not* be possible.  Otherwise, I don't see how the new software
could have been incrementally deployed in the first place.  2) The
operator would never deploy  the new software unless had had verified
that it could be backed out.  Further, why would new CP->MP->old CP work
when new CP->old CP would not work?

> 
> Furthermore, on more general note, if we decide that we need 
> to be capable of doing MP->CP, just from the simmetricity 
> point of view it makes a lot of sense to me to have CP->MP 
> capability for debugging and testing the MP->CP move (if for 
> nothing else) 
> 
> Igor
> 
> >

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 14:05:41 -0400

Snipped

IB>> No, that's exactly what I meant. My customer purchased a ring of new devices with new software. The customer also happens to have several rings of older devices running older software. The customer wants to interconnect the new rings with old ones. The customer does not mind to downgrade the software on the new ring so that it will be compatible with other rings.

Igor

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 14:48:31 -0400

Deborah,

Have you been in a situation when you just performed a software upgrade
and a network operator tells you that your new release sucks and he
wants the network in the state of this morning prior to the upgrade? No?
Than you are lucky.

Db> that is totally different from this discussion, hopefully they know
what a backup is (for your benefit), and also one does not necessarily
want to use the backup since there could have been changes in the
network since the backup was made, unless the network is static;-) 

IB>> Exactly my point. If you can not or don't wnat to use backup, what is the way out of this mess?

Igor

Would
stongly suggest you (and the operator) have done sufficient testin

Besides, what is the problem with moving "hundreds/thousands of LSPs
from CP->MP"? 
Db> Good joke;-)

Igor

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Wednesday, August 23, 2006 11:43 AM
To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou
Cc: " ccamp " <ccamp; " owner-ccamp " <owner-ccamp; Adrian Farrel
<adrian; danli

Agree with John, and control plane failures don't (should not/hope not)
impact the data plane state. And before doing such a sw upgrade, I would
not want to have to move hundreds/thousands of LSPs from CP->MP.

(chair hat off)
Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E

Snipped

---

From: "Bryskin, Igor" <[email-masked]>
Date: Wed, 23 Aug 2006 17:06:31 -0400

that it could be backed out.  

IB>> Agree, I probably should have said *not feasible* instead of  *not possible*. Imagine that the new CP was run for 1 month before the problem was encountered. Using backup of old CP would mean loosing all services that were provisioned within this period. Likewise, if one made the MP->CP move, worked for some time and then discovered a problem, using old MP backups would mean loosing all services that were dynamically created or modified. CP->MP move would solve the problem.

Further, why would new CP->MP->old CP work
when new CP->old CP would not work?

IB>> Because you can not perform new CP->old CP conversion simultameously on all nodes.

Igor

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Aug 2006 12:50:15 -0700

> IB>> No, that's exactly what I meant. My customer purchased a ring of 
> IB>> new devices with new software. The customer also happens to have 
> IB>> several rings of older devices running older software. 
> The customer 
> IB>> wants to interconnect the new rings with old ones. The customer 
> IB>> does not mind to downgrade the software on the new ring 
> so that it 
> IB>> will be compatible with other rings.

As I said previously, the situation you are describing above is *not*
the same as 'add to 
the network some older equipment.'  What you are describing is adding
new equipment to an existing network, and there are many options for
doing this, but going from CP->MP is not one of them.  If the existing
equipment was deployed with an MP and you didn't want to upgrade it to
CP, you would just deploy the new equipment with MP from the beginning.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Aug 2006 16:24:27 -0700

IB>> Agree, I probably should have said *not feasible* instead of  *not 
IB>> possible*. Imagine that the new CP was run for 1 month before the 
IB>> problem was encountered. Using backup of old CP would mean loosing 
IB>> all services that were provisioned within this period.

JD: Let me guess.  You are now making the further assumption that the
databases of the old and new CPs are completely incompatible.  As I
indicated above, if incremental deployment and incremental roll back are
not supported, the new CP will never be deployed.  It's not like there
is anything new here.

IB>> Likewise, if 
IB>> one made the MP->CP move, worked for some time and then discovered 
IB>> a problem, using old MP backups would mean loosing all services 
IB>> that were dynamically created or modified.

JD:  What are you talking about?  We are discussing a CP update.

IB>> CP->MP move would solve 
IB>> the problem.

JD: Completely unsupported assertion.

IB>> Because you can not perform new CP->old CP conversion 
IB>> simultameously on all nodes.

JD:  You cannot perform new CP->MP conversion simultaneously on all
nodes either, and there is no reason to assume that simultaneous new
CP->old CP conversion is required.

Igor

> > Agree with John, and control plane failures don't (should not/hope 
> > not) impact the data plane state. And before doing such a sw 
> > upgrade, I would not want to have to move hundreds/thousands of LSPs

> > from CP->MP.