Subject: [bmwg] Software Update Doc

From: Sarah Banks <[email-masked]>
Date: Wed, 20 Feb 2013 05:16:47 +0000

At IETF... 82? we discussed the idea of having a draft that characterizes a device under software upgrade. At long last, and 2 minutes late for cut off, we've worked out an initial draft. Since we missed the deadline, Al, our chair, suggested that we post the draft elsewhere, and submit the draft when submissions reopen on March 11. 

In the meantime, the draft we intent to upload can be found at:

http://www.encrypted.net/draft_issu_methodology-00.pdf

Abstract
Modern forwarding devices attempt to minimize any control and data
plane disruptions while performing planned software changes, by
implementing a technique commonly known as an In Service Software
Upgrade (ISSU).
This document specifies a set of common methodologies and procedures
designed to characterize the overall behavior of a Device Under Test
(DUT) subject to an ISSU event.

We welcome any comments, questions or suggestions you may have.

Regards,
Sarah (&Fernando &Gery)

---

From: David Newman <[email-masked]>
Date: Tue, 19 Feb 2013 22:02:52 -0800

> We welcome any comments, questions or suggestions you may have.

Tests of in-service software downgrades would be a welcome addition.

Network operators roll images forward *and backward* for a variety of
reasons. This is different than simply rolling back if ISSU fails, in
that a downgrade starts with the DUT running one fully functional image
and ends with an earlier one.

A few years ago a trade publication commissioned me to test one of the
first-ever ISSU implementations. It worked flawlessly. I then suggested
to the vendor's engineers that we use the same commands to roll back to
the previous image. Judging from the engineers' expressions, it was
pretty clear this hadn't been tried before; sure enough, the DUT crashed
when we ran the test.

dn

> 
> Regards,
> Sarah (&Fernando &Gery)
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg
>

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Wed, 20 Feb 2013 07:25:07 -0500

Thanks Sarah, &Fernando &Gery

I'll make one quick suggestion:
when you upload the draft to IETF, change the filename to
something like this:

draft-banks-bmwg-issu-meth-00.txt

this way, it will automagically appear at the bottom
of the bmwg tools page:
http://tools.ietf.org/wg/bmwg/

(as folks may notice, it's about getting the work published
and reviewed in bmwg, not about arbitrary deadlines, and it
always has been AFAICT)

Al
bmwg chair

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sarah Banks
> Sent: Wednesday, February 20, 2013 12:17 AM
> To: [email-masked]
> Subject: [bmwg] Software Update Doc
> 
> At IETF... 82? we discussed the idea of having a draft that characterizes
> a device under software upgrade. At long last, and 2 minutes late for cut
> off, we've worked out an initial draft. Since we missed the deadline, Al,
> our chair, suggested that we post the draft elsewhere, and submit the
> draft when submissions reopen on March 11.
>

---

From: Sarah Banks <[email-masked]>
Date: Mon, 25 Feb 2013 22:16:48 +0000

Hi David,
    Thanks for your feedback. I understand your point regarding network operators rolling images forward and backwards; however, I believe the scope of the document is clear; do you think this might address your concern?

ISSU is a technique implemented by forwarding devices to upgrade or downgrade from one software version to another as applicable. The end goal of the entire process is to minimize downtime and/or degradation of service. The ISSU operation may apply in terms of an atomic version change of the entire system software or it may be applied in a more modular sense such as for a patch or maintenance upgrade. The procedure described herein may be used to verify either approach, as may be supported by the vendor hardware and software.

Having said this, I think that if or when downgrades are covered, the methodology would be exactly the same. Would you agree?

Thanks
Sarah

On Feb 19, 2013, at 10:02 PM, David Newman <[email-masked]<mailto:[email-masked]>> wrote:

Abstract

dn

Regards,
Sarah (&Fernando &Gery)
_______________________________________________
bmwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________
bmwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bmwg

---

From: David Newman <[email-masked]>
Date: Tue, 26 Feb 2013 10:41:46 -0800

On 2/25/13 2:16 PM, Sarah Banks wrote:
> Hi David,
>     Thanks for your feedback. I understand your point regarding network
> operators rolling images forward and backwards; however, I believe the
> scope of the document is clear; do you think this might address your
> concern?
> 
> ISSU is a technique implemented by forwarding devices to upgrade or
> downgrade from one software version to another as applicable. The end
> goal of the entire process is to minimize downtime and/or degradation of
> service. The ISSU operation may apply in terms of an atomic version
> change of the entire system software or it may be applied in a more
> modular sense such as for a patch or maintenance upgrade. The procedure
> described herein may be used to verify either approach, as may be
> supported by the vendor hardware and software.

I'm less concerned with nailing down an exact definition at this point
than by the omission of ISSD, especially since we seem to agree that
it's a common practice to roll images both forward and backward.

Some vendors say "we only support ISSU" which IMO is not a good answer,
especially since there's already gear in production that supports both
ISSU and ISSD, and more in the pipeline, from multiple vendors. In this
light, a test that covers only half the picture isn't comprehensive.

> Having said this, I think that if or when downgrades are covered, the
> methodology would be exactly the same. Would you agree?

Yes.

dn

>>> At IETF... 82? we discussed the idea of having a draft that
>>> characterizes a device under software upgrade. At long last, and 2
>>> minutes late for cut off, we've worked out an initial draft. Since we
>>> missed the deadline, Al, our chair, suggested that we post the draft
>>> elsewhere, and submit the draft when submissions reopen on March 11.
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>