Subject: RE: Polling for new WG I-Ds

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

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

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.

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

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

-----Original Message-----
From: [email-masked] [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

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

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 17:17:55 +0100

Igor,

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

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

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

Ben

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 23 Aug 2006 13:38:57 -0500

Hi Igor- comments below (as >db, chair hat off) 

-----Original Message-----
From: Bryskin, Igor [mailto:[email-masked]] 
Sent: Wednesday, August 23, 2006 12:09 PM
To: Brungard, Deborah A, ALABS; Drake, John E; Diego Caviglia;
Dimitri.Papadimitriou

Deborah.
Db> thanks;-)

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;-) Would
stongly suggest you (and the operator) have done sufficient testing.

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

(chair hat off)
Deborah 

-----Original Message-----

Snipped

---

From: Richard Rabbat <[email-masked]>
Date: Wed, 23 Aug 2006 11:17:02 -0700

Ben,
see inline.

[email-masked] wrote:
> hundreds/thousands of LSPs from CP->MP or MP->CP.  
I guess the jury is still out w/r to CP->MP as the discussion on the ML 
shows; but w/r to MP->CP, when an operator decides to deploy a CP, then 
control functions that resided in the MP should be delegated to that CP. 
There needs to be a migration strategy for that operation.

> It'd also have to be
I believe the authors were concerned about error handling and are not 
talking about this as a routine operation

> Ben
Richard.