Clause
|
Compliance
|
Comply (Comply/Partial Comply)
|
7,01
|
Does the equipment support community based SNMP v1? If so, please detail if one access-list can be attached to one community and if “views” supports inclusions and exclusions. Please give the maximum number of communities and hosts that can be supported.
|
Comply
|
7,02
|
Does the equipment support community based SNMP v2c? If so, please detail if one access-list can be attached to one community and if “views” supports inclusions and exclusions. Please give the maximum number of communities and hosts that can be supported.
|
Comply
|
7,03
|
Are the 64-bit traffic counters supported for all interfaces?
|
Comply
|
7,04
|
Is GET-BULK supported?
|
Comply
|
7,05
|
Does the equipment support USM-based SNMP v3? Please detail if “views” supports inclusions and exclusions. Please give the maximum number of users/groups that can be supported and detail if one access list can be attached to one user.
|
Comply
|
7,06
|
What are the supported combinations of Auth / Priv? Please describe the usable systems for key management.
|
Comply
|
7,07
|
Is SNMP SET supported? Please elaborate on the possible restrictions to some MIBs or OIDs.
|
Comply
|
7,08
|
Are the incoming SNMP packets serialized or parallelized? Please describe your queuing mechanism.
|
Comply
|
7,09
|
For all versions of SNMP, how are defined the IP source address and the UDP source port of the response packet? If it is not the direct mapping of the destination IP address and destination UDP port of the SNMP query packet, as it is expected to be, can it be configured? Please elaborate.
|
Comply
|
7,10
|
Same question as above for a virtual router, respectively a logical router (if different and if applicable)? Please elaborate.
|
Comply
|
7,11
|
Is the transport of SNMP packets over IPv6 supported?
|
Comply
|
7,12
|
If the equipment supports “null” interfaces (packet sinks), are those interfaces present in IF-MIB or in a dedicated MIB? Please describe how many “null” interfaces could have counters attached.
|
Comply
|
7,13
|
If supported, do logical routers, respectively virtual routers, have a distinct “view” showing their respective resources?
|
Comply
|
7,14
|
Is indexes persistency supported? If so, please detail which indexes.
|
Comply
|
7,15
|
Does the equipment support an SNMP-based SLA probe? If so, please elaborate on the supported probes (attention will be given to RTT and Jitters, with and without VRFs, and to IPv6).
|
Comply
|
7,16
|
Regarding interface accounting and routing, does the equipment support dedicated IPv4 and IPv6 OIDs? If so, is it in through new generation IP-MIB/IP-FORWARD-MIB/BGPv2-MIB/etc or is IPv6 handled in dedicated MIBs? In any case, please elaborate.
|
Comply
|
7,17
|
Does your equipment support the following IETF MIBs?
ATM-MIB, BGP4-MIB, BGP4-V2-MIB, BRIDGE-MIB, DISMAN-PING-MIB, ENTITY-MIB, IF-MIB, IP-FORWARD-MIB, IGMP-MIB, IP-MIB, IPMROUTE-MIB, IPV6-MIB, MPLS-LSR-MIB, MPLS-VPN-MIB, MSDP-MIB, OSPF-MIB, OSPFV3-MIB, PIM-MIB, PWE3 MIBs, SNMPv2-MIB, SONET-MIB and VRRP-MIB.
Please list all other IETF MIBs that your equipment supports, their version (which RFC or draft) and their level of implementation (complete or not, with details).
You are encouraged to provide with your answers your MIB files (in a format that can be compiled) and a dump of a “walk” of the complete MIB tree (long routing tables could be shortened for practical reasons).
|
Comply
|
7,18
|
Does your equipment support enterprise specific MIBs or non-IETF MIBs?
Special attention will be given to MIBs related to configuration management, environmental monitoring, hardware (inventory from the rack down to the optics, fans, power modules, including CPUs, memory, disks and/or flashes), accounting and routing not covered by IETF MIBs, firewall/ACL and src/dst class accounting.
You are encouraged to provide with your answers your MIB files (in a format that can be compiled) and a dump of a “walk” of the complete MIB tree (long routing tables could be shortened for practical reasons).
|
Comply
|
7,19
|
Does the equipment support notification through SNMP traps? If so, please specify the version(s) supported (and the corresponding parameters), and the number of destinations configurable.
|
Comply
|
7,20
|
Are the source IP address and source UDP port of the SNMP traps configurable? Please detail how they are configured and their default values.
|
Partial Comply
|
7,21
|
Do you support the traps defined in IETF RFCs or drafts that are supported by the equipment. Please detail the ones supported.
Special attention will be given to routing protocols events, system events, interface events so please be exhaustive.
|
Comply
|
7,22
|
Does your equipment support notifications for both beginning and end of events?
|
Comply
|
7,23
|
Does the equipment provide a XML programmable API? Please elaborate and please list the different XML schemas available.
|
Comply
|
7,24
|
Is this API conformant with NETCONF? Please elaborate on the level of conformance and on the capabilities supported.
|
Comply
|
7,25
|
Are configuration operations possible through this API? Please elaborate.
|
Comply
|
7,26
|
Are operational information (interfaces and adjacencies states, counters, environmental data...) available through this API? Please elaborate.
|
Comply
|
7,27
|
Are transport protocols available to use this API? Please list them and include the protection mechanisms (such as ACLs protecting the service, encryption of the sessions, etc).
|
Comply
|
7,28
|
Do you provide a toolkit to use this API? If so, what are the supported languages?
|
Comply
|
7,30
|
Does the equipment provide a way to run scripts within the box? Please elaborate.
|
Comply
|
7,31
|
For each access mode (Telnet, SSH, HTTP / SHTTP, SSL, IPSec, Accounting), please describe the authentication and authorization procedures whenever granted access to the equipment is required.
|
Comply
|
7,32
|
Is it possible to have different authentication and authorization processes for each different possible mode? If so, please elaborate.
Is it limited to dedicate interface (Console, Aux, port).
|
Comply
|
7,34
|
Is it possible to define an access password and limit the timeout of the idle sessions to the line access?
|
Comply
|
7,35
|
What are the protocols that can be used for AAA purposes? For each of these options, please elaborate on the AAA procedure itself (in particular Radius and TACACS+).
|
Comply
|
7,36
|
Is it possible to configure multiple AAA servers for each supported protocol? Please elaborate on the maximum number of servers and describe limitations such as maximum authentication key length and authentication algorithms implemented. In particular, does the authentication traffic transit in clear text or is it encrypted?
|
Comply
|
7,37
|
Is the traffic between the equipment and the AAA servers encrypted? If yes, please describe algorithm.
|
Comply
|
7,38
|
Do you implement a backup process in case of impossibility of joining AAA servers?
|
Comply
|
7,39
|
Can administrative command be logged? If so, please describe the different possibility.
|
Comply
|
7,40
|
Do you provide multiple authorization levels? Please, elaborate on the authorization management feature, in particular on the following points:
- describe the different authorization levels
- describe the different possibilities to define user groups
- describe the way a user can be restrict to a subset of commands
- Is it possible to log each configuration changes?
|
Comply
|
7,41
|
Do you implement default accounts? Please elaborate on the following items:
- How and where are the local passwords stored?
- If passwords are encrypted, which encryption / hashing modes are available?
- How can a local password be changed?
- How many local accounts can be configured in the equipment?
|
Comply
|
7,42
|
Is it possible to deny unwanted services like IP source-route, finger, etc?
What are the other security features available? Please describe.
|
Comply
|
7,43
|
System must support standard SNMP traps for all faults in the system.
|
Comply
|
7,44
|
System must support a separate trap for every system affecting or performance affecting event or error.
|
Comply
|
7,45
|
System must support the ability to enable/disable a trap for each fault type.
|
Comply
|
7,46
|
System must support ability to configure thresholds for traps, where
applicable.
|
Comply
|
7,47
|
System must support ability to configure send traps to a minimum of 8 systems (IP addresses).
|
Comply
|
7,48
|
System should support ability to control/specify destination(s) of each trap.
|
Comply
|
7,49
|
Vendor shall provide a comprehensive lists of all traps supported by the system and recommendation on the alarm severity for each trap.
|
Comply
|
7,50
|
The device shall support SNMPv3 and RMON Ethernet PM on all Ethernet interfaces.
|
Comply
|
7,51
|
System must support IETF RY 2863, The Interfaces Group MIB.
|
Comply
|
7,65
|
System must support IETF RY 3289, MIB for Differentiated Services Architecture.
|
Comply
|
7,66
|
Provide the complete list of MIBs, both standard and enterprise, supported by the platform.
|
Comply
|
7,67
|
System must support statistics for non-conforming (yellow) frames dropped at each queuing point in the system on a per-port, per-queue} basis.
|
Comply
|
7,68
|
System must support statistics for conforming (green) frames dropped at each queuing point in the system on a per-port, per-queue basis.
|
Comply
|
7,69
|
System should support statistics for non-conforming (yellow) frames dropped at each queuing point in the system on a per-port, per-queue, per-VLAN basis.
|
Comply
|
7,70
|
System should support statistics for conforming (green) frames dropped at each queuing point in the system on a per-port, per-queue, per-VLAN basis.
|
Comply
|
7,71
|
System should support on-demand monitoring of queues on a per-port, per-queue, per-VLAN basis.
|
Comply
|
7,72
|
System must support statistics for utilization at each queuing point in the system on a per-port, per-queue} basis.
|
Comply
|
7,73
|
System must supports statistics for dropped (red) frames at the ingress policer on a per-port, per-queue, per-VLAN, per-class-of-service} basis.
|
Comply
|
7,74
|
System must support a minimum of 64-bit counters for Ethernet statistics.
|
Comply
|
7,75
|
Count of Originating/terminating LSP
|
Comply
|
7,76
|
Count of Transit LSP's
|
Comply
|
7,77
|
Bandwidth reservation (RSVP) per LSP
|
Comply
|
7,78
|
Bandwdith reservation per port
|
Comply
|
7,79
|
Bandwidth utilization per port
|
Comply
|
7,80
|
Utilization per port by CoS
|
Comply
|
7,81
|
Dropped packets per queue
|
Comply
|
7,82
|
Auto bandwidth changes as they happen
|
Comply
|
7,83
|
The device shall have full fault detection and isolation architecture.
|
Comply
|
7,84
|
The fault detection shall include hardware and software error malfunctions.
|
Comply
|
7,85
|
Each fault detected shall generate an Alarm/event.
|
Comply
|
7,86
|
The device will support selection of traps to generate.
|
Comply
|
7,87
|
Alarm severity shall have a default and will be user configurable.
|
Comply
|
7,88
|
Alarms will indicate: alarm severity and alarm type, date and time, probable cause, device.
|
Comply
|
7,89
|
Alarms will detail problems down to the device, hardware unit, card, port, physical and logical connection.
|
Comply
|
7,91
|
Alarms shall be categorized in 3 different levels:
|
|
7,92
|
Catastrophic/Critical: Priority 1.
|
Comply
|
7,93
|
Major: Priority 2
|
Comply
|
7,94
|
Minor: Priority 3
|
Comply
|
7,95
|
Information/Event: priority 3
|
Comply
|
7,96
|
The fault management function shall identify the fault as hardware or software specific.
|
Comply
|
7,97
|
Alarms and Problem Reports shall be sent to the following systems:
|
|
7,98
|
· Local Craft Interface
|
Comply
|
7,99
|
· Problem Log
|
Comply
|
7,100
|
· Alarm Log (disk)
|
Comply
|
7,101
|
· Shelf Alarm Panel (visual and audible)
|
|
7,102
|
· Up to 8 destination remote peripheral device, such as a device OSS or Network Management System
|
Comply
|
7,103
|
The device shall supply a Heartbeat to the Network Management system. Provide details.
|
Comply
|
7,104
|
The device will support 8 destination IP address for reporting to remote Management platforms. Destination addresses can be set via the craft, telnet and Management system.
|
Comply
|
7,105
|
Ethernet (Loss of Signal, Loss of Link and CRC/Frame errors received at the Ethernet interfaces) – see below for more information
|
Comply
|
7,106
|
Software failures
|
Comply
|
7,107
|
Security violations
|
Comply
|
7,108
|
Loss of Signal (LOS - on electrical interfaces-)
|
Comply
|
7,109
|
The information should be attainable from the Ethernet MIB/RMON MIB. If a standard is developed in the future to deal with these issues, it should be followed.
|
Comply
|
7,110
|
The device shall support collection of performance data, based on two methods: periodic snapshots and persistent memory. In each case, the vendor shall provide for accumulation of data in real time in files. Either OSS SFTP will be used for file transfer of stored data.
|
Comply
|
7,111
|
System must support data collection interval for real-time performance management must be 5 minutes or less.
|
Comply
|
7,112
|
System performance data must be collected via out-of-band interface and in-band management interface.
|
Comply
|
7,113
|
System 5-minute performance data must be collected via SNMP GET to read the value of an SNMP object specified by the OID.
|
Comply
|
7,114
|
System must support simultaneous polling by a minimum of four systems every five minutes.
|
Comply
|
7,115
|
System must support Threshold Crossing Alerts (TCAs) with user provisionable thresholds for each PM parameter (with exception of status parameters).
|
Comply
|
7,116
|
System must support the ability to enable/disable reporting of TCA on a per-parameter and per client port basis.
|
Comply
|
7,117
|
System must support access of all performance monitoring data by the EMS, NMS and/or OSS.
|
Comply
|
7,118
|
System must continue to collect statistics when counters are reset via the CLI or NMS.
|
Comply
|
7,119
|
The device shall provide Performance Monitoring (PM) data collection at different hierarchical levels
|
Comply
|
7,120
|
What size counters are supported for each interface type?
|
Comply
|
7,121
|
Can the counters be reset per port and/or EVC?
|
Comply
|
7,122
|
Performance monitoring data is used for troubleshooting and for reporting performance statistics to customers. The data must be reported accurately and be stored in the device long enough to be collected.
|
Comply
|
7,123
|
Octets Received
|
Comply
|
7,124
|
Octets Transmitted
|
Comply
|
7,125
|
Frames Received without Errors
|
Comply
|
7,126
|
Frames Transmitted without Errors
|
Comply
|
7,127
|
Jumbo Frames Received
|
Comply
|
7,128
|
Jumbo Frames Transmitted
|
Comply
|
7,129
|
Pause Frames Received
|
Comply
|
7,130
|
Pause Frames Transmitted
|
Comply
|
7,131
|
Time Valid Carrier Present on LAN Interface
|
Comply
|
7,132
|
Time Valid Carrier not Present on LAN Interface
|
Comply
|
7,133
|
The following cumulative Ethernet LAN (client interface) PM error parameters shall be supported.
|
|
7,134
|
Frames Received with Errors (types of errors are broken out below)
|
Comply
|
7,135
|
Frames Received and Discarded with Errors
|
Comply
|
7,136
|
Frames not Transmitted due to Errors
|
Comply
|
7,137
|
Frames Transmitted with Errors
|
Comply
|
7,138
|
Frames Received and Discarded due to Congestion (buffer overflow)
|
Comply
|
7,139
|
Frames Received with YS Errors
|
Comply
|
7,140
|
Frames Received with Alignment Errors
|
Comply
|
7,141
|
Frames Received not Transmitted due to MAC Errors
|
Comply
|
7,142
|
Oversized Frames Received (over provisionable MTU)
|
Comply
|
7,143
|
Runts Received (< 64 bytes with CRC errors)
|
Comply
|
7,144
|
Jabbers Received (>1548 bytes with CRC errors)
|
Comply
|
7,145
|
Total Frames
|
Comply
|
7,146
|
Broadcast Frames
|
Comply
|
7,147
|
Multicast Frames
|
Comply
|
7,148
|
Undersize Frames
|
Comply
|
7,149
|
Oversize Frames
|
Comply
|
7,150
|
Fragmented Frames
|
Comply
|
7,151
|
Jabbers
|
Comply
|
7,152
|
Number of Frames less than 64 Octets
|
Comply
|
7,153
|
Number of frames 65-127 Octets
|
Comply
|
7,154
|
Number of frames 128-255 Octets
|
Comply
|
7,155
|
Number of frames 256-511 Octets
|
Comply
|
7,156
|
Number of frames 512-1023 Octets
|
Comply
|
7,157
|
Number of frames 1024-1518 Octets
|
Comply
|
7,158
|
Number of frames 1518-2048 Octets
|
Comply
|
7,159
|
Number of frames 2048-4096 Octets
|
Comply
|
7,160
|
Number of frames 4096-8000 Octets
|
Comply
|
7,161
|
Number of frames 8000-9600 Octets
|
Comply
|
7,162
|
The following alarm conditions shall be reported and be able to be retrieved:
|
Comply
|
7,163
|
Raising Alarm
|
Comply
|
7,164
|
Falling Alarm
|
Comply
|
7,165
|
Raising threshold
|
Comply
|
7,166
|
Falling threshold
|
Comply
|
7,167
|
When a request to retrieve alarms is received all current alarm and threshold crossing events shall be reported.
|
Comply
|
7,168
|
Performance statistics shall be able to be cleared and reset on a per port and/or EVC basis.
|
Comply
|
7,169
|
The device shall provide Threshold Crossing Alerts (TCAs) with user provisionable thresholds for each PM parameter (for the error PM parameters only – not for the status parameters).
|
Comply
|
7,170
|
All performance monitoring data shall be accessible by the EMS/NMS or OSS.
|
Comply
|
7,171
|
The device must implement Simple Network Management Protocol version 1 as defined in RfC1157.
|
Comply
|
7,172
|
The device must implement Simple Network Management Protocol version 2c as defined in RfC1901.
|
Comply
|
7,173
|
The device must implement Simple Network Management Protocol version 3 as defined in RfC 3410 - 3418.
|
Comply
|
7,174
|
The device must implement Simple Network Management Protocol version 1 trap generation to the trap receiver.
|
Comply
|
7,175
|
The device must implement Simple Network Management Protocol version 2c trap generation to the trap receiver.
|
Comply
|
7,176
|
The device must implement Simple Network Management Protocol version 3 trap generation to the trap receiver.
|
Comply
|
7,177
|
The device provide a facility for limiting SNMP access to a list of hosts or source IP addresses.
|
Comply
|
7,178
|
The vendor must state how servicing SNMP requests impacts the performance of the router's control plane or forwarding plane.
|
Comply
|
7,179
|
The vendor must state the maximum rate at which SNMP requests can be handled.
|
Comply
|
7,180
|
The device must implement SMI version 2 as defined in RfC2578.
|
Comply
|
7,181
|
The vendor must state all underlying SNMP transport protocols (L3) implemented by the device.
|
Comply
|
7,182
|
The device must implement SNMP views to restrict SNMP access based on the SNMP community values.
|
Comply
|
7,183
|
The device must implement Simple Network Management Protocol (SNMP) MIB II according to RfC 1213.
|
Comply
|
7,184
|
The device must implement the Remote Monitoring (RMON) MIB according to RfC 2819.
|
Comply
|
7,185
|
The device must implement "Management Information Base for the Internet Protocol (IP)" according to RfC 4293
|
Comply
|
7,186
|
The device must implement the TCP MIB according to RfC 4022.
|
Comply
|
7,187
|
The vendor must details any 'optional' or 'should' requirements defined in RFC1157 (Simple Network Management Protocol version 1) that their proposed device does not implement
|
Comply
|
7,188
|
The vendor must details any 'optional' or 'should' requirements defined in RFC1901 (Simple Network Management Protocol version 2c) that their proposed device does not implement
|
Comply
|
7,189
|
The vendor must details any 'optional' or 'should' requirements defined in RFC 3410 (Simple Network Management Protocol version 3) that their proposed device does not implement
|
Comply
|
7,190
|
The vendor must details any 'optional' or 'should' requirements defined in RFC 2578 (SMI version 2) that their proposed device does not implement
|
Comply
|
7,191
|
The vendor must details any 'optional' or 'should' requirements defined in RFC1213 (Simple Network Management Protocol (SNMP) MIB II) that their proposed device does not implement
|
Comply
|
7,192
|
The vendor must details any 'optional' or 'should' requirements defined in RFC 2819 (Remote Monitoring (RMON) MIB) that their proposed device does not implement
|
Comply
|
7,193
|
The vendor must details any 'optional' or 'should' requirements defined in RFC 4293 (Management Information Base for the Internet Protocol (IP)) that their proposed device does not implement
|
Comply
|
7,194
|
The vendor must details any 'optional' or 'should' requirements defined in RFC 4022 (TCP MIB) that their proposed device does not implement
|
Comply
|
7,195
|
The device must implement configuration of source interface (IP address) for snmp protocols
|
Comply
|
7,196
|
The device must implement time synchronization via Network Time Protocol version 3 according to RfC 1305 as an NTP server.
|
Comply
|
7,197
|
The device must implement time synchronization via Network Time Protocol version 3 according to RfC 1305 as an NTP client.
|
Comply
|
7,198
|
The device must implement the authentication of NTPv3 messages (e.g. with MD5 hashing).
|
Comply
|
7,199
|
The vendor must details any optional requirements defined in RFC 1305 (Network Time Protocol version 3) that their proposed device does not implement
|
Comply
|
7,200
|
The device must implement configuration of source interface (IP address) for NTP.
|
Comply
|
