Network Working Group                                          S. Zhuang
Internet-Draft                                                     Z. Li
Intended status: Informational                                    G. Yan
Expires: September 14, 2017                                       Huawei
                                                                   P. Mi
                                                                 Tencent
                                                          March 13, 2017


                 Monitoring BGP Capabilities Using BMP
            draft-zhuang-grow-monitoring-bgp-capabilities-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.

   This document provides a use case that the BMP station can get all
   BGP capability information 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 http://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 September 14, 2017.








Zhuang, et al.         Expires September 14, 2017               [Page 1]


Internet-Draft         Monitoring BGP Capabilities            March 2017


Copyright Notice

   Copyright (c) 2017 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
   (http://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.  Virtual Peer  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Terminology

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

   Virtual Peer: A virtual BGP speaker connecting to the network device

   BMP: BGP Monitoring Protocol

   BMS: BGP Monitoring Station

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
   capabilities, e.g., IPv4 Unicast, IPv4 Multicast, IPv6 Unicast, and
   other multiple-protocol extended capabilities, and the different BGP
   may support a different number of different capabilities.  The
   network device configured with the BGP typically may not enable all
   capabilities supported in the configured BGP, but enable some
   currently required BGP capabilities as required for a current task.



Zhuang, et al.         Expires September 14, 2017               [Page 2]


Internet-Draft         Monitoring BGP Capabilities            March 2017


   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 capabilities in 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 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 capabilities will include only the
   BGP capabilities enabled on the network device A.

   However it may not suffice if only the deployed or enabled BGP
   capabilities are sent, but the monitoring station has to obtain all
   the BGP capabilities supported by the network devices configured with
   the BGP in the network, including the enabled and disabled BGP
   capabilities, so that the monitoring station can know comprehensively
   the real capabilities supported throughout the network, and further
   provide a valid criterion for deployment and decision throughout the
   network.

   This document provides a use case that the BMP station can get all
   BGP capability information of the monitored network device via BMP.

3.  Virtual Peer

   As described in Section 8.2 of [RFC7854], locally originated routes
   can be modeled as having been sent by the router to itself.  This
   document introduces a virtual BGP speaker for the monitored router



Zhuang, et al.         Expires September 14, 2017               [Page 3]


Internet-Draft         Monitoring BGP Capabilities            March 2017


   that the speaker is connecting to the router.  The virtual BGP
   speaker existing in the router is a virtual Peer to the router.

4.  Operation

   Consider the following scenario:

   A simple topology:

   BMS---Device A----Device B

   Configure a BMP session between BMS and Device A,
   and a BGP session between Device A and B.


   Suppose that the BGP capabilities supported on the network device A
   and B include three BGP capabilities, which are IPv4 Unicast, IPv4
   Multicast, and IPv6 Unicast respectively, and only one of the BGP
   capabilities is currently enabled on the network device A and B,
   which is IPv4 Unicast.

   When the BGP session between Device A and B reaches the Established
   state, Device A will send a few BMP messages to BMS, one of the
   messages is a Peer Up Notification message, which includes only IPv4
   Unicast multiple-protocol extended capabilitiy.  In this case, the
   BMS does not know the other support capabilities, such as IPv4
   Multicast and IPv6 Unicast.

   When the network device A is configured to create a virtual peer, the
   process follows the steps:

   1) A gets all the BGP capabilities from BGP module.

   2) A encapsulates a Peer Up Notification message as follows:

   o  Setting Peer Type field of the Per-Peer header to 2 (Local
      Instance Peer )

   o  Placing the router's own address in the Peer Address field of the
      Per-Peer header

   o  Setting the Local Port field to 0

   o  Setting the Remote Port field to 0

   o  Including IPv4 Unicast, IPv4 Multicast, and IPv6 Unicast in the
      "Received OPEN Message" part




Zhuang, et al.         Expires September 14, 2017               [Page 4]


Internet-Draft         Monitoring BGP Capabilities            March 2017


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Local Address (16 bytes)                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Local Port            |        Remote Port            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sent OPEN Message                          |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Received OPEN Message                        |
   ~                 (NULL for Virtual Peer)                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Information (variable)                        |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: Peer Up Notification for Virtual Peer

   3) Upon reception of the Peer Up Notification message, BMS can
   indentify the virtual peer identifier of the network device A,
   thereby gets all the BGP multiple-protocol extended capabilities
   corresponding to the network device A.

   Use the method described above, the monitoring station BMS can know
   comprehensively the real BGP capabilities supported by the monitored
   device.

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,
              <http://www.rfc-editor.org/info/rfc2119>.




Zhuang, et al.         Expires September 14, 2017               [Page 5]


Internet-Draft         Monitoring BGP Capabilities            March 2017


   [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,
              <http://www.rfc-editor.org/info/rfc4271>.

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

Authors' Addresses

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

   Email: zhuangshunwan@huawei.com


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

   Email: lizhenbin@huawei.com


   Gang Yan
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: yangang@huawei.com


   Penghui Mi
   Tencent
   Tengyun Building,Tower A ,No. 397 Tianlin Road
   Shanghai  200233
   China

   Email: kevinmi@tencent.com





Zhuang, et al.         Expires September 14, 2017               [Page 6]