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