Clause
|
Compliance
|
Comply (Comply/Partial Comply)
|
2,1
|
Describe your operating system (OS) name and the release frequency of new version
|
Comply
|
2,2
|
Is your OS common to multiple platforms? Please elaborate.
|
Comply
|
2,3
|
Does you operating system supports batch/cron jobs and/or scripts running in background ?
|
Comply
|
2,4
|
Does your operating system offer a shell mode (to access Unix/Linux like commands, process management, directory arborescence browsing, etc.) ?
|
Comply
|
2,5
|
Is your operating system based on a linux/Unix kernel ? Which one ?
|
Comply
|
2,6
|
Does the software design include a sufficient process modularity to provide fault isolation for all software components (through protected memory space for example) ?
If so, please elaborate on this modularity and its impact on the globalavailability.
|
Comply
|
2,7
|
Do you implement process placement and/or process split into different cards or routing engine? Please elaborate in details, especially for a multi-shelf configuration.
|
Comply
|
2,8
|
Is it possible to restart only a process without impacting others? If so, please elaborate.
|
Comply
|
2,1
|
Is it possible to safety power down by CLI any hardware part (linecard, Routing processor, Fantray...) into a chassis ?
|
Comply
|
2,11
|
Do you support ISSU between two minor releases in the same major release? Please elaborate on any restrictions about minimum release number, card restart or enabled services. Please give the average service impact in duration.
|
Comply
|
2,12
|
Do you support ISSU between two major releases? Please elaborate on any restrictions about minimum release number, maximum major release gap, card restart or enabled services. Please give the average service impact in duration.
|
Comply
|
2,13
|
Is your ISSU capability based on non stop routing feature (when no routing session or FIB information or layer 2 adjacency status is lost)?
|
Comply
|
2,14
|
Vendor should list all protocol and hardware capabilty for ISSU support?
|
Comply
|
2,16
|
What are the update modes for ISSU? Please elaborate on file transfer method
|
Comply
|
2,17
|
Are any check regarding fimware integrity and/or confidentiality implemented? Describe the method used
|
Comply
|
2,18
|
Does your implementation of ISSU requires some restart of Linecards or forwarding engine ? Elaborate on how long traffic is disrupted when forwarding plane is upgraded.
|
Comply
|
2,2
|
Does the equipment support a multiple stage configuration mechanism? If so, what are the commands available for each stage?
|
Comply
|
2,21
|
Does the equipment provide a configuration commit capability? Please elaborate.
|
Comply
|
2,22
|
Does the equipment provide a configuration rollback capability? Please elaborate.
|
Comply
|
2,23
|
Does the equipment provide a configuration semantic check? Please elaborate.
|
Comply
|
2,24
|
Does the equipment provide a command completion inline? Please elaborate.
|
Comply
|
2,26
|
Does the equipement provide an automatic configuration archival function locally (each time configuration is changed, old one is stored) ? How many configurations could be stored?
|
Comply
|
2,27
|
Does the equipment provide a configuration comparison function ? (comparing between current and old one, and between two olds).
|
Comply
|
2,28
|
Does the equipment support configuration templates (specifically MTU interface configuration)?
|
Comply
|
2,29
|
Does the equipement support multi administrators configuration at the same time and a way to commit only one's changes ?
|
Comply
|
2,3
|
Does the equipement support a way to prevent multi edition of the configuration by two administrators at the same time ?
|
Comply
|
2,31
|
Does the equipment support a "replace pattern" configuration feature ?
|
Comply
|
2,32
|
Does the equipement provide a way to apply a configuration change at a specified time (i.e. not right after the commit) ?
|
Comply
|
2,33
|
Does the equipment provide a way to save a configuration without applying it right away (to edit the configuration change afterwards) ?
|
Comply
|
2,34
|
Is there any mechanism to backup restore a configuration? Indicate how it is protected and which underlying protocols can be used.
|
Comply
|
2,35
|
Is it possible to run CLI commands into edition mode ?
|
Comply
|
2,36
|
Does the CLI have options filter outputs (match, begin, find, count...) ?
If so, list the outputs
|
Comply
|
2,37
|
Is it possible to push a configuration file in edit mode?
|
Comply
|
2,4
|
Ability to back out of a software installation for the network element: The platform shall have the ability to back out of an installation of a new software version and resume operation under the previous software version that has been reset to the previous operational configuration. This ability shall be provided prior to full operation under the new version and shall reset the new software to the previous operational configuration.
|
Comply
|
2,41
|
Status Messages: The platform software shall provide incremental status messages to the user as stages of the upgrade are completed.
|
Comply
|
2,42
|
Backward compatibility of software releases for the network element: All network element software releases shall be backward compatible to ALL previous release.
|
Comply
|
2,43
|
Ability to detect software version number for the network element: The software version number of the platform shall be retrievable from all user interfaces. This requirement includes the ability to distinguish between different software “point” releases delivered during testing.
|
Comply
|
2,44
|
Warning of improperly configured software for the network element: The software update procedure shall verify that the network element is in the proper configuration to apply the update. The software shall provide the user with ample warnings for an improperly configured system, and the user must be required to override the warnings manually.
|
Comply
|
2,45
|
Network element software reset: The network element shall have the capability to have its system level and shelf level control software individually reset through a software-reset command available at the craft interface terminal command line interface and at the EMS.
|
Comply
|
2,46
|
Duration of network element software reset: All network element software resets of system level and shelf level control software shall be completed within five (5) minutes, regardless of whether the command was issued at the craft interface terminal command line interface or at the EMS. Network element software reset shall be considered completed when the network element is completely visible again to the OSS.
|
Comply
|
2,47
|
Remote network element software reset: The network element shall have the capability to have its system level and shelf level control software individually reset remotely (such as through remote access to a contact closure) in the event that the software becomes unresponsive to command requests. A software-reset command available from the EMS is not sufficient to satisfy compliance with this requirement.
|
Comply
|
2,48
|
Local network element software reset: The network element shall have the capability to have its system level and shelf level control software individually reset locally in the event that the software becomes unresponsive to command requests. This capability shall not require the extraction and reinsertion of Line Cards. This capability shall require at least two steps (such as reset enable followed by a reset initiation). A software-reset command from the craft interface terminal command line interface is not sufficient to satisfy compliance with this requirement.
|
Comply
|
2,5
|
No service-affecting network element software resets: All network element software resets shall have no affect on service traffic or network element management and control functions. All customer service and configuration data shall not be affected by software resets.
|
Comply
|
2,51
|
Modular software: The software shall be modular in design to the extent that any module/component of the running software image can be installed, upgraded, troubleshoot without affecting other modules/components of the running software image.
NOTE: this requirement applies to the implementation of Bug fixes and patch release upgrades that can be implemented without impacting the entire code.
|
Comply
|
2,53
|
Modular Software restart: Restarting of a software module shall not affect other modules
|
Comply
|
2,56
|
Support timed load: The core router/switch shall have the capability to be programmed to reload/restart itself at a set future time and date.
|
Comply
|
2,61
|
Quality: What quality techniques were used in development of the software? For example were fault trees or walkthroughs used? Please supply documentation of techniques used.
|
Comply
|
2,64
|
Installed Base: Is this software currently in use? Where and how long? Provide contact names.
|
Comply
|
2,65
|
How many installations are still in service?
|
Comply
|
2,66
|
Other Software: Has the vendor previously produced similar software? Where and when was it installed? What are the similarities and differences?
|
Comply
|
2,68
|
Release Testing: Can new releases, patches and upgrades be installed without affecting service? Has this been tested? Describe the testing procedure.
|
Comply
|
2,72
|
Documentation: The vendor must supply software documentation. How is complete documentation ensured?
|
Comply
|
2,73
|
Software Patches: How many patches have been made to each previous release and over what time period?
|
Comply
|
2,74
|
Release Cycle: What is the major release cycle – how often is there a new release?
|
Comply
|
2,91
|
How do the software subsystems communicate with each other? Please provide a detailed description of inter-process communications architecture.
|
Comply
|
2,92
|
Please describe how contention for shared resources is arbitrated between different software subsystems and between different instances of the same software system.
|
Comply
|
2,93
|
Please describe how the consistency of replicated information is maintained within the device.
|
Comply
|
2,94
|
Does the software provide an open API to allow third party development of value added applications? If so, please explain.
|
Comply
|
2,96
|
How frequently are minor software releases scheduled?
|
Comply
|
2,98
|
Does the platform support a SDK (Software Development Kit) to develop "integrated" applications that leverage the control/forwarding plane of the device?
|
Comply
|
