Internet DRAFT - draft-zhuang-grow-monitoring-bgp-parameters
draft-zhuang-grow-monitoring-bgp-parameters
Network Working Group S. Zhuang
Internet-Draft Y. Gu
Intended status: Standards Track H. Wang
Expires: May 7, 2020 Huawei
November 04, 2019
Monitoring BGP Parameters Using BMP
draft-zhuang-grow-monitoring-bgp-parameters-01
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 parameters that are supported by the monitored network
device 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 May 7, 2020.
Zhuang, et al. Expires May 7, 2020 [Page 1]
Internet-Draft Monitoring BGP Parameters November 2019
Copyright Notice
Copyright (c) 2019 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 implementations may support a different number
Zhuang, et al. Expires May 7, 2020 [Page 2]
Internet-Draft Monitoring BGP Parameters November 2019
of different 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 capabilities 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 May 7, 2020 [Page 3]
Internet-Draft Monitoring BGP Parameters November 2019
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 behaviors 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 categories 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 May 7, 2020 [Page 4]
Internet-Draft Monitoring BGP Parameters November 2019
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 Parameters sub TLV
The Default Behavior Type is a one octet field that identifies the
default 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 May 7, 2020 [Page 5]
Internet-Draft Monitoring BGP Parameters November 2019
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 May 7, 2020 [Page 6]
Internet-Draft Monitoring BGP Parameters November 2019
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
Haibo Wang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: rainsword.wang@huawei.com
Zhuang, et al. Expires May 7, 2020 [Page 7]
