idnits 2.17.1 draft-gu-grow-bmp-vpn-te-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 30 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1865 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) == Outdated reference: A later version (-07) exists of draft-ietf-grow-bmp-adj-rib-out-03 == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-02 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 12, 2019 Tencent 6 P. Mi 7 S. Zhuang 8 Z. Li 9 Huawei 10 March 11, 2019 12 VPN Traffic Engineering Using BMP 13 draft-gu-grow-bmp-vpn-te-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 traffic engineering (TE) 20 method in the VPN (Virtual Private Network) scenario using 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 September 12, 2019. 45 Copyright Notice 47 Copyright (c) 2019 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. VPN TE Using BMP . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Label Message . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Implementation Examples . . . . . . . . . . . . . . . . . . . 6 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The Border Gateway Protocol (BGP) [RFC4271], as an inter-Autonomous 77 (AS) routing protocol, is used to exchange network reachability 78 information between BGP systems. Later on, RFC4760 [RFC4760] extends 79 BGP to carry not only the routing information for BGP, but also for 80 multiple Network Layer protocols (e.g., IPv6, Multicast, etc.), known 81 as the MP-BGP (Multiprotocol BGP). The MP-BGP is currently widely 82 deployed in case of MPLS L3VPN, to exchange VPN labels learned for 83 the routes from the customer sites over the MPLS network. BGP routes 84 are needed for both intra-domain and inter-domain route optimization. 85 Before BGP Monitoring Protocol (BMP) [RFC7854] was introduced, BGP 86 routes could be only obtained through manual query, such as screen 87 scraping. The introduction of BMP greatly improves the BGP route 88 monitoring efficiency and accuracy.Currently, it provides the 89 monitoring of BGP adj-rib-in [RFC7854], BGP local-rib 90 [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out 91 [I-D.ietf-grow-bmp-adj-rib-out]. 93 In the MPLS (Multiprotocol Label Switching) VPN traffic egnieering 94 scenario, the controller distributes optimized route entries with 95 MPLS VPN labels (inner labels) to the target devices. The target 96 devices use the inner MPLS VPN labels to find the corresponding VRF 97 (Virtual routing and forwarding) instance, and then add the optimized 98 route entries into the target VRF table. Techically, it's workable 99 to extract the labels from VPNv4 routes by monitoring the VPNv4 100 routes exchanged between two PE (provider edge) devices, i.e., by 101 monitoring the adj-rib-out of and adj-rib-in of both PEs. However, 102 unlike the public BGP routes and IGP routes, VPNv4 routes are not 103 usually used for either the inter-domain or intra-domain traffic 104 optmization. Thus, it's not very cost efficient, from the 105 perspective of CPU and network bandwidth consumption, to monitor the 106 VPNv4 routes only for the purpose of label extraction. 108 Depending on the implementation scenarios, there are typically 109 different ways of allocating the VPN route labels: per route per 110 label, per VRF per label, per next hop per label, and so on. For 111 example, in the Multi-AS VPN case, the redistribution of labeled 112 VPNv4 routes from one AS to another can be realized through setting 113 up the EBGP peering between ASBRs (Autonomous System Border Routers). 114 In this case, the per route per label allocation method is preferred. 115 However, per route per label allocation can be very consuming as for 116 the label space, thus, in many cases the per VRF/next hop per label 117 assignment modes are adopted. 119 This document descrbes a method using BMP to collect the MPLS VPN 120 label information. A new BMP message type is proposed to carry the 121 label information. More specifically, in the per route per label 122 case, the VRF nformation, route prefix and label are included in the 123 newly defined BMP Label Message. In the per instance per label case, 124 the VRF information and label are included in the newly defined BMP 125 Label Message, while in the per next hop per label case, the VRF 126 information, next hop and label are included in the newly defined BMP 127 Label Message. The report of BMP Label Message is triggered by the 128 label assignment chnage. 130 There are several merits of using the BMP Label Message type to 131 collect the MPLS VPN labels compared with extracting labels from the 132 monitored VPNv4 routes: 134 o It saves work of extracting the label information from the VPNv4 135 routes, and saves network bandwidth considering that VPNv4 routes 136 includes all route attributes that are not necessary in this case. 138 o In the per instance/next hop per label assignment cases, the same 139 VPN label is used for multiple VPNv4 routes. The BMP Label 140 Message only report the label information once (if no change), and 141 thus saves network resources compared with the repeated label 142 report by monitoring VPNv4 routes. 144 o The label assignments are typically less dynamic compared with the 145 VPNv4 routes. Thus, acquiring the label information through the 146 real-time monitoring of VPNv4 routes is not quite necessary. 148 All in all, it's more efficient to collect the MPLS VPN label 149 independently than extracting it from VPNv4 routes. In Section 2, 150 the BMP Label Message format is defined, and in Section 3, two 151 specific implementation examples are provided to show case the usage 152 of BMP Label Message. 154 2. VPN TE Using BMP 156 This document defines a new BMP message type called the Label Message 157 to carry the VPN label. 159 2.1. Common Header 161 This document defines a new BMP message type to carry the VPN label 162 data. 164 o Type = TBD: Label Message 166 The new defined message type is indicated in the Message Type field 167 of the BMP common header. 169 2.2. Per Peer Header 171 The Label Message is not per peer based, thus it does not require the 172 Per Peer Header. 174 2.3. Label Message 176 +--------------------------------+------------------------------+ 177 | Label Assignment Mode | Reserved | 178 +--------------------------------+------------------------------+ 179 | Label Mapping Information | 180 +---------------------------------------------------------------+ 181 | Label | 182 +---------------------------------------------------------------+ 184 Figure 1: BMP Label Message 186 o Label Assignment Mode (4 Bits): indicates how label is assigned. 187 Curerntly, 3 types of label assignment mode are defined: "0000" 188 indicating the per instance per label assignment mode, "0001" 189 indicating the per next hop per label assignment mode, "0010" 190 indicating the per instance per label assignment mode. More modes 191 can be defined per requirement. 193 o Reserved (1 Byte): reserved for future use. 195 o Label Mapping Information (Variable): is interpreted in 196 combination with the Label Assignment Mode field. If the Label 197 Assignment Mode field is set to "0000", meaning per instance per 198 label assignment mode, then this field is set to VRF Route 199 Distinguisher; If the Label Assignment Mode field is set to 200 "0001", meaning per next hop per label assignment mode, then this 201 field is set to the next hop address; If the Label Assignment Mode 202 field is set to "0010", meaning per route per label assignment 203 mode, then this field is set to the route prefix. 205 o Label (3 Bytes): indicates the label value with 20 bits label and 206 4 bits zero padding. 208 More specifically, the Label Mapping Information field is defined as 209 follows. Regarding different values indicated in the Label 210 Assignment Mode field, 212 +---------------------------------------------------------------+ 213 | Length | 214 +---------------------------------------------------------------+ 215 | VRF RD | 216 +---------------------------------------------------------------+ 217 | Next Hop/Prefix | 218 +---------------------------------------------------------------+ 220 Figure 2: Label Mapping Information 222 o Length (2 Bytes): indicates the length of the following Label 223 Mapping Information value fields. The Length field value SHALL be 224 set in accordance with the Label Assignment Mode field. If the 225 Label Assignment Mode is set to "0000", the Length field is set to 226 the length of the VRF RD field (i.e., 8 Bytes); If the Label 227 Assignment Mode is set to "0001", the Length field is set to the 228 length of the VRF RD field (8 Bytes) + the length of the Next Hop 229 field (variable); If the Label Assignment Mode is set to "0010", 230 the Length field is set to the length of the VRF RD field (8 231 Bytes) + the length of the Prefix field (variable). 233 o VRF RD (8 Bytes): indicates the route distinguisher (RD) of the 234 VRF. In either the "per instance per label" case, or "per next 235 hop per label" case, or "per route per label" case, the VRF 236 information (i.e., RD) SHALL be indicated in this field. 238 o Next Hop/Prefix (Variable): is interpreted in combination with the 239 Label Assignment Mode field and the Length field. If the Label 240 Assignment Mode is set to "0000", this field SHALL be set empty; 241 If the Label Assignment Mode is set to "0001", this field SHALL be 242 set to the next hop address (i.e., the CE's address), with length 243 indicated by the Length field (i.e., Length value - 8 Bytes); If 244 the Label Assignment Mode is set to "0010", this field SHALL be 245 set to the prefix of the route, with length indicated by the 246 Length field (i.e., Length value - 8 Bytes) 248 3. Implementation Examples 250 In this section, we use two examples to more specifically explain how 251 to use BMP for VPN traffic engineering. 253 +-------------+ 254 Option 1: | BMP server | Option2: 255 10.2.1.0/24 +------+ + +---------+10.2.1.0/24 256 NH:CE1 | | Controller | |NH:PE1 257 Label:100 | +-+----------++ |Label:100 258 10.2.0.0/24 | VRF1 ^ ^VRF1 | | 259 10.1.0.0/24 10.1.1.0/24 | R1:100| |R1:500 | |10.1.1.0/24 260 +++ NH:PE2 | R2:200| |R2:600 | |NH:PE2 261 | Label:600 | R3:300| |R3:700 | |Label:600 262 | | R4:400| |R4:800 | | 263 | | ******|**|*******|******** | 264 +----+---+ R1:10.2.0.0/16 v * | | + AS0 * | 265 | CE1 | R2:10.1.0.0/16 ++-----+ | | Option 1: * | 266 | (ISP1 +--------------->+ PE1 +--+ | 10.2.1.0/24 * | 267 | AS1) +------------| | VRF1 | | NH:PE1 * | 268 +--------+ R1,R2 +----->+ | | Label:100 * | 269 R3:10.2.0.0/17 | | +------+ | 10.1.1.0/24 * v 270 R4:10.1.0.0/17 | | * | NH:CE1 +-----++ +---+ 271 + | | * | Label:600 | PE3 +---+AS4| 272 v | | * | + | VRF1 | +---+ 273 +----+---+ R3,R4 | | +------+-----+ | | | 274 | CE2 +---------+ +-->+ PE2 | | +------+ 275 | (ISP2 | | VRF1 +<------------+ * 276 | AS2) +--------------->+ | * 277 +--------+ R3,R4 +------+ * 278 ************************** 280 Figure 3: VPN TE using BMP example: per route per label 282 Two prefixes 10.2.0.0/24 and 10.1.0.0/24 are generated from ISP1 283 (AS1), advertised to ISP 2 (AS2) in the format of R3: 10.2.0.0/17, 284 and R4: 10.1.0.0/17, and also advertised to AS0 in the format of R1: 286 10.2.0.0/16, and R2: 10.1.0.0/16. R1, R2 are advertised to both PE1 287 and PE2 in AS0, and so are R3 and R4. By the rule of the longest 288 prefix match, any traffic, with the destination address within the 289 subnets of 10.2.0.0/16 or 10.1.0.0/16, coming from AS4 that traverses 290 AS0 will exit from PE2. This may cause unbalanced traffic loads on 291 PE2 and PE1. In addition, the costs of traversing through AS1 and 292 AS2 might be different due to business contracts assigned between 293 different ISPs. Now suppose for traffic and cost optimization 294 purposes, the operator wants to: 1) steer the traffic, with the 295 destination address within the subnets of 10.2.0.0/16, to exit from 296 PE1 and then traverse AS1 (ISP1) to its destination; 2) steer the 297 traffic, with the destination address within the subnets of 298 10.1.0.0/16, to exit from PE2 and then traverse AS1 (ISP1) to its 299 destination. 301 In the example shown in Figure 2, the VPN label assignement mode is 302 per route per label. Thus, PE1 assigns R1, R2, R3, R4 with label 303 100, 200, 300, 400, respectively, under VRF1. PE2 assigns R1, R2, 304 R3, R4 with label 600, 700, 800, 900, respectively, under VRF1. 305 Using the BMP Label Message, PE1 and PE2 reports to the BMP server 306 with the per-route labels, which also includes the VRF RD 307 information. Then the TE controller (suppose it's colocated with the 308 BMP server) combines the label information with routes, and 309 distribute the optimized routes with label to either the ingress or 310 egress devices. There are typically two options: 312 o Option 1: The controller distributes the optimized route to the 313 Egress devices, i.e., PE1 and PE2. For optimizing 10.2.0.0/16 314 traffic, controller distributes 10.2.0.0/24 with next hop as CE1, 315 label as 100, RT as 100:1 to PE1, so that when traffic, with the 316 destination address within the subnets of 10.2.0.0/16, arrives at 317 PE1 will exit from PE1 and choose CE1 (ISP1) as its next hop. 318 Controller also distributes 10.2.0.0/24 with next hop as PE1, 319 label as 100, RT as 100:1 to PE1, so that when traffic, with the 320 destination address within the subnets of 10.2.0.0/16, arrives at 321 PE2 will exit from PE1 and choose CE1 (ISP1) as its next hop. For 322 optimizing 10.1.0.0/16 traffic, controller distributes 10.1.0.0/24 323 with next hop as PE2, label as 600, RT as 100:1 to PE1, so that 324 when traffic, with the destination address within the subnets of 325 10.1.0.0/16, arrives at PE1 will exit from PE2 and choose CE1 326 (ISP1) as its next hop. Controller also distributes 10.1.0.0/24 327 with next hop as CE1, label as 600, RT as 100:1 to PE2, so that 328 when traffic, with the destination address within the subnets of 329 10.1.0.0/16, arrives at PE2 will exit from PE2 and choose CE1 330 (ISP1) as its next hop. 332 o Option 2: The controller distributes a more specific route to the 333 Ingress device, i.e., PE3. Controller distributes 10.2.0.0/24 334 with next hop as PE1, label as 100, RT as 100:1 to PE3, so that 335 when traffic, with the destination address within the subnets of 336 10.2.0.0/16, arrives at PE3 will exit from PE1 and choose CE1 337 (ISP1) as its next hop. Controller also distributes 10.1.0.0/24 338 with next hop as PE2, label as 600, RT as 100:1 to PE3, so that 339 when traffic, with the destination address within the subnets of 340 10.2.0.0/16, arrives at PE3 will exit from PE2 and choose CE1 341 (ISP1) as its next hop. 343 +-------------+ 344 Option 1: | BMP server | Option2: 345 10.2.1.0/24 +------+ + +-+ +-----+10.2.1.0/24 346 NH:CE1 | | Controller | |NH:PE1 347 Label:1000 | +-+----------++ |Label:1000 348 | VRF1 ^ ^VRF1 + | 349 10.2.0.0/24 10.1.1.0/24 |CE1:1000| |CE1:3000 |10.1.1.0/24 350 10.1.0.0/24 NH:PE2 |CE2:2000| |CE2:4000 |NH:PE2 351 +++ Label:3000 | | | + |Label:3000 352 | | | | | | 353 | | ******|**|*******|******** | 354 +----+---+ R1:10.2.0.0/16 v * | | + AS0 * | 355 | CE1 | R2:10.1.0.0/16 ++-----+ | | Option 1: * | 356 | (ISP1 +--------------->+ PE1 +--+ | 10.2.1.0/24 * | 357 | AS1) +------------| | VRF1 | | NH:PE1 * | 358 +--------+ R1,R2 +----->+ | | Label:1000 * | 359 R3:10.2.0.0/17 | | +------+ | 10.1.1.0/24 * v 360 R4:10.1.0.0/17 | | * | NH:CE1 +-----++ +---+ 361 | | | * | Label:3000| PE3 +---+AS4| 362 v | | * | + | VRF1 | +---+ 363 +----+---+ R3,R4 | | +------+-----+ | | | 364 | CE2 +---------+ +-->+ PE2 | | +------+ 365 | (ISP2 | | VRF1 +<------------+ * 366 | AS2) +--------------->+ | * 367 +--------+ R3,R4 +------+ * 368 ************************** 370 Figure 4: VPN TE using BMP example: per next hop per label 372 In the example shown in Figure 3, he VPN label assignement mode is 373 per next hop per label. Comparing the two examples in Figure 2 and 374 Figure 3, less label information are reported though BMP if the label 375 is allocated per next hop. 377 4. Acknowledgements 379 TBD. 381 5. IANA Considerations 383 TBD. 385 6. Security Considerations 387 TBD. 389 7. Normative References 391 [I-D.ietf-grow-bmp-adj-rib-out] 392 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 393 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 394 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-03 (work 395 in progress), December 2018. 397 [I-D.ietf-grow-bmp-local-rib] 398 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 399 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 400 draft-ietf-grow-bmp-local-rib-02 (work in progress), 401 September 2018. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 409 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 410 DOI 10.17487/RFC4271, January 2006, 411 . 413 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 414 "Multiprotocol Extensions for BGP-4", RFC 4760, 415 DOI 10.17487/RFC4760, January 2007, 416 . 418 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 419 Monitoring Protocol (BMP)", RFC 7854, 420 DOI 10.17487/RFC7854, June 2016, 421 . 423 Authors' Addresses 424 Yunan Gu 425 Huawei 426 Huawei Bld., No.156 Beiqing Rd. 427 Beijing 100095 428 China 430 Email: guyunan@huawei.com 432 Jie Chen 433 Tencent 435 Email: jasonjchen@tencent.com 437 Penghui Mi 438 Huawei 439 Shenzhen, Guangdong 440 China 442 Email: mipenghui@huawei.com 444 Shunwan Zhuang 445 Huawei 446 Huawei Bld., No.156 Beiqing Rd. 447 Beijing 100095 448 China 450 Email: zhuangshunwan@huawei.com 452 Zhenbin Li 453 Huawei 454 Huawei Bld., No.156 Beiqing Rd. 455 Beijing 100095 456 China 458 Email: lizhenbin@huawei.com