draft-ietf-idr-bgp4-mibv2-01.txt

xorp源码hg

Inter-Domain Routing Working Group                         J. Haas
Internet Draft                                             NextHop
                                                          S. Hares
                                                           NextHop
                                                      W. Tackabury
                                              Gold Wire Technology

                                                November 21, 2001



                     Definitions of Managed Objects
       for the Fourth Version of Border Gateway Protocol (BGP-4),
                             Second Version
                   <draft-ietf-idr-bgp4-mibv2-01.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 mate-
   rial 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.

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



Various Authors           Expires May 21, 2002                  [Page 1]


Internet Draft                 BGP-MIB v2              November 21, 2001


   management of the Border Gateway Protocol Version 4 (BGP4).

   Distribution of this memo is unlimited.


1.  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 compo-
   nents:

     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 proto-
          col 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].

     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].




Various Authors           Expires May 21, 2002                  [Page 2]


Internet Draft                 BGP-MIB v2              November 21, 2001


   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.



2.  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 updat-
   ing 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.


2.1.  Protocol Extensions

   Additionally, however, there are a number of ways in which the BGP
   Protocol has been enhanced through its ability for added capabili-
   ties. Implementations of 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 adop-
   tion of RFC 1657.  For several significant capabilities, in the form
   of BGP Communities [17], Autonomous System Confederation [16] , BGP
   Multiprotocol Extensions [18], and Route Reflection [19], the MIB
   Module defined in this document exposes object types to manage those
   extended capabilities and their operation.

   One of these extensions in particular (the multiprotocol extensions)
   requires a thorough redefinition of MIB table row indices from the
   RFC 1657 state.  This allows transport-independent address indices
   consistent with the Address Family Identifier (AFI) and Subsequent
   Address Family Identifier (SAFI) mechanisms of that extension.


2.2.  Mechanisms for MIB Extensibility

   Moreover, the requirement for the incremental update of support for
   capabilities such as these begs the issue of placing modular extensi-
   bility 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.



Various Authors           Expires May 21, 2002                  [Page 3]


Internet Draft                 BGP-MIB v2              November 21, 2001


2.3.  BGP Configuration

   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 capac-
   ity for configuration of BGP4 and its capabilities than was present
   in RFC 1657 or than was common practice at the time of its adoption.


3.  MIB Organization

   The MIB is broken down into several top level sections.  This sec-
   tionalization is important to create an organization for extensibil-
   ity.

   In general, a top level section of the MIB module will identify some
   number of "core" scalar and tabular objects rooted off of it.  If
   there is sufficient depth within a subsection of one of these top-
   level sections, the "core" subdivision off of the top level section
   may provide multiple levels to the OBJECT IDENTIFIER scope necessary
   to define its management data.

   Once this core section is defined, however, each top-level section
   has an explicit provision for an 'extensions' section OBJECT IDENTI-
   FIER.  The intent of the extensions section is to be containment for
   discrete per-extension sections.  By 'extension' here, we refer to
   protocol mechanisms, capabilities, and exchanges which are not
   defined in the base Border Gateway Protocol definition, or is not
   configuration for protocol operations of similarly 'core' status.
   Currently, we propose keying the identification within the per-exten-
   sion section in one of two ways.

   Where the extension is keyed to a defined capability which has an
   associated BGP capability number assiged by IANA (for example, multi-
   protocol BGP extensions), the per extension section will be that
   defined IANA capability number.  Where the extension has management
   information suitable for a MIB extension but does not correspond to
   an exchanged protocol capability (for example, BGP Route Reflection),
   the extension section shall have its final OBJECT IDENTIFIER fragment
   correspond to the RFC number which first uniquely defined the exten-
   sion (i.e., not requiring renumbering at the time a defining RFC for
   a protocol mechanism is outdated by a later RFC).







Various Authors           Expires May 21, 2002                  [Page 4]


Internet Draft                 BGP-MIB v2              November 21, 2001


3.1.  bgpBaseScalars

   The bgpBaseScalars section (and corresponding OBJECT IDENTIFIER) is
   used to delineate object types used for basic management and monitor-
   ing of the protocol implementation.   These are core parameters for
   the local configuration.  While notifications are designed to be
   extensible into any other section in the MIB module, the currently
   defined traps are located here, in a subsection 'bgpBaseNotifica-
   tions'.  This is rooted at index level zero (0) here, owing to con-
   ventions established in [4].

   Support for multiple concurrently supported versions of BGP is
   exposed through the entries of the bgpVersionTable.  Similarly, sup-
   port for multiple capabilities and authentication mechanisms, as
   identified by their assigned numbers, are reported in the bgpSupport-
   edCapabilitiesTable and bgpSupportedAuthTable respectively.

   In the MIB document, there are currently basic scalar extension mech-
   anisms to allow the agent to report membership of a local BGP Confed-
   eration [21] or Route Reflection Cluster ID [24].  These are consis-
   tent with the non-capability based extension section indexing guide-
   lines as presented above.


3.2.  bgpPeerData

   The bgpPeerData section is per-peer object type definitions. The pre-
   dominant 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 indi-
   vidual route prefixes received over each peer session.  A separate
   subsection and its subordinate table (bgpPeerErrorsTable) reports
   information about the last error encountered on a given peering ses-
   sion.

   Further subsections report authentication state with the peer and
   elapsed time it has taken to advance the peering session into various
   states defined in the protocol FSM.

   The bgpPeerConfiguredTimersTable reports and allows dynamic reset of
   key timers on the peer session.  These currently allow reset of hold
   time and keepalive timer, for compatibility wity the same capabili-
   ties in RFC 1657 [17]. For these resettable timers, their end-to-end
   negotiated current values are reflected in the bgpPeerNegotiated-
   TimersTable.






Various Authors           Expires May 21, 2002                  [Page 5]


Internet Draft                 BGP-MIB v2              November 21, 2001


3.2.1.  bgpPeerCapabilities

   bgpPeerCapabilitiesData has objects and tables to describe BGP capa-
   bilities locally supported, and those reported and negotiated over
   each peer session.   For tables supporting each of these capability
   sets, capability code and data value are provided.  Attention must be
   given to the fact that multiple instances of a given capability can
   be transmitted between BGP speakers.


3.2.2.  bgpPeerCounters

   The bgpCountersTable and bgpPrefixCountersTable report protocol
   exhanges/FSM transitions, and discrete number of NLRIs exchanged per
   peering session, respectively.  This is independent of actual
   exhanged path attributes, which are tabularized later in the MIB mod-
   ule.

3.2.3.  Peering Data Extensions

   Route reflector status on a per-peer basis (whether the peer is a
   client or nonClient of  the local BGP router's reflected route propa-
   gation), and peer confederation membership is reported in non capa-
   bility extensions of the peering data section.

3.3.  BGP Routing Information Base Data

   An important table for providing index information for other tables
   in the MIB module is the bgpNlriTable.  This discriminates on a given
   network prefix (by AFI/SAFI), and the peer which advertised the pre-
   fix (since it can be heard of from multiple spakers).  The bgpPathAt-
   trIndex column which identifies each row in this table is used as an
   index for other per-attribute tables through the remainder of the MIB
   module.

   The bgpPathAttrTable provides discrete BGP NLRI attributes which were
   recieved with the advertisement of the prefix by its advertising
   peer.  Specific information about the autonomous system path (AS
   Path) advertised with the NLRI, on a per AS value, is to be found in
   the bgpAsPathTable.

   Finally, where attributes which were unable to be reported in the
   bgpPathAttrTable, the AS Path table, or any defined per-NLRI tables
   in the agent were recieved with the prefix, those attributes are
   reported via the bgpPathAttrUnknownTable.  Short of advertised
   attribute type, no semantic breakdown of the unknown attribute data
   is provided.  That data is only available as a raw OCTET STRING in
   the bgpPathAttrUnknownValue column of this table.



Various Authors           Expires May 21, 2002                  [Page 6]


Internet Draft                 BGP-MIB v2              November 21, 2001


3.3.1.  Routing Information Base Extensions

   There are two extension sections and five subordinate tables to the
   bgp4PathAttrTable and RIB data OBJECT IDENTIFIER-delimited MIB module
   section. The bgpPathAttrRouteReflectionExts and its contained bgp-
   PathAttrOriginatorIdTable report on the originating route reflector.
   The bgpPathAttrClusterTable specifically reports on the reflection
   route a NLRI has traversed to get to the local BGP routing process.

   The bgpPathAttrCommunityExts section deals with extended and non-
   exteded communities for network routes.  The bgpPathAttrCommTable
   bgpPathAttrExtCommTable  contained herein report community membership
   (if any) on a per network-prefix basis.

3.4.  Consideration On Table Indexing

   There are certain efficiency concerns for row index management for
   management applications which are useful to take into consideration,
   given the nature of some of the tables implied in the preceding sec-
   tion.

   In the first place, it is valuable to exploit the direct relationship
   of entries in, for example, the bgpPrefixCountersTable as they relate
   to the entry in the bgpPeerTable to which they are related.  More
   compelling is the case of the one-to-many relationship between a row
   entry in the bgpPeerTable and the bgp4PathAttrTable, the latter of
   which maintains per-row entries for potentially many NLRIs as
   received from a peer in a BGP UPDATE message.  From the point of view
   of normalizing these relationships, it would be useful to have a
   direct reference to the "governing" bgpPeerTable row entry for the
   peer which is a "dependency" for the subordinate table row entry for
   other peer data.

   Second, the nature of protocol-independent addressing makes the
   indexing of these entries indirectly even more compelling.  Even
   accounting for the addressing requirements of IPv6 and the provision