Network Working Group Internet Draft Nitin Kakkar Document: draft-kakkar-ospf-ospfv3-trap-mib- Huawei 00.txt Technologies Bangalore Expires: May 2006 November 2005 OSPF Version 3 Trap MIB Status of this Memo This document is a submission by the author to IETF Network Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the nitink@huawei.com. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines Traps for managing version 3 of the Open Shortest Path First Routing Protocol. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo is intended to complement draft-ietf-ospf-ospfv3-mib-09.txt and uses many definitions provided in this MIB. - 1 - Expires - May 2006 [Page 1] Internet Draft OSPF Version 3 Trap MIB November 2005 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. Table of Contents 1. OSPFv3 Traps Overview..........................................2 1.1 Introduction...............................................2 1.2 Approach...................................................2 1.3 Ignoring Initial Activity..................................3 1.4 Throttling Traps...........................................3 1.5 One Trap Per OSPFv3 Event..................................3 1.6 Polling Event Counters.....................................4 2. Trap MIB definition............................................4 3. Formal Syntax.................................................14 Security Considerations..........................................14 References.......................................................14 Acknowledgments..................................................15 Author's Addresses...............................................16 1. OSPFv3 Traps Overview 1.1 Introduction As network topologies become large and complex it is getting more complicated and time consuming to identify the causes and sources of misbehaving devices, by polling alone. A more systematic approach is for devices themselves to notify the network managers of potentially critical conditions using SNMP traps. This draft defines a set of traps, objects and mechanisms to enhance the ability to manage IP internetworks which use OSPFv3 as its IGP. It is an optional but very useful extension to the OSPFv3 MIB. 1.2 Approach Whenever an unexpected event occurs, the application notifies the local snmp agent, which generates corresponding SNMP trap message and send it to the appropriate SNMP management stations. The message includes the trap type and may include a list of trap specific variables. Section 2 provides the trap definitions for OSPFv3 which includes the variable lists. The router ID of the originator of the trap is Expires - May 2006 [Page 2] Internet Draft OSPF Version 3 Trap MIB November 2005 included in the variable list so that the network manager can easily determine the originator of the trap. At times error conditions persist for long duration, To limit the frequency of OSPFv3 traps, the following additional mechanisms are suggested. 1.3 Ignoring Initial Activity Most of the transitional events occur when OSPFv3 is enabled on the router, During this time the designated router is elected and neighbor adjacencies are formed. All these events are normal and expected, but most of them can potentially generate unnecessary SNMP traps, Which should be avoided. To avoid these unnecessary traps, a router should not originate expected OSPFv3 interface related traps until two of that interface's dead timer intervals have elapsed. The expected OSPFv3 interface traps are ospfv3IfStateChange, ospfv3VirtIfStateChange, ospfv3NbrStateChange, ospfv3VirtNbrStateChange, ospfv3TxRetranmit and ospfv3VirtIfTxRetransmit. Additionally, ospfv3MaxAgeLsa and ospfv3OriginateLsa traps should not be originated until two dead timer intervals have elapsed where the dead timer interval used should be the dead timer with the smallest value. 1.4 Throttling Traps The mechanism for throttling the traps is similar to the mechanism explained in RFC 1224 [5]. The basic premise of the throttling mechanism is that of a sliding window, defined in seconds and an upper bound on the number of traps that may be generated within this window. Note that unlike RFC 1224, traps are not sent to inform the network manager that the throttling mechanism has kicked in. A single window should be used to throttle all OSPF traps types except for the ospfv3LsdbOverflow and the ospfv3LsdbApproachingOverflow trap which should not be throttled. For example, with a window time of 3, an upper bound of 3, and events to cause trap types 1,3,5 and 7 (4 traps within a 3 second period), the type 7 (the 4th) trap should not be generated. Appropriate values are 7 traps with a window time of 10 seconds. 1.5 One Trap Per OSPFv3 Event Several of the traps defined in section 2 are generated as the result of finding an unusual conditions while parsing an OSPFv3 packet or a Expires - May 2006 [Page 3] Internet Draft OSPF Version 3 Trap MIB November 2005 processing a timer event. There may be more than one unusual condition detected while handling the event. For example, a link- state update packet may contain several retransmitted link-state advertisements (LSAs), or a retransmitted database description packet may contain several database description entries. To limit the number of traps and variables, OSPFv3 should generate at most one trap per OSPF event. Only the variables associated with the first unusual condition should be included with the trap. Similarly, if more than one type of unusual condition is encountered while parsing the packet, only the first event should generate a trap. 1.6 Polling Event Counters Many of the tables in the OSPFv3 MIB contain generalized event counters. By enabling the traps defined in this document a network manager can obtain more specific information about these events. A network manager may want to poll these event counters and enable specific OSPFv3 traps when a particular counter starts increasing abnormally. The following table shows the relationship between the event counters defined in the OSPF MIB and the trap types defined in section 2. Counter32 Trap Type ----------------------- ------------------------ ospfv3OriginateNewLsas ospfv3OriginateLsa ospfv3IfEvents ospfv3IfStateChange ospfv3ConfigError ospfv3IfAuthFailure ospfv3RxBadPacket ospfv3TxRetransmit ospfv3VirtIfEvents ospfv3VirtIfStateChange ospfv3VirtIfConfigError ospfv3VirtIfAuthFailure ospfv3VirtIfRxBadPacket ospfv3VirtIfTxRetransmit ospfv3NbrEvents ospfv3NbrStateChange ospfv3VirtNbrEvents ospfv3VirtNbrStateChange ospfv3ExternLSACount ospfv3LsdbApproachingOverflow ospfv3ExternLSACount ospfv3LsdbOverflow 2. Trap MIB definition OSPFv3 Trap Definitions OSPFv3-TRAP-MIB DEFINITIONS ::= BEGIN IMPORTS Expires - May 2006 [Page 4] Internet Draft OSPF Version 3 Trap MIB November 2005 MODULE-IDENTITY,OBJECT-TYPE,NOTIFICATION-TYPE,IpAddress FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB ospfv3RouterId, ospfv3IfIndex, ospfv3IfInstId, ospfv3IfState, ospfv3NbrIfIndex, ospfv3NbrIfInstId, ospfv3VirtIfAreaId, ospfv3VirtIfNeighbor, ospfv3VirtIfState, ospfv3NbrRtrId, ospfv3NbrState, ospfv3VirtNbrArea, ospfv3VirtNbrRtrId, ospfv3VirtIfInstId, ospfv3VirtNbrState, ospfv3ExtAreaLsdbLimit, Ospfv3RouterIdTc, Ospfv3AreaIdTc FROM OSPFV3-MIB; ospfv3Trap MODULE-IDENTITY LAST-UPDATED "200511151600Z" -- Tue Nov 15 16:00:00 IST 2005 ORGANIZATION "" CONTACT-INFO "Nitin Kakkar Postal: Huawei Technologies India Pvt Ltd Level-3, Leela Galleria, The Leela Palace, #23 Airport Road, Bangalore 560008, India Tel: +91 80 5217192 E-Mail: nitink@huawei.com " DESCRIPTION "The MIB module to describe traps for the OSPF Version-3 Protocol." ::= { ospfv3Objects 13 } -- Trap Support Objects -- The following are support objects for the OSPFv3 traps. ospfv3TrapControl OBJECT IDENTIFIER ::= { ospfv3Trap 1 } ospfv3Traps OBJECT IDENTIFIER ::= { ospfv3Trap 2 } ospfv3SetTrap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-write STATUS current DESCRIPTION "A four-octet string serving as a bit map for the trap events defined by the OSPFv3 traps. This object is used to enable and disable specific OSPFv3 traps where a 1 in the bit field represents enabled. The right-most bit (least significant) Expires - May 2006 [Page 5] Internet Draft OSPF Version 3 Trap MIB November 2005 represents trap 0." ::= { ospfv3TrapControl 1 } ospfv3ConfigErrorType OBJECT-TYPE SYNTAX INTEGER { badVersion (1), areaMismatch (2), unknownNbmaNbr (3), -- Router is Dr eligible unknownVirtualNbr (4), helloIntervalMismatch (5), deadIntervalMismatch (6), optionMismatch (7), instanceMismatch (8) } MAX-ACCESS read-only STATUS current DESCRIPTION "Potential types of configuration conflicts. Used by the ospfv3ConfigError and ospfv3ConfigVir- tError traps." ::= { ospfv3TrapControl 2 } ospfv3PacketType OBJECT-TYPE SYNTAX INTEGER { hello (1), dbDescript (2), lsReq (3), lsUpdate (4), lsAck (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "OSPFv3 packet types." ::= { ospfv3TrapControl 3 } ospfv3PacketSrc OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 address of an inbound packet that can- not be identified by a neighbor instance." ::= { ospfv3TrapControl 4 } ospfv3LsdbAreaId OBJECT-TYPE SYNTAX Ospfv3AreaIdTc MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit identifier of the Area from which the Expires - May 2006 [Page 6] Internet Draft OSPF Version 3 Trap MIB November 2005 LSA was received." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfv3TrapControl 5 } ospfv3LsdbType OBJECT-TYPE SYNTAX Unsigned32(0..'FFFFFFFF'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format. Area-Scope LSAs unrecognized by the router are also stored in this database." ::= { ospfv3TrapControl 6 } ospfv3LsdbRouterId OBJECT-TYPE SYNTAX Ospfv3RouterIdTc MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1 Global parameters" ::= { ospfv3TrapControl 7 } ospfv3LsdbLsid OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS Type Specific field containing a unique identifier; it identifies the piece of the routing domain that is being described by the advertisement. In contrast to OSPFv2, the LSID has no addressing semantics." ::= { ospfv3TrapControl 8 } -- Traps ospfv3IfStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3IfIndex, ospfv3IfInstId, ospfv3IfState -- The new state } Expires - May 2006 [Page 7] Internet Draft OSPF Version 3 Trap MIB November 2005 STATUS current DESCRIPTION "An ospfv3IfStateChange trap signifies that there has been a change in the state of a non-virtual OSPF interface. This trap should be generated when the interface state regresses (e.g., goes from Dr to Down) or progresses to a terminal state (i.e., Point-to-Point, DR Other, Dr, or Backup)." ::= { ospfv3Traps 1 } ospfv3VirtIfStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3VirtIfAreaId, ospfv3VirtIfNeighbor, ospfv3VirtIfInstId, ospfv3VirtIfState -- The new state } STATUS current DESCRIPTION "An ospfv3IfStateChange trap signifies that there has been a change in the state of an OSPF virtual interface. This trap should be generated when the inter- face state regresses (e.g., goes from Point- to-Point to Down) or progresses to a terminal state (i.e., Point-to-Point)." ::= { ospfv3Traps 2 } ospfv3NbrStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3NbrIfIndex, ospfv3NbrIfInstId, ospfv3NbrRtrId, ospfv3NbrState -- The new state } STATUS current DESCRIPTION "An ospfv3NbrStateChange trap signifies that there has been a change in the state of a non- virtual OSPF neighbor. This trap should be generated when the neighbor state regresses (e.g., goes from Attempt or Full to 1-Way or Down) or progresses to a terminal state (e.g., 2-Way or Full). When an neighbor transitions from or to Full on non-broadcast multi-access Expires - May 2006 [Page 8] Internet Draft OSPF Version 3 Trap MIB November 2005 and broadcast networks, the trap should be gen- erated by the designated router. A designated router transitioning to Down will be noted by ospfv3IfStateChange." ::= { ospfv3Traps 3 } ospfv3VirtNbrStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3VirtNbrArea, ospfv3VirtNbrIfInstId, ospfv3VirtNbrRtrId, ospfv3VirtNbrState -- The new state } STATUS current DESCRIPTION "An ospfv3IfStateChange trap signifies that there has been a change in the state of an OSPF vir- tual neighbor. This trap should be generated when the neighbor state regresses (e.g., goes from Attempt or Full to 1-Way or Down) or progresses to a terminal state (e.g., Full)." ::= { ospfv3Traps 4 } ospfv3IfConfigError NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3IfIndex, ospfv3IfInstId, ospfv3PacketSrc, -- The source IPv6 address ospfv3ConfigErrorType, -- Type of error ospfv3PacketType } STATUS current DESCRIPTION "An ospfv3IfConfigError trap signifies that a packet has been received on a non-virtual in- terface from a router whose configuration parameters conflict with this router's confi- guration parameters. Note that the event op- tionMismatch should cause a trap only if it prevents an adjacency from forming." ::= { ospfv3Traps 5 } ospfv3VirtIfConfigError NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3VirtIfAreaId, ospfv3VirtIfNeighbor, Expires - May 2006 [Page 9] Internet Draft OSPF Version 3 Trap MIB November 2005 ospfv3VirtIfInstId, ospfv3ConfigErrorType, -- Type of error ospfv3PacketType } STATUS current DESCRIPTION "An ospfv3VirtIfConfigError trap signifies that a packet has been received on a virtual interface from a router whose configuration parameters conflict with this router's configuration parameters. Note that the event optionMismatch should cause a trap only if it prevents an ad- jacency from forming." ::= { ospfv3Traps 6 } ospfv3IfRxBadPacket NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3IfIndex, ospfv3IfInstId, ospfv3PacketSrc, -- The source IPv6 address ospfv3PacketType } STATUS current DESCRIPTION "An ospfv3IfRxBadPacket trap signifies that an OSPF packet has been received on a non-virtual interface that cannot be parsed." ::= { ospfv3Traps 7 } ospfv3VirtIfRxBadPacket NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3VirtIfAreaId, ospfv3VirtIfNeighbor, ospfv3VirtIfInstId, ospfv3PacketType } STATUS current DESCRIPTION "An ospfv3VirtIfRxBadPacket trap signifies that an OSPFv3 packet has been received on a virtual interface that cannot be parsed." ::= { ospfv3Traps 8 } ospfv3TxRetransmit NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3IfIndex, Expires - May 2006 [Page 10] Internet Draft OSPF Version 3 Trap MIB November 2005 ospfv3IfInstId, ospfv3NbrRtrId, -- Destination ospfv3PacketType, ospfv3LsdbType, ospfv3LsdbLsid, ospfv3LsdbRouterId } STATUS current DESCRIPTION "An ospfv3TxRetransmit trap signifies than an OSPF packet has been retransmitted on a non- virtual interface. All packets that may be re- transmitted are associated with an LSDB entry. The LS type, LS ID, and Router ID are used to identify the LSDB entry." ::= { ospfv3Traps 9 } ospfv3VirtIfTxRetransmit NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3VirtIfAreaId, ospfv3VirtIfNeighbor, ospfv3VirtIfInstId, ospfv3PacketType, ospfv3LsdbType, ospfv3LsdbLsid, ospfv3LsdbRouterId } STATUS current DESCRIPTION "An ospfv3VirtIfTxRetransmit trap signifies than an OSPF packet has been retransmitted on a virtual interface. All packets that may be retransmitted are associated with an LSDB entry. The LS type, LS ID, and Router ID are used to identify the LSDB entry." ::= { ospfv3Traps 10 } ospfv3OriginateLsa NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3LsdbAreaId, -- 0.0.0.0 for AS Externals ospfv3LsdbType, ospfv3LsdbLsid, ospfv3LsdbRouterId } STATUS current DESCRIPTION "An ospfv3OriginateLsa trap signifies that a new Expires - May 2006 [Page 11] Internet Draft OSPF Version 3 Trap MIB November 2005 LSA has been originated by this router. This trap should not be invoked for simple refreshes of LSAs (which happesn every 30 minutes), but instead will only be invoked when an LSA is (re)originated due to a topology change. Addi- tionally, this trap does not include LSAs that are being flushed because they have reached MaxAge." ::= { ospfv3Traps 11 } ospfv3MaxAgeLsa NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3LsdbAreaId, -- 0.0.0.0 for AS Externals ospfv3LsdbType, ospfv3LsdbLsid, ospfv3LsdbRouterId } STATUS current DESCRIPTION "An ospfv3MaxAgeLsa trap signifies that one of the LSA in the router's link-state database has aged to MaxAge." ::= { ospfv3Traps 12 } ospfv3UnknownLsa NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfLsid, ospfv3IfIndex, -- Input interface ospfv3IfInstId, ospfOrigRouterId, -- Originator routerID } STATUS current DESCRIPTION "An ospfv3UnknownLsa trap signifies that one of the Nbr has sent an UNknown LSA. Only DR generate this trap and If NBR state is less than Exchange need not originate this trap" ::= { ospfv3Traps 13 } ospfv3LsdbOverflow NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3ExtAreaLsdbLimit } STATUS current DESCRIPTION "An ospfv3LsdbOverflow trap signifies that the Expires - May 2006 [Page 12] Internet Draft OSPF Version 3 Trap MIB November 2005 number of LSAs in the router's link-state data- base has exceeded ospfv3ExtAreaLsdbLimit." ::= { ospfv3Traps 14 } ospfv3LsdbApproachingOverflow NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap ospfv3ExtAreaLsdbLimit } STATUS current DESCRIPTION "An ospfv3LsdbApproachingOverflow trap signifies that the number of LSAs in the router's link- state database has exceeded ninety percent of ospfv3ExtAreaLsdbLimit." ::= { ospfv3Traps 15 } ospfv3AsbrStatusChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap } STATUS current DESCRIPTION "An ospfv3AsbrStatusChange trap signifies that device's Asbr Status has changed." ::= { ospfv3Traps 16 } ospfv3AbrStatusChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the trap } STATUS current DESCRIPTION "An ospfv3AbrStatusChange trap signifies that device's Abr Status has changed. There are two distinct definitions of ABR given by IBM & Cisco, Implementations are free to follow their own interpretation of ABR while originating this trap" ::= { ospfv3Traps 17 } -- conformance information ospfv3TrapConformance OBJECT IDENTIFIER ::= { ospfv3Trap 3 } ospfv3TrapGroups OBJECT IDENTIFIER ::= { ospfv3TrapConformance 1 } ospfv3TrapCompliances OBJECT IDENTIFIER ::= { ospfv3TrapConformance 2 } Expires - May 2006 [Page 13] Internet Draft OSPF Version 3 Trap MIB November 2005 -- compliance statements ospfv3TrapCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { ospfv3TrapControlGroup } GROUP ospfv3TrapControlGroup DESCRIPTION "This group is optional but recommended for all OSPFv3 systems" ::= { ospfv3TrapCompliances 1 } -- units of conformance ospfv3TrapControlGroup OBJECT-GROUP OBJECTS { ospfv3SetTrap, ospfv3ConfigErrorType, ospfv3PacketType, ospfv3PacketSrc } STATUS current DESCRIPTION "These objects are required to control traps from OSPF systems." ::= { ospfv3TrapGroups 1 } END 3. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234. Security Considerations This document does not introduce any new security issues to OSPFv3 References Expires - May 2006 [Page 14] Internet Draft OSPF Version 3 Trap MIB November 2005 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K., Kastenholtz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [RFC1224] L. Steinberg, "Techniques for Managing Asynchronously Generated Alerts" [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC1850] Baker, F., and Coltun, R., "OSPF Version 2 Management Information Base", RFC 1850, November 1995. [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. [RFC2370] Coltun, R., "The OSPF Opqaue LSA Option", RFC 2370, July 1998. [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. Acknowledgments This document is based on the MIB for OSPF version 2 by Rob Coltun and Fred Baker [8] and MIB for OSPF version 3[13] by Dan Joyal and Vishwas Manral. I would like to acknowledge KL Srini, Fuchao, Praveen GS, & Others for their constructive comments. Expires - May 2006 [Page 15] Internet Draft OSPF Version 3 Trap MIB November 2005 Author's Addresses Nitin Kakkar Huawei Technologies India Pvt Ltd, Level-3, Leela Galleria, The Leela Palace, #23 Airport Road, Bangalore 560008, India Phone: +91 80 5217192 Email: nitink@huawei.com Disclaimer of Validity "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Expires - May 2006 [Page 16]