idnits 2.17.1 draft-zhuang-grow-monitoring-bgp-capabilities-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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 Z. Li 4 Intended status: Informational G. Yan 5 Expires: September 14, 2017 Huawei 6 P. Mi 7 W. Guo 8 X. Zheng 9 Tencent 10 March 13, 2017 12 Monitoring BGP Capabilities Using BMP 13 draft-zhuang-grow-monitoring-bgp-capabilities-01 15 Abstract 17 The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor 18 BGP [RFC4271] running status, such as BGP peer relationship 19 establishment and termination and route updates. 21 This document provides a use case that the BMP station can get all 22 BGP capability information of the monitored network device via BMP. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 14, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 3. Virtual Peer . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Terminology 76 This memo makes use of the terms defined in [RFC7854]. 78 Virtual Peer: A virtual BGP speaker connecting to the network device 80 BMP: BGP Monitoring Protocol 82 BMS: BGP Monitoring Station 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 89 capabilities, e.g., IPv4 Unicast, IPv4 Multicast, IPv6 Unicast, and 90 other multiple-protocol extended capabilities, and the different BGP 91 may support a different number of different capabilities. The 92 network device configured with the BGP typically may not enable all 93 capabilities supported in the configured BGP, but enable some 94 currently required BGP capabilities as required for a current task. 96 The BGP Monitoring Protocol (BMP) introduces the availability of 97 monitoring BGP running status, such as BGP peer relationship 98 establishment and termination and route updates. Without BMP, manual 99 query is required if you want to know about BGP running status. With 100 BMP, a router can be connected to a monitoring station and configured 101 to report BGP running statistics to the station for monitoring, which 102 improves the network monitoring efficiency. BMP facilitates the 103 monitoring of BGP running status and reports security threats in real 104 time so that preventive measures can be taken promptly. 106 In order to monitor and manage effectively the operating states of 107 the BGP configured on the respective network devices in the network, 108 the existing practice is that a monitoring station obtains BGP 109 information of the respective network devices in the network to 110 monitor and manage centrally the network devices configured with the 111 BGP in the network. By way of an example of a flow in which the 112 monitoring station obtains the BGP information, after a BGP 113 connection is set up between network devices A and B configured with 114 the BGP (or between peers), taking the network device A as an 115 example, the network devices A and B negotiate about their own 116 enabled BGP capabilities in messages under a BGP rule, and the 117 network device A further includes a BGP Monitoring Protocol (BMP) 118 module connected with the monitoring station, where the BMP module 119 can obtain the enabled BGP capabilities of the network device A, and 120 the enabled BGP capabilities of the network device B as a result of 121 negotiation about the enabled BGP capabilities, so that if the BMP 122 module of the network device A sends the configured BGP information 123 of the network device to the monitoring station in a Peer Up 124 Notification message, then the BGP capabilities will include only the 125 BGP capabilities enabled on the network device A. 127 However it may not suffice if only the deployed or enabled BGP 128 capabilities are sent, but the monitoring station has to obtain all 129 the BGP capabilities supported by the network devices configured with 130 the BGP in the network, including the enabled and disabled BGP 131 capabilities, so that the monitoring station can know comprehensively 132 the real capabilities supported throughout the network, and further 133 provide a valid criterion for deployment and decision throughout the 134 network. 136 This document provides a use case that the BMP station can get all 137 BGP capability information of the monitored network device via BMP. 139 3. Virtual Peer 141 As described in Section 8.2 of [RFC7854], locally originated routes 142 can be modeled as having been sent by the router to itself. This 143 document introduces a virtual BGP speaker for the monitored router 144 that the speaker is connecting to the router. The virtual BGP 145 speaker existing in the router is a virtual Peer to the router. 147 4. Operation 149 Consider the following scenario: 151 A simple topology: 153 BMS---Device A----Device B 155 Configure a BMP session between BMS and Device A, 156 and a BGP session between Device A and B. 158 Suppose that the BGP capabilities supported on the network device A 159 and B include three BGP capabilities, which are IPv4 Unicast, IPv4 160 Multicast, and IPv6 Unicast respectively, and only one of the BGP 161 capabilities is currently enabled on the network device A and B, 162 which is IPv4 Unicast. 164 When the BGP session between Device A and B reaches the Established 165 state, Device A will send a few BMP messages to BMS, one of the 166 messages is a Peer Up Notification message, which includes only IPv4 167 Unicast multiple-protocol extended capabilitiy. In this case, the 168 BMS does not know the other support capabilities, such as IPv4 169 Multicast and IPv6 Unicast. 171 When the network device A is configured to create a virtual peer, the 172 process follows the steps: 174 1) A gets all the BGP capabilities from BGP module. 176 2) A encapsulates a Peer Up Notification message as follows: 178 o Setting Peer Type field of the Per-Peer header to 2 (Local 179 Instance Peer ) 181 o Placing the router's own address in the Peer Address field of the 182 Per-Peer header 184 o Setting the Local Port field to 0 186 o Setting the Remote Port field to 0 188 o Including IPv4 Unicast, IPv4 Multicast, and IPv6 Unicast in the 189 "Received OPEN Message" part 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Local Address (16 bytes) | 195 ~ ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Local Port | Remote Port | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Sent OPEN Message | 200 ~ ~ 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Received OPEN Message | 203 ~ (NULL for Virtual Peer) ~ 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Information (variable) | 206 ~ ~ 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1: Peer Up Notification for Virtual Peer 211 3) Upon reception of the Peer Up Notification message, BMS can 212 indentify the virtual peer identifier of the network device A, 213 thereby gets all the BGP multiple-protocol extended capabilities 214 corresponding to the network device A. 216 Use the method described above, the monitoring station BMS can know 217 comprehensively the real BGP capabilities supported by the monitored 218 device. 220 5. Acknowledgements 222 TBD. 224 6. IANA Considerations 226 TBD. 228 7. Security Considerations 230 TBD. 232 8. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 240 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 241 DOI 10.17487/RFC4271, January 2006, 242 . 244 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 245 Monitoring Protocol (BMP)", RFC 7854, 246 DOI 10.17487/RFC7854, June 2016, 247 . 249 Authors' Addresses 251 Shunwan Zhuang 252 Huawei 253 Huawei Bld., No.156 Beiqing Rd. 254 Beijing 100095 255 China 257 Email: zhuangshunwan@huawei.com 259 Zhenbin Li 260 Huawei 261 Huawei Bld., No.156 Beiqing Rd. 262 Beijing 100095 263 China 265 Email: lizhenbin@huawei.com 267 Gang Yan 268 Huawei 269 Huawei Bld., No.156 Beiqing Rd. 270 Beijing 100095 271 China 273 Email: yangang@huawei.com 275 Penghui Mi 276 Tencent 277 Tengyun Building,Tower A ,No. 397 Tianlin Road 278 Shanghai 200233 279 China 281 Email: kevinmi@tencent.com 282 Wei Guo 283 Tencent 284 Tengyun Building,Tower A ,No. 397 Tianlin Road 285 Shanghai 200233 286 China 288 Email: weissguo@tencent.com 290 Xianyu Zheng 291 Tencent 292 Tengyun Building,Tower A ,No. 397 Tianlin Road 293 Shanghai 200233 294 China 296 Email: zealzheng@tencent.com