idnits 2.17.1 draft-zhuang-grow-monitoring-bgp-parameters-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271], [RFC7854]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 04, 2019) is 1632 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Zhuang 3 Internet-Draft Y. Gu 4 Intended status: Standards Track H. Wang 5 Expires: May 7, 2020 Huawei 6 November 04, 2019 8 Monitoring BGP Parameters Using BMP 9 draft-zhuang-grow-monitoring-bgp-parameters-01 11 Abstract 13 The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor 14 BGP [RFC4271] running status, such as BGP peer relationship 15 establishment and termination and route updates. Without BMP, manual 16 query is required if you want to know about BGP running status. 18 This document provides the use cases that the BMP station can get the 19 optional parameters that are supported by the monitored network 20 device and default configure parameters of the monitored network 21 device via BMP. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 7, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Extension of BMP Initiation Message . . . . . . . . . . . . . 4 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Terminology 75 This memo makes use of the terms defined in [RFC7854]. 77 BMP: BGP Monitoring Protocol 79 BMS: BGP Monitoring Station 81 Initiation message: Reports to the monitoring server such information 82 as the router vendor and its software version. 84 2. Introduction 86 The Border Gateway Protocol (BGP) is a dynamic routing protocol 87 operating on an Autonomous System (AS) and typically configured on a 88 network device. The BGP typically can support a number of optional 89 parameters[RFC5492], e.g., IPv4 Unicast, IPv4 Multicast, IPv6 90 Unicast, and other Multiple-Protocol Extended Capabilities, Route 91 Refresh Capability, Outbound Route Filtering Capability, Graceful 92 Restart Capability, Support for 4-octet AS number capability etc., 93 and the different BGP implementations may support a different number 94 of different capabilities. The network device configured with the 95 BGP typically may not enable all optional capabilities supported in 96 the configured BGP, but enable some currently required BGP optional 97 capabilities as required for a current task. 99 The BGP Monitoring Protocol (BMP) introduces the availability of 100 monitoring BGP running status, such as BGP peer relationship 101 establishment and termination and route updates. Without BMP, manual 102 query is required if you want to know about BGP running status. With 103 BMP, a router can be connected to a monitoring station and configured 104 to report BGP running statistics to the station for monitoring, which 105 improves the network monitoring efficiency. BMP facilitates the 106 monitoring of BGP running status and reports security threats in real 107 time so that preventive measures can be taken promptly. 109 In order to monitor and manage effectively the operating states of 110 the BGP configured on the respective network devices in the network, 111 the existing practice is that a monitoring station obtains BGP 112 information of the respective network devices in the network to 113 monitor and manage centrally the network devices configured with the 114 BGP in the network. By way of an example of a flow in which the 115 monitoring station obtains the BGP information, after a BGP 116 connection is set up between network devices A and B configured with 117 the BGP (or between peers), taking the network device A as an 118 example, the network devices A and B negotiate about their own 119 enabled BGP optional capabilities in OPEN messages under a BGP rule, 120 and the network device A further includes a BGP Monitoring Protocol 121 (BMP) module connected with the monitoring station, where the BMP 122 module can obtain the enabled BGP optional capabilities of the 123 network device A, and the enabled BGP capabilities of the network 124 device B as a result of negotiation about the enabled BGP 125 capabilities, so that if the BMP module of the network device A sends 126 the configured BGP information of the network device to the 127 monitoring station in a Peer Up Notification message, then the BGP 128 optional capabilities will include only the BGP capabilities enabled 129 on the network device A. 131 However, sometimes it's not sufficient to report only the 132 capabilities currently enabled at the monitored device to the BMS. 133 In order to better optimize the network, the BMS may want to access 134 all the capabilities that are supported at each monitored devices, as 135 well as the current configuration informations. 137 3. Use cases 139 o BGP Optional Parameters: The Open Message reported to BMS contains 140 only the currently enabled capabilities at the monitored device. 141 If all the supported capabilities of the monitored devices, both 142 the enabled and not yet enabled ones, are informed to the BMS, the 143 BMS can use the more comprehensive and valid inputs to make 144 decisions about the whole network optimization. For example, if 145 the Graceful Restart Capability is not enabled for a BGP Peer, and 146 thus the BGP Open Message (i.e., the Peer Up Notification in BMP) 147 would not include the GR capability. However, if the BMS or the 148 operator has the knowledge that both devices support the GR 149 capability, and enables it at both devices, it could improve the 150 operational stability of the network. 152 o BGP Default Behavior Parameters: As one of the concern from the 153 operators, that in multi-vendor environment, some default 154 configurations or behaviors of devices are vendor-specific, and 155 may cause various issues during the interoperation test or any 156 time after. Take the protocol preferences (distance) of different 157 BGP routes for example: Vendor A assigns value 255 to eBGP, iBGP 158 and BGP local routes by default, while vendor B assigns 20 to 159 eBGP, 200 to iBGP and 200 to BGP local routes by default. In 160 addition, value 255 is not recognized by vendor B, and routes 161 assigned such distance would be ignored. 163 4. Extension of BMP Initiation Message 165 As described in Section 4.3 of [RFC7854], the initiation message 166 provides a means for the monitored router to inform the monitoring 167 station of its vendor, software version, and so on. 169 The initiation message consists of the common BMP header followed by 170 two or more Information TLVs (Section 4.4 of [RFC7854]) containing 171 information about the monitored router. Currently defined types are: 173 Type = 0: String. 175 Type = 1: sysDescr. 177 Type = 2: sysName. 179 This document defines two new categories of TLV types: the BGP 180 Optional Parameters and the BGP Default Behavior Parameters. 182 Type = TBD1: BGP Optional Parameters. The Information field is used 183 to specify all the BGP Optional Parameters that have been enabled or 184 not yet enabled at the monitored device. Each optional parameter is 185 encoded as a 186 triplet, as defined in RFC 4271 [RFC4271] . 188 0 1 189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 191 | Parm. Type | Parm. Length | Parameter Value (variable) 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 194 Figure 1: BGP Optional Parameters Information TLV 196 Parameter Type is a one octet field that unambiguously identifies 197 individual parameters. Parameter Length is a one octet field that 198 contains the length of the Parameter Value field in octets. 199 Parameter Value is a variable length field that is interpreted 200 according to the value of the Parameter Type field. RFC 5492 201 [RFC5492] defines the Capabilities Optional Parameter. 203 Type = TBD2: Default Behavior Parameters. The Information field 204 contains a list of default behavior parameters, in which each 205 parameter is encoded as a Default Behavior sub TLV , which is 207 defined as follows: 209 0 1 2 3 210 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 211 +-------------------------------+-------------------------------+ 212 | Default Beh. Type | Def Beh. Length | 213 +-------------------------------+-------------------------------+ 214 + Default Beh. Value (variable) + 215 ~ ~ 216 +---------------------------------------------------------------+ 218 Figure 2: Default Behavior Parameters sub TLV 220 The Default Behavior Type is a one octet field that identifies the 221 default behavior type parameter. Parameter Length is a one octet 222 field that contains the length of the Parameter Value field in 223 octets. Parameter Value is a variable length field that is 224 interpreted according to the value of the Parameter Type field: 226 o Type = TBD3, (32-bit integer ) Value of default Protocol 227 Preference for Local route 229 o Type = TBD4, (32-bit integer ) Value of default Protocol 230 Preference for EBGP route 232 o Type = TBD5, (32-bit integer ) Value of default Protocol 233 Preference for IBGP route 235 o Type = TBD6, (32-bit integer ) Value of default BGP connect-retry 236 timer time 238 o Type = TBD7, (32-bit integer ) Value of default BGP Keepalive time 240 o Type = TBD8, (32-bit integer ) Value of default BGP hold time 242 o Type = TBD9, (32-bit integer ) Value of EBGP route-update-interval 244 o Type = TBD10, (32-bit integer ) Value of IBGP route-update- 245 interval 247 o Type = TBD11, (32-bit integer ) Value of Default local-preference 249 o Type = TBD12, (32-bit integer ) Value of Default MED 251 5. Acknowledgements 253 TBD. 255 6. IANA Considerations 257 TBD. 259 7. Security Considerations 261 TBD. 263 8. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 271 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 272 DOI 10.17487/RFC4271, January 2006, 273 . 275 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 276 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 277 2009, . 279 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 280 Monitoring Protocol (BMP)", RFC 7854, 281 DOI 10.17487/RFC7854, June 2016, 282 . 284 Authors' Addresses 286 Shunwan Zhuang 287 Huawei 288 Huawei Bld., No.156 Beiqing Rd. 289 Beijing 100095 290 China 292 Email: zhuangshunwan@huawei.com 294 Yunan Gu 295 Huawei 296 Huawei Bld., No.156 Beiqing Rd. 297 Beijing 100095 298 China 300 Email: guyunan@huawei.com 302 Haibo Wang 303 Huawei 304 Huawei Bld., No.156 Beiqing Rd. 305 Beijing 100095 306 China 308 Email: rainsword.wang@huawei.com