RE: Polling for new WG I-Ds

["Drake, John E" <John.E.Drake2@boeing.com>]

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

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.

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

> 
> 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
> 
> > 
> > Besides, what is the problem with moving "hundreds/thousands of LSPs

> > from CP->MP"?
> > 
> > Igor
> > 
> > -----Original Message-----
> > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
> > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 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.
> > 
> > 
> > 
>