idnits 2.17.1 draft-gu-grow-bmp-vpn-label-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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 2123 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gu 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Chen 5 Expires: January 3, 2019 Tencent 6 P. Mi 7 S. Zhuang 8 Z. Li 9 Huawei 10 July 02, 2018 12 VPN Label Monitoring Using BMP 13 draft-gu-grow-bmp-vpn-label-00 15 Abstract 17 The BGP Monitoring Protocol (BMP) is designed to monitor BGP running 18 status, such as BGP peer relationship establishment and termination 19 and route updates. This document provides a method of collecting the 20 VPN label using BMP, as well as an implementation example. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Extension of BMP Peer Up Message . . . . . . . . . . . . . . 4 64 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The Border Gateway Protocol (BGP) [RFC4271], as an inter-Autonomous 74 (AS) routing protocol, is used to exchange network reachability 75 information between BGP systems. Later on, [RFC4760] extends BGP to 76 carry not only the routing information for BGP, but also for multiple 77 Network Layer protocols (e.g., IPv6, Multicast, etc.), known as the 78 MP-BGP (Multiprotocol BGP). The MP-BGP is currently widely deployed 79 in case of MPLS L3VPN, to exchange VPN labels learned for the routes 80 from the customer sites over the MPLS network. 82 The BGP Monitoring Protocol (BMP) [RFC7854] has been proposed around 83 2006 to monitor the BGP routing information, which includes the 84 monitoring of BGP peer status, BGP route update, and BGP route 85 statistics. BMP is realized through setting up the TCP session 86 between the monitored BGP device and the BMP monitoring station, and 87 then periodic/event-triggerred messages are sent unidirectionaly from 88 the monitored device to the BMP monitoring station. Before BMP was 89 introduced, such information could be only obtained through manual 90 query, such as screen scraping. The introduction of BMP greatly 91 improves the BGP routing monitoring efficiency without interrupting 92 or interfering the ongoing services. 94 Currently, BMP is mainly utilized to monitor the public BGP routes. 95 There are also cases that the VPN (Virtual Private Network) route/ 96 label information is needed. For example, for the purpose of Traffic 97 Engineering (TE), the network operator may insert explicit routes, 98 subject to certain constraints or optimization ceriteria, into 99 related routers with high local preferences so that these routes will 100 be selected and installed into the routing table. Under the VPN 101 environment, the VPN route labels should be collected from the 102 devices, and be distributed back jointly with the explicit routes to 103 the devices, so that the devices can use the VPN labels to correlate 104 the received routes with the approriate VRFs (VPN Routing and 105 Forwarding tables). The collection and distribution of such labels 106 could be done by an SDN (Software Defined Network) controller, or an 107 route monitoring station equipped with the traffic optimization 108 module. 110 The VPN routes between CE (Customer Edge) and PE (Provider Edge) can 111 be monitored by BMP using the "RD Instance Peer Type". However, such 112 VPN routes between CE and PE do not include the VPN labels, since 113 labels are allocated at the PE side. On the other hand, the labeled 114 VPN routes are exchanged beween PE and PE, which could have been 115 monitored by BMP but are currently not implemented due to the massive 116 data exchange between the monitored devices and the BMP monitoring 117 station. An existing method to collect the VPN route label, 118 considering the L3VPN scenario, is by setting up BGP VPNv4 peering 119 relationship between the monitored device and the monitoring station/ 120 controller. The label information is then extracted from the 121 collected VPN-IPv4 routes, carried by the BGP NLRI (Network Layer 122 Reachability Information). However, there are several shortcomings 123 of collecting the VPN label using this method. 125 o The VPN labels, instead of the VPNv4 routes, are the necessary 126 information for fulfilling the traffic optimization purpose. 127 Thus, extracting the label from the VPNv4 route requires extra 128 work compared with directly collecting the label information 129 alone. 131 o The same VPN label is sometims used for several VPNv4 routes. 132 Depending on the implementation scenarios, there are typically 133 different ways of allocating the VPN route labels: per route per 134 label, per VRF per label, per interface per label, and so on. For 135 example, in the Multi-AS VPN case, the redistribution of labeled 136 VPN-IPv4 routes from one AS to another can be realized through 137 setting up the EBGP peering between ASBRs (Autonomous System 138 Border Routers) of different ASes. In this case, the per route 139 per label allocation method is preferred. However, per route per 140 label allocation can be very consuming as for the label space, 141 thus, in many cases the per VRF per label allocation is adopted. 143 As a result, repeatedly reporting the same label for several 144 routes wastes network resources. 146 o The VPN label changes are typically less dynamic compared with the 147 time-varying VPNv4 routes. Thus, acquiring the label information 148 through the real-time monitoring of VPNv4 routes is not quite 149 necessary. 151 All in all, it's more efficient to collect the VPN label 152 independently than extracting it from the collected VPNv4 routes. In 153 this document, we propose a method to utilize BMP to monitor the VPN 154 label. In Section 2, the VPN label is defined to be encapsulated in 155 the BMP Peer Up Notification message, and in Section 3, a specific 156 implementation example is provided to show case the usage of the 157 collected VPN label. 159 2. Extension of BMP Peer Up Message 161 The Peer Up message of BMP, defined in [RFC7854], is used to indicate 162 the come-up of a peering session. The VPN route label can be carried 163 in the Peer Up message and reported to the BMP monitoring station in 164 the TLV format. The Information TLV defined in [RFC7854] can be used 165 to encode the label, and new Information Types are defined. Each 166 Information TLV contains at most one label, and one or more 167 Information TLVs can be included in the Peer Up Notification when 168 necessary. 170 0 1 2 3 171 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 172 +-------------------------------+-------------------------------+ 173 | Information Type | Information Length | 174 +-------------------------------+-------------------------------+ 175 + Information (variable) + 176 ~ ~ 177 +---------------------------------------------------------------+ 179 o Information Type (2 bytes): indicates the type of the Inoformation 180 TLV. Depending on the label allocation method, the following new 181 types are defined: 183 * Type = TBD1: VPN Label, allocated per VRF per label. 185 * Type = TBD2: VPN Label, allocated per interface per label. 187 * Type = TBD3: VPN Label, allocated per route per label. 189 * Type = TBD4: VPN Label, allocated per next hop per label. 191 o Information Length (2 bytes): indicates the length of the 192 following Inforamtion field, in bytes. 194 o Information (variable): specifies the Label information according 195 to the Information Type. 197 * If the Information Type is VPN Label, allocated per VRF per 198 label, the Information field should be the VPN label (20 bits), 199 padded with zeros to 24 bits (3 bytes). The corresponding 200 Length field should be set to 3. 202 * If the Information Type is VPN Label, allocated per interface 203 per label, the Information field should include the VPN label 204 (20 bits label and 4 bits zero padding) and the corresponding 205 interface address, with the total length specified in the 206 Information Length field. One label and one interface address 207 is allowed for each Information TLV. 209 * If the Information Type is VPN Label, allocated per route per 210 label, the Information includes the VPN label (20 bits label 211 and 4 bits zero padding) and the corresponding route prefix, 212 with the total length specified in the Information Length 213 field. The prefix should be in VPNv4 address format. One 214 label and one prefix is allowed for each Information TLV. 216 * If the Information Type is VPN Label, allocated per next hop 217 per label, the Information should include the VPN label (20 218 bits label and 4 bits zero padding) and the corresponding next 219 hop address, with the total length specified in the Information 220 Length field. One label and one next hop address is allowed 221 for each Information TLV. 223 Considering the per VRF per label allocation, instead of extracting 224 this same label information from all the monitored VPNv4 routes, it 225 an be reported only once to save both device and network resources. 226 Similarly, for the per interface per label and per next hop per 227 label, label reporting frequencies can be reduced compared with the 228 VPNv4 routes minotoring. Even for the per route per label case, 229 reporting only the label information can be immune from the update of 230 route changes, and reduce the reported information size. 232 3. Operation 234 In this section, we use an example of traffic optimization 235 applicaiton to more specifically explain how the BMP VPN label 236 collection functions. An Internet content provider (ICP) may own a 237 Backbone network as the DCI (Data Center Interconnection) and 238 Internet access solutions. Such backbone network may implement 239 different VPNs as the bearer networks for different services, and the 240 granularity depends on specific service requirement. Each VPN, 241 piggybacking on the backbone network, may connect to the Internet 242 through other ISPs' (Internet Service Providers') networks. 243 Different Internet Exchange (IX) devices are deployed for the 244 Internet traffic exchange between the ICP and different ISPs. 246 Suppose two ISPs are considered in this example, ISP A and ISP B, as 247 shown in the following figure.The ICP backbone network, implements 248 VPN 1 for a specific service. This VPN exchanges Internet traffic 249 with ISP A and ISP B through IX device A and IX device B, 250 respetively. Prefixes are advertised from ISP A (considered as CE A 251 of VPN 1) and ISP B (CE B) to the IX A (PE A) and IX B (PE B), 252 repectively. Consider the case that ISP B advertises a more specific 253 prefix (20.1.128.0/17) than ISP A (20.1.0.0/16). Both routes would 254 be learnt by the PE devices of VPN 1, and be installed on both PE A's 255 and PE B's routing tables. Now suppose there's a packet with 256 destination 20.1.128.1, then according to the Longest prefix match 257 (LPM) rule, PE B will be used as the ICP's exit for this packet. 258 Similarly, more traffic with such prefixes may choose to exit the ICP 259 to other ISPs through PE B, while PE A is lightly burdened, which 260 leads to unbalanced traffic load and even traffic congestion at PE B. 262 +---------+ +---------------------+ 263 | ISP A | 20.1.0.0/16 +----+ | 264 | | +-------------> |IX A| | 265 +---------+ +-+--+ | 266 | | 267 | ICP VPN 1 | 268 | | 269 | | 270 +---------+ 20.1.128.0/17 +-+--+ | 271 | ISP B | +-------------> |IX B| | 272 | | +----+ | 273 +---------+ +---------------------+ 275 The above mentioned issue can be solved as follows. Through traffic 276 monitoring, the SDN controller can reoptimize the traffic load 277 through explicit routes installation into PE A and PE B. The Next 278 Hop field is indicated explicitly by the controller for the routes 279 that need to be adjusted. For example, for the destination prefix 280 20.1.128.1, its next hop in the explicit route sent to PE A is set to 281 the router's address in ISP A, while the next hop in the explicit 282 route sent to PE B is set to PE A. Simutainiously, BMP is used to 283 collect VPN 1's route labels from PE A (Label: 1000) and PE B (Label: 284 2000). Assume in this example, the labels are allocated per VRF per 285 label, then Label 1000 is the label allocated to PE A for VRF 1, and 286 Label 2000 is the label allocated to PE B for VRF 1. The explicit 287 routes distributed to PE A and PE B are specified in the following 288 figures, respectively. After receiving the explicit route, PE A/B 289 may use the label information to correlate the route to the correct 290 VRF and then install it into VRF 1. Thus, part of the traffic may 291 exit VPN 1 through PE A to balance the traffic load. 293 +-------------------------+-------+-------------+ 294 |Dest. Addr./Mask| NH | Label | Local Pref. | 295 +-----------------------------------------------+ 296 | 20.1.128.0/17 | ISP A | 1000 | 200 | 297 +----------------+--------+-------+-------------- 299 +-------------------------+-------+-------------+ 300 |Dest. Addr./Mask| NH | Label | Local Pref. | 301 +-----------------------------------------------+ 302 | 20.1.128.0/17 | PE A | 1000 | 200 | 303 +----------------+--------+-------+-------------- 305 4. Acknowledgements 307 TBD. 309 5. IANA Considerations 311 TBD. 313 6. Security Considerations 315 TBD. 317 7. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 325 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 326 DOI 10.17487/RFC4271, January 2006, 327 . 329 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 330 "Multiprotocol Extensions for BGP-4", RFC 4760, 331 DOI 10.17487/RFC4760, January 2007, 332 . 334 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 335 Monitoring Protocol (BMP)", RFC 7854, 336 DOI 10.17487/RFC7854, June 2016, 337 . 339 Authors' Addresses 341 Yunan Gu 342 Huawei 343 Huawei Bld., No.156 Beiqing Rd. 344 Beijing 100095 345 China 347 Email: guyunan@huawei.com 349 Jie Chen 350 Tencent 352 Email: jasonjchen@tencent.com 354 Penghui Mi 355 Huawei 356 Shenzhen, Guangdong 357 China 359 Email: mipenghui@huawei.com 361 Shunwan Zhuang 362 Huawei 363 Huawei Bld., No.156 Beiqing Rd. 364 Beijing 100095 365 China 367 Email: zhuangshunwan@huawei.com 369 Zhenbin Li 370 Huawei 371 Huawei Bld., No.156 Beiqing Rd. 372 Beijing 100095 373 China 375 Email: lizhenbin@huawei.com