updated bgp-4 mib submitted
"Jeffrey T. Johnson" <jjohnson@cisco.com> Tue, 09 January 1996 01:21 UTC
Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14745 (5.65c/IDA-1.4.4 for <archive-iwg@ftp.ans.net>); Mon, 8 Jan 1996 20:21:21 -0500
Received: by p-o.ans.net id AA12535 (5.65c/IDA-1.4.4 for bgp-outgoing); Tue, 9 Jan 1996 01:21:19 GMT
From: "Jeffrey T. Johnson" <jjohnson@cisco.com>
Date: Mon, 08 Jan 1996 17:16:45 -0800
Message-Id: <199601090116.RAA05779@jjohnson-ss20.cisco.com>
To: bgp@ans.net
Subject: updated bgp-4 mib submitted
Sender: bgp-owner@ans.net
Precedence: bulk
Reply-To: bgp@ans.net
Since I raised an objection to the BGP-4 MIB at last call, I was requested to update the MIB so as to resolve my concerns. I have submitted an updated MIB to CNRI. The two major diffs, with an explanation, follows. Major diff 1, trap definitions. Recall that in RFC 1269 the following traps were defined: bgpEstablished TRAP-TYPE ENTERPRISE { bgp } VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError, bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM enters the ESTABLISHED state. " ::= 1 bgpBackwardTransition TRAP-TYPE ENTERPRISE { bgp } VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError, bgpPeerState } DESCRIPTION "The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state." ::= 2 In RFC 1657, these traps were converted to the SNMPv2 SMI as follows: bgpTraps OBJECT IDENTIFIER ::= { bgp 7 } bgpEstablished NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGP Established event is generated when the BGP FSM enters the ESTABLISHED state." ::= { bgpTraps 1 } bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state." ::= { bgpTraps 2 } There were two problems with these definitions. The first problem was the assignment of the OIDs to the traps. Although the procedure was hidden in the coexistance document, the mechanism for converting a V1-style trap into a V2-style trap is described as: ...the value used is the concatenation of the enterprise field from the Trap-PDU with two additional sub-identifiers, `0', and the value of the specific-trap field... Hence the OID assigned to bgpEstablished should have been bgp.0.1 and the OID assigned to bgpBackwardTransition should have been bgp.0.2. This is easily fixed by changing the definition of bgpTraps from: bgpTraps OBJECT IDENTIFIER ::= { bgp 7 } to bgpTraps OBJECT IDENTIFIER ::= { bgp 0 } The second problem with the new trap definitions was that the mib object bgpPeerRemoteAddr was removed from the varbind list of the trap. I understand the rationale for removing the object, but that doesn't make it legal to do so. Major diff #2, compliance and conformance info. RFC 1657 did not contain any compliance or conformance information, which is required of all SNMPv2 mibs. I have added this information. Note that based on the recommendation of the Network Management Area Director, I have based my definitions on the latest draft of the conformance documents, draft-ietf-snmpv2-conf-ds-06.txt. The major difference between this drat and RFC 1444 which affects the BGP MIB is that the new draft introduces the NOTIFICATION-GROUP macro which the mib utilizes. regards /jeff
- updated bgp-4 mib submitted Jeffrey T. Johnson