[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          S. Zhuang
Internet-Draft                                                     Y. Gu
Intended status: Standards Track                                   Z. Li
Expires: January 3, 2019                                          Huawei
                                                           July 02, 2018


                  Monitoring BGP Parameters Using BMP
             draft-zhuang-grow-monitoring-bgp-parameters-00

Abstract

   The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor
   BGP [RFC4271] running status, such as BGP peer relationship
   establishment and termination and route updates.  Without BMP, manual
   query is required if you want to know about BGP running status.

   This document provides the use cases that the BMP station can get the
   optional and default configure parameters of the monitored network
   device via BMP.

Requirements Language

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 3, 2019.








Zhuang, et al.           Expires January 3, 2019                [Page 1]


Internet-Draft          Monitoring BGP Parameters              July 2018


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Extension of BMP Initiation Message . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Terminology

   This memo makes use of the terms defined in [RFC7854].

   BMP: BGP Monitoring Protocol

   BMS: BGP Monitoring Station

   Initiation message: Reports to the monitoring server such information
   as the router vendor and its software version.

2.  Introduction

   The Border Gateway Protocol (BGP) is a dynamic routing protocol
   operating on an Autonomous System (AS) and typically configured on a
   network device.  The BGP typically can support a number of optional
   parameters[RFC5492], e.g., IPv4 Unicast, IPv4 Multicast, IPv6
   Unicast, and other Multiple-Protocol Extended Capabilities, Route
   Refresh Capability, Outbound Route Filtering Capability, Graceful
   Restart Capability, Support for 4-octet AS number capability etc.,
   and the different BGP may support a different number of different



Zhuang, et al.           Expires January 3, 2019                [Page 2]


Internet-Draft          Monitoring BGP Parameters              July 2018


   capabilities.  The network device configured with the BGP typically
   may not enable all optional capabilities supported in the configured
   BGP, but enable some currently required BGP optional capabilities as
   required for a current task.

   The BGP Monitoring Protocol (BMP) introduces the availability of
   monitoring BGP running status, such as BGP peer relationship
   establishment and termination and route updates.  Without BMP, manual
   query is required if you want to know about BGP running status.  With
   BMP, a router can be connected to a monitoring station and configured
   to report BGP running statistics to the station for monitoring, which
   improves the network monitoring efficiency.  BMP facilitates the
   monitoring of BGP running status and reports security threats in real
   time so that preventive measures can be taken promptly.

   In order to monitor and manage effectively the operating states of
   the BGP configured on the respective network devices in the network,
   the existing practice is that a monitoring station obtains BGP
   information of the respective network devices in the network to
   monitor and manage centrally the network devices configured with the
   BGP in the network.  By way of an example of a flow in which the
   monitoring station obtains the BGP information, after a BGP
   connection is set up between network devices A and B configured with
   the BGP (or between peers), taking the network device A as an
   example, the network devices A and B negotiate about their own
   enabled BGP optional capabilities in OPEN messages under a BGP rule,
   and the network device A further includes a BGP Monitoring Protocol
   (BMP) module connected with the monitoring station, where the BMP
   module can obtain the enabled BGP optional capabilities of the
   network device A, and the enabled BGP capabilities of the network
   device B as a result of negotiation about the enabled BGP
   capabilities, so that if the BMP module of the network device A sends
   the configured BGP information of the network device to the
   monitoring station in a Peer Up Notification message, then the BGP
   optional capabilities will include only the BGP capabilities enabled
   on the network device A.

   However, sometimes it's not sufficient to report only the
   capabilities currently enabled at the monitored device to the BMS.
   In order to better optimize the network, the BMS may want to access
   all the capabilites that are supported at each monitored devices, as
   well as the current configuration informations.

3.  Use cases

   o  BGP Optional Parameters: The Open Message reported to BMS contains
      only the currently enabled capabilities at the monitored device.
      If all the supported capabilities of the monitored devices, both



Zhuang, et al.           Expires January 3, 2019                [Page 3]


Internet-Draft          Monitoring BGP Parameters              July 2018


      the enabled and not yet enabled ones, are informed to the BMS, the
      BMS can use the more comprehensive and valid inputs to make
      decisions about the whole network optimization.  For example, if
      the Graceful Restart Capability is not enabled for a BGP Peer, and
      thus the BGP Open Message (i.e., the Peer Up Notification in BMP)
      would not include the GR capability.  However, if the BMS or the
      operator has the knowledge that both devices support the GR
      capability, and enables it at both devices, it could improve the
      operational stability of the network.

   o  BGP Default Behavior Parameters: As one of the concern from the
      operators, that in multi-vendor environment, some default
      configurations or behabiors of devices are vendor-specific, and
      may cause various issues during the interoperation test or any
      time after.  Take the protocol preferences (distance) of different
      BGP routes for example: Vendor A assigns value 255 to eBGP, iBGP
      and BGP local routes by default, while vendor B assigns 20 to
      eBGP, 200 to iBGP and 200 to BGP local routes by default.  In
      addition, value 255 is not recognized by vendor B, and routes
      assigned such distance would be ignored.

4.  Extension of BMP Initiation Message

   As described in Section 4.3 of [RFC7854], the initiation message
   provides a means for the monitored router to inform the monitoring
   station of its vendor, software version, and so on.

   The initiation message consists of the common BMP header followed by
   two or more Information TLVs (Section 4.4 of [RFC7854]) containing
   information about the monitored router.  Currently defined types are:

   Type = 0: String.

   Type = 1: sysDescr.

   Type = 2: sysName.

   This document defines two new catagories of TLV types: the BGP
   Optional Parameters and the BGP Default Behavior Parameters.

   Type = TBD1: BGP Optional Parameters.  The Information field is used
   to specify all the BGP Optional Parameters that have been enabled or
   not yet enabled at the monitored device.  Each optional parameter is
   encoded as a <Parameter Type, Parameter Length, Parameter Value>
   triplet, as defined in RFC 4271 [RFC4271] .






Zhuang, et al.           Expires January 3, 2019                [Page 4]


Internet-Draft          Monitoring BGP Parameters              July 2018


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
   |  Parm. Type   | Parm. Length  |  Parameter Value (variable)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   Figure 1 BGP Optional Parameters Information TLV

   Parameter Type is a one octet field that unambiguously identifies
   individual parameters.  Parameter Length is a one octet field that
   contains the length of the Parameter Value field in octets.
   Parameter Value is a variable length field that is interpreted
   according to the value of the Parameter Type field.  RFC 5492
   [RFC5492] defines the Capabilities Optional Parameter.

   Type = TBD2: Default Behavior Parameters.  The Information field
   contains a list of default behavior parameters, in which each
   parameter is encoded as a Default Behavior sub TLV <Default Behavior
   Type, Default Behavior Length, Default Behavior Value>, which is
   defined as follows

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-------------------------------+-------------------------------+
   |       Default Beh. Type       |        Def Beh. Length        |
   +-------------------------------+-------------------------------+
   +                  Default Beh. Value (variable)                +
   ~                                                               ~
   +---------------------------------------------------------------+

   Figure 2 Default Behavior sub TLV

   The Default Behavior Type is a one octet field that identifies the
   defualt behavior type parameter.  Parameter Length is a one octet
   field that contains the length of the Parameter Value field in
   octets.  Parameter Value is a variable length field that is
   interpreted according to the value of the Parameter Type field:

   o  Type = TBD3, (32-bit integer ) Value of default Protocol
      Preference for Local route

   o  Type = TBD4, (32-bit integer ) Value of default Protocol
      Preference for EBGP route

   o  Type = TBD5, (32-bit integer ) Value of default Protocol
      Preference for IBGP route





Zhuang, et al.           Expires January 3, 2019                [Page 5]


Internet-Draft          Monitoring BGP Parameters              July 2018


   o  Type = TBD6, (32-bit integer ) Value of default BGP connect-retry
      timer time

   o  Type = TBD7, (32-bit integer ) Value of default BGP Keepalive time

   o  Type = TBD8, (32-bit integer ) Value of default BGP hold time

   o  Type = TBD9, (32-bit integer ) Value of EBGP route-update-interval

   o  Type = TBD10, (32-bit integer ) Value of IBGP route-update-
      interval

   o  Type = TBD11, (32-bit integer ) Value of Default local-preference

   o  Type = TBD12, (32-bit integer ) Value of Default MED

5.  Acknowledgements

   TBD.

6.  IANA Considerations

   TBD.

7.  Security Considerations

   TBD.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <https://www.rfc-editor.org/info/rfc5492>.

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/info/rfc7854>.



Zhuang, et al.           Expires January 3, 2019                [Page 6]


Internet-Draft          Monitoring BGP Parameters              July 2018


Authors' Addresses

   Shunwan Zhuang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com


   Yunan Gu
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: guyunan@huawei.com


   Zhenbin Li
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com
























Zhuang, et al.           Expires January 3, 2019                [Page 7]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/