idnits 2.17.1 draft-zhuang-grow-monitoring-bgp-parameters-00.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 (July 02, 2018) is 2125 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 Z. Li 5 Expires: January 3, 2019 Huawei 6 July 02, 2018 8 Monitoring BGP Parameters Using BMP 9 draft-zhuang-grow-monitoring-bgp-parameters-00 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 and default configure parameters of the monitored network 20 device via BMP. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 3, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Extension of BMP Initiation Message . . . . . . . . . . . . . 4 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Terminology 74 This memo makes use of the terms defined in [RFC7854]. 76 BMP: BGP Monitoring Protocol 78 BMS: BGP Monitoring Station 80 Initiation message: Reports to the monitoring server such information 81 as the router vendor and its software version. 83 2. Introduction 85 The Border Gateway Protocol (BGP) is a dynamic routing protocol 86 operating on an Autonomous System (AS) and typically configured on a 87 network device. The BGP typically can support a number of optional 88 parameters[RFC5492], e.g., IPv4 Unicast, IPv4 Multicast, IPv6 89 Unicast, and other Multiple-Protocol Extended Capabilities, Route 90 Refresh Capability, Outbound Route Filtering Capability, Graceful 91 Restart Capability, Support for 4-octet AS number capability etc., 92 and the different BGP may support a different number of different 93 capabilities. The network device configured with the BGP typically 94 may not enable all optional capabilities supported in the configured 95 BGP, but enable some currently required BGP optional capabilities as 96 required for a current task. 98 The BGP Monitoring Protocol (BMP) introduces the availability of 99 monitoring BGP running status, such as BGP peer relationship 100 establishment and termination and route updates. Without BMP, manual 101 query is required if you want to know about BGP running status. With 102 BMP, a router can be connected to a monitoring station and configured 103 to report BGP running statistics to the station for monitoring, which 104 improves the network monitoring efficiency. BMP facilitates the 105 monitoring of BGP running status and reports security threats in real 106 time so that preventive measures can be taken promptly. 108 In order to monitor and manage effectively the operating states of 109 the BGP configured on the respective network devices in the network, 110 the existing practice is that a monitoring station obtains BGP 111 information of the respective network devices in the network to 112 monitor and manage centrally the network devices configured with the 113 BGP in the network. By way of an example of a flow in which the 114 monitoring station obtains the BGP information, after a BGP 115 connection is set up between network devices A and B configured with 116 the BGP (or between peers), taking the network device A as an 117 example, the network devices A and B negotiate about their own 118 enabled BGP optional capabilities in OPEN messages under a BGP rule, 119 and the network device A further includes a BGP Monitoring Protocol 120 (BMP) module connected with the monitoring station, where the BMP 121 module can obtain the enabled BGP optional capabilities of the 122 network device A, and the enabled BGP capabilities of the network 123 device B as a result of negotiation about the enabled BGP 124 capabilities, so that if the BMP module of the network device A sends 125 the configured BGP information of the network device to the 126 monitoring station in a Peer Up Notification message, then the BGP 127 optional capabilities will include only the BGP capabilities enabled 128 on the network device A. 130 However, sometimes it's not sufficient to report only the 131 capabilities currently enabled at the monitored device to the BMS. 132 In order to better optimize the network, the BMS may want to access 133 all the capabilites that are supported at each monitored devices, as 134 well as the current configuration informations. 136 3. Use cases 138 o BGP Optional Parameters: The Open Message reported to BMS contains 139 only the currently enabled capabilities at the monitored device. 140 If all the supported capabilities of the monitored devices, both 141 the enabled and not yet enabled ones, are informed to the BMS, the 142 BMS can use the more comprehensive and valid inputs to make 143 decisions about the whole network optimization. For example, if 144 the Graceful Restart Capability is not enabled for a BGP Peer, and 145 thus the BGP Open Message (i.e., the Peer Up Notification in BMP) 146 would not include the GR capability. However, if the BMS or the 147 operator has the knowledge that both devices support the GR 148 capability, and enables it at both devices, it could improve the 149 operational stability of the network. 151 o BGP Default Behavior Parameters: As one of the concern from the 152 operators, that in multi-vendor environment, some default 153 configurations or behabiors of devices are vendor-specific, and 154 may cause various issues during the interoperation test or any 155 time after. Take the protocol preferences (distance) of different 156 BGP routes for example: Vendor A assigns value 255 to eBGP, iBGP 157 and BGP local routes by default, while vendor B assigns 20 to 158 eBGP, 200 to iBGP and 200 to BGP local routes by default. In 159 addition, value 255 is not recognized by vendor B, and routes 160 assigned such distance would be ignored. 162 4. Extension of BMP Initiation Message 164 As described in Section 4.3 of [RFC7854], the initiation message 165 provides a means for the monitored router to inform the monitoring 166 station of its vendor, software version, and so on. 168 The initiation message consists of the common BMP header followed by 169 two or more Information TLVs (Section 4.4 of [RFC7854]) containing 170 information about the monitored router. Currently defined types are: 172 Type = 0: String. 174 Type = 1: sysDescr. 176 Type = 2: sysName. 178 This document defines two new catagories of TLV types: the BGP 179 Optional Parameters and the BGP Default Behavior Parameters. 181 Type = TBD1: BGP Optional Parameters. The Information field is used 182 to specify all the BGP Optional Parameters that have been enabled or 183 not yet enabled at the monitored device. Each optional parameter is 184 encoded as a 185 triplet, as defined in RFC 4271 [RFC4271] . 187 0 1 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 190 | Parm. Type | Parm. Length | Parameter Value (variable) 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 193 Figure 1 BGP Optional Parameters Information TLV 195 Parameter Type is a one octet field that unambiguously identifies 196 individual parameters. Parameter Length is a one octet field that 197 contains the length of the Parameter Value field in octets. 198 Parameter Value is a variable length field that is interpreted 199 according to the value of the Parameter Type field. RFC 5492 200 [RFC5492] defines the Capabilities Optional Parameter. 202 Type = TBD2: Default Behavior Parameters. The Information field 203 contains a list of default behavior parameters, in which each 204 parameter is encoded as a Default Behavior sub TLV , which is 206 defined as follows 208 0 1 2 3 209 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 210 +-------------------------------+-------------------------------+ 211 | Default Beh. Type | Def Beh. Length | 212 +-------------------------------+-------------------------------+ 213 + Default Beh. Value (variable) + 214 ~ ~ 215 +---------------------------------------------------------------+ 217 Figure 2 Default Behavior sub TLV 219 The Default Behavior Type is a one octet field that identifies the 220 defualt behavior type parameter. Parameter Length is a one octet 221 field that contains the length of the Parameter Value field in 222 octets. Parameter Value is a variable length field that is 223 interpreted according to the value of the Parameter Type field: 225 o Type = TBD3, (32-bit integer ) Value of default Protocol 226 Preference for Local route 228 o Type = TBD4, (32-bit integer ) Value of default Protocol 229 Preference for EBGP route 231 o Type = TBD5, (32-bit integer ) Value of default Protocol 232 Preference for IBGP route 234 o Type = TBD6, (32-bit integer ) Value of default BGP connect-retry 235 timer time 237 o Type = TBD7, (32-bit integer ) Value of default BGP Keepalive time 239 o Type = TBD8, (32-bit integer ) Value of default BGP hold time 241 o Type = TBD9, (32-bit integer ) Value of EBGP route-update-interval 243 o Type = TBD10, (32-bit integer ) Value of IBGP route-update- 244 interval 246 o Type = TBD11, (32-bit integer ) Value of Default local-preference 248 o Type = TBD12, (32-bit integer ) Value of Default MED 250 5. Acknowledgements 252 TBD. 254 6. IANA Considerations 256 TBD. 258 7. Security Considerations 260 TBD. 262 8. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 270 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 271 DOI 10.17487/RFC4271, January 2006, 272 . 274 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 275 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 276 2009, . 278 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 279 Monitoring Protocol (BMP)", RFC 7854, 280 DOI 10.17487/RFC7854, June 2016, 281 . 283 Authors' Addresses 285 Shunwan Zhuang 286 Huawei 287 Huawei Bld., No.156 Beiqing Rd. 288 Beijing 100095 289 China 291 Email: zhuangshunwan@huawei.com 293 Yunan Gu 294 Huawei 295 Huawei Bld., No.156 Beiqing Rd. 296 Beijing 100095 297 China 299 Email: guyunan@huawei.com 301 Zhenbin Li 302 Huawei 303 Huawei Bld., No.156 Beiqing Rd. 304 Beijing 100095 305 China 307 Email: lizhenbin@huawei.com