comments on draft-banks-bmwg-issu-meth-01

Hi Team,

Here is some of the feedback and suggestions:



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.



<efrahim> Some Datacenter layer 3 switches are referred their Routing Processor as Supervisors (SUP). It would be nice to add both reference.


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.


 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.


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.


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

_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg