Re: comments on draft-banks-bmwg-issu-meth-01
Sarah Banks <[email protected]>
| Newsgroups | gmane.ietf.bmwg |
|---|---|
| Message-ID | <[email protected]> |
Hi Erum,
Thanks for the feedback! Please let me comment inline.
Missing the 5.1 in table of Content.
5. ISSU Test Methodology............................................10
5.1 Pre-ISSU recommended verifications ………………………………………………
1. Introduction
<efrahim> Can we define the patching and maintenance upgrade little bit more.
ISSU operation can be categorized into multiple scenario
- Whole Atomic version change: In this scenario, the whole system including all the process are upgraded as well in certain cases the firmware and bios can be upgraded.
- Patching: This usually refer to the one or two process upgrade. Patching usually helpful to fix a bug on the current version.
- Maintenance: If there are multiple fixes are coming for many modules.
We don't expand here, because we are not focusing on the patching or maintenance upgrades; that is, we don't distinguish between a major, or minor, or maintenance release; we take the approach that ISSU loads new code. We wanted to focus on how to measure that loading; not WHAT we were loading, as the notion of what major, minor, maintenance and patching, and downgrades for that matter, seems to be polarizing. Having said this, though, there's nothing in the methodology that stops it from being applied in that manner.
<efrahim> Some Datacenter layer 3 switches are referred their Routing Processor as Supervisors (SUP). It would be nice to add both reference.
We'll take this under consideration.
Different hardware configurations may be expected to be benchmarked,
but a typical configuration for a forwarding device that supports
ISSU consists of at least one pair of Routing Processors (RP's) or Supervisors
(SUP)
<efrahim>
Since most modern forwarding devices, where ISSU would be applicable,
do consist of redundant RP's or Sups and hardware-separated control plane
and data plane functionality, this document will focus on
methodologies which would be directly applicable to those platforms.
<efrahim> Do we really want to restrict the ISSU to only redundant supervisors or RP. A lot of the new DC switches can easily do patching and ISSU without the redundant supervisor or RP. It would be good to include both ISSU testing methodology. The procedure if there is single SUP.
Others on the list, what do you think? We picked a spot to start; that was with redundant RPs, because it's what the authors are familiar with and the customers we speak with are familiar with. If there's large consensus to bring this into the fold, we'll certainly consider it. I'd like to hear what others think - but it's a great point.
3.3 Upgrade Run
<efrahim> May be change to include and clear the process better. Here is the suggestion
In this phase, the secondary RP load the new software first. Once the software is loaded on the secondary RP and comes to HA State, the secondary RP/SUP takes over, forcing the RP/SUP which was
previously designated as primary, to adopt the standby role. At this
point, the new primary RP drives the required updates to other
specific components and forces warm-updates or re-initializations
with the new software, as applicable. In addition, the now-standby
RP will be updated with the desired software.
Depend of vendor implementation, after upgrading and downgrading the SUP/RP, the line cards (LC) and other modules gets upgraded either serially or in parallel.
We (authors) will discuss. I personally dislike part of this, as it assumes a behaviour that might not matter at the end; that the primary RP runs the ISSU or that the secondary does isn't what concerns me (personally), speaking for myself. But I understand your point, and we'll discuss.
5.3 Upgrade Run
<efrahim> There is no reference for any T3 Time where on the section 7 Final Report, there is a mention of T3 time. It would be nice to have some reference of T Time.
<efrahim> There was no mention of LC upgrades after the Supervisor. Upgrade processes do include both Supervisor and Lcs. May be log that as T4.
At this point, pay particular attention to any indications of
control plane disruption, traffic impact or other anomalous
behavior. Once the DUT has converged upon the new code and returned
to normal operation note the completion time and log the duration of
this step as T2.
Once both RP/SUPs are up on new code and synchronized, upgrade the LC and other modules. Log this duration of this time as T4.
OK, we'll discuss.
7 Final Report
Add the T4 time for LC and other modules upgrade.
ISSU for all the LCs and other components T4
Total ISSU Maintenance Window T5 (sum of T1+T2+T3+T4)
Regards
Erum
Got it. Thanks!
Sarah
_______________________________________________
bmwg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bmwg
_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg