Internet Draft              BGP-MIB v2              July 13, 2001Network Working Group                                     S. HaresInternet Draft                                             NextHop                                                           J. Haas                                                           NextHop                                                      W. Tackabury				                                                                       Gold Wire Technology								                                                                                                                           Definitions of Managed Objects       for the Fourth Version of Border Gateway Protocol (BGP-4),                              Second Version                    <draft-ietf-idr-bgp4-mibv2-00.txt>Status of this Memo   This document is an Internet-Draft and is in full conformance   with all provisions of Section 10 of RFC2026.   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.Copyright Notice  Copyright (C) The Internet Society (2001).  All Rights Reserved.Various Authors      Expires July  13, 2002             [Page 1]Internet Draft              BGP-MIB v2              July 13, 20011.  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, this MIB defines objects that   facilitate the management of the Border Gateway Protocol Version    4 (BGP4).   Distribution of this memo is unlimited.  2. Introduction   This memo defines a portion of the Management Information Base (MIB)   for use with network management protocols in the Internet community.   In particular, it describes managed objects used for managing the   Border Gateway Protocol Version 4.   The SNMP Management Framework presently consists of five   major components:    o   An overall architecture, described in RFC 2571 [1].    o   Mechanisms for describing and naming objects and        events for the purpose of management. The first        version of this Structure of Management Information        (SMI) is called SMIv1 and described in STD 16, RFC        1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The        second version, called SMIv2, is described in STD 58,        RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].    o   Message protocols for transferring management        information. The first version of the SNMP message        protocol is called SNMPv1 and described in STD 15, RFC        1157 [8]. A second version of the SNMP message        protocol, which is not an Internet standards track        protocol, is called SNMPv2c and described in RFC 1901        [9] and RFC 1906 [10]. The third version of the        message protocol is called SNMPv3 and described in RFC        1906 [10], RFC 2572 [11] and RFC 2574 [12].    o   Protocol operations for accessing management        information. The first set of protocol operations and        associated PDU formats is described in STD 15, RFC        1157 [8]. A second set of protocol operations and        associated PDU formats is described in RFC 1905 [13].Various Authors      Expires July  13, 2002             [Page 2]Internet Draft              BGP-MIB v2              July 13, 2001    	o   A set of fundamental applications described in RFC        2573 [14] and the view-based access control mechanism        described in RFC 2575 [15].   A more detailed introduction to the current SNMP Management   Framework can be found in RFC 2570 [18].   Managed objects are accessed via a virtual information   store, termed the Management Information Base or MIB.   Objects in the MIB are defined using the mechanisms defined   in the SMI.3. Objectives   This MIB Module is meant to broadly update and replace a prior MIB    Module defined in RFC 1657 [12].  Additionally, there is another    effort underway to address very specific limited objectives in   updating points in the RFC 1657 object definition and managed object        attributes [13].  The MIB Module described herein is intended    to fully serve the functions and scope of RFC 1657 and these RFC 1657    updates.   Additionally, however, there are a number of ways in which the BGP   Protocol has been enhanced through its ability for added capabilities,   where those capabilities have not been able to have any management   capabilities present in RFC 1657-compliant MIB module agents, since the   capabilities themselves postdated the adoption of RFC 1657.  For   several significant capabilities of BGP Communities [17], Autonomous    System Confederation [16] , BGP Multiprotocol Extensions [18], and    Route Reflection [19], the MIB Module defines herein objects to manage    those extended capabilities and their operation.   One of these extensions in particular (the multiprotocol extensions)    requires a thorough redefinition of MIB objects from the RFC 1657    state, so as to allow transport-independent address exposure consistent   with the Address Family Identifier (AFI) and Subsequent Address Family    Identifier (SAFI) mechanisms of that extension.     Moreover, the requirement for the incremental update of support for    capabilities such as these begs the issue of placing modular    extensibility for protocol extensions within the framework of the MIB   itself.  Going forward, it would be very desirable to have attributes   of the MIB structure, and administrative procedures, to allow the    incremental update of the MIB scope to cover any such new protocol    extensions, without requiring a reissue of the entire MIB.  In this    sense, we seek to structure the MIB much like the underlying BGP4    itself, allowing capability-by-capability update.   Finally, the definition and adoption of Version 3 of the SNMP has    occurred since the adoption of the RFC 1657 MIB.  As a result, the   ability to deploy secure configuration of managed elements via SNMP    in a standardized way has become a reality for managed networks.  In    this MIB definition effort, we seek to expose a more thorough    capacity for configuration of BGP4 and its capabilities than was Various Authors      Expires July  13, 2002             [Page 3]Internet Draft              BGP-MIB v2              July 13, 2001      present in RFC 1657 or than was common practice at the time of its   adoption.4. MIB Organization   The MIB is broken down into several top level sections.  This    sectionalization is important to create an organization for    extensibility:   * The bgpBaseScalars section (and corresponding OBJECT IDENTIFIER)      is used to delineate objects used for basic management and 	 monitoring of the protocol implementation.   These are core 	 parameters for the local configuration.   * The bgpPeerData section is per-peer object definitions. The     predominant table in that section (bgpPeerTable) describes the     session, negotiation state, and authentication state on a      per peer basis.  A second table (bgpPrefixCountersTable) exposes 	 information about individual route prefixes received      over each peer session.  * bgpCapabilitiesData has objects and tables to describe  BGP     capabilities locally supported, and those reported and negotiated	over each peer session.  * bgpPathAttributesData contains objects describing destination    networks and paths to those networks, independent of the peer    from which the information on each network was received.   Each section is further given an OBJECT IDENTIFIER allowing a section   of containment for the per-capability extensions of the scope of the   section.  4.1  Preliminary State of Work   The MIB herein is the first, very rough, step in the refinement of   the managed object definition this effort seeks to define.  It is being   offered to the community at this moment to get a read as to the    general directions and ideas being pursued.  Reviewers are urged not    to focus too much on certain details, or the inevitable roughness   of their specification.  Attention to those details is promised   with the next revision or two of this internet-draft.Various Authors      Expires July  13, 2002             [Page 4]Internet Draft              BGP-MIB v2              July 13, 20015. Definitions    BGP4-V2-MIB DEFINITIONS ::= BEGIN        IMPORTS            MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,            IpAddress, Integer32, Counter32, Gauge32, mib-2,         experimental, Unsigned32                FROM SNMPv2-SMI        InetAddressType, InetAddress        FROM INET-ADDRESS-MIB        TEXTUAL-CONVENTION, TruthValue            FROM SNMPv2-TC            MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP                FROM SNMPv2-CONF;        bgp MODULE-IDENTITY            LAST-UPDATED "200107060000Z"            ORGANIZATION "IETF IDR Working Group"            CONTACT-INFO "E-mail:  idr@merit.net                          Jeff Haas  (Editor)                          517 W. William Street                          Ann Arbor, MI 48103-4943                          Tel: +1 734 973-2200                           Fax: +1 734 615-3241                          E-mail: jhaas@nexthop.com"            DESCRIPTION           "This MIB module defines management objects for           the Border Gateway Protocol, Version 4."            ::= { mib-2 ??? }    BgpIdentifier ::= TEXTUAL-CONVENTION        DISPLAY-HINT "1d:"        -- jmh - is this right?        STATUS     current        DESCRIPTION        "The representation of a BGP Identifier."        SYNTAX OCTET STRING(SIZE (4))    BgpSafi ::= TEXTUAL-CONVENTION        DISPLAY-HINT "d"        STATUS current        DESCRIPTION        "The representation of a BGP Safi"        SYNTAX Integer32(0..255)    		Various Authors      Expires July  13, 2002             [Page 5]Internet Draft              BGP-MIB v2              July 13, 2001		BgpAutonomousSystemNumber ::= TEXTUAL-CONVENTION        DISPLAY-HINT "d"        STATUS current        DESCRIPTION        "An autonomous System Number.  If bgpAsSize is          two-octet, the range is 0..65535.  If it is         four-octet, it is the full range of Unsigned32."        SYNTAX Unsigned32     bgpBaseScalars          OBJECT IDENTIFIER ::= { bgp 1 }    -- notifications and derivations from the SNMPv1 'trap' in general    -- must be rooted at suboid 0        bgpBaseTraps        OBJECT IDENTIFIER ::= { bgpBaseScalars 0 }        bgpEstablished NOTIFICATION-TYPE            OBJECTS {         bgpPeerRemoteAddrType,        bgpPeerRemoteAddr,        bgpPeerLastError,                bgpPeerState        }            STATUS  current            DESCRIPTION                "The BGP Established event is generated when                 the BGP FSM enters the ESTABLISHED state."            ::= { bgpBaseTraps 1 }        bgpBackwardTransition NOTIFICATION-TYPE            OBJECTS {         bgpPeerRemoteAddrType,        bgpPeerRemoteAddr,                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."            ::= { bgpBaseTraps 2 }------        										Various Authors      Expires July  13, 2002             [Page 6]Internet Draft              BGP-MIB v2              July 13, 2001				bgpVersion OBJECT-TYPE            SYNTAX     OCTET STRING (SIZE (1..32))            MAX-ACCESS read-only            STATUS     current            DESCRIPTION                    "Vector of supported BGP protocol version                    numbers.  Each peer negotiates the version                    from this vector.  Versions are identified                    via the string of bits contained within this                    object.  The first octet contains bits 0 to                    7, the second octet contains bits 8 to 15,                    and so on, with the most significant bit                    referring to the lowest bit number in the                    octet (e.g., the MSB of the first octet                    refers to bit 0).  If a bit, i, is present                    and set, then the version (i+1) of the BGP                    is supported."            ::= { bgpBaseScalars 1 }------    bgpAsSize OBJECT-TYPE        SYNTAX     INTEGER {            twoOctet(1),            fourOctet(2)        }        MAX-ACCESS read-only        STATUS     current        DESCRIPTION        "The size of the AS value in this implementation.        The semantics of this are determined as per the         as-4bytes draft."        ::= { bgpBaseScalars 2 }        --