idnits 2.17.1 draft-fan-bess-pm-bgp-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 ([I-D.dong-l3vpn-pm-framework]), 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 date (December 28, 2016) is 2675 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) == Missing Reference: 'RFC4026' is mentioned on line 104, but not defined ** Downref: Normative reference to an Informational draft: draft-dong-l3vpn-pm-framework (ref. 'I-D.dong-l3vpn-pm-framework') Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Fan 3 Internet-Draft Z. Li 4 Intended status: Standards Track S. Zhuang 5 Expires: July 1, 2017 Huawei 6 December 28, 2016 8 BGP Extension For L3VPN Performance Monitoring 9 draft-fan-bess-pm-bgp-00 11 Abstract 13 This document describes a new VT address family in BGP to exchange 14 information required for apply performance monitoring in MPLS/BGP 15 VPN, as described in [I-D.dong-l3vpn-pm-framework]. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 1, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The New VT Sub Address Family . . . . . . . . . . . . . . . . 3 60 3.1. VT Sub Address Family . . . . . . . . . . . . . . . . . . 3 61 3.2. VT NLRI . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2.1. VT VPN-membership A-D Route . . . . . . . . . . . . . 5 63 3.2.2. VT Labeled Route . . . . . . . . . . . . . . . . . . 5 64 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. VRF-to-VRF VPN Membership Auto Discovery . . . . . . . . 6 66 4.2. VRF-to-VRF Labeled Route Exchange . . . . . . . . . . . . 7 67 4.2.1. VT Labeled Route Update . . . . . . . . . . . . . . . 7 68 4.2.2. VT Labeled Route Withdrawal . . . . . . . . . . . . . 7 69 4.3. VRF-to-VRF Labeled Route Application . . . . . . . . . . 8 70 5. VT Route Selection Consideration . . . . . . . . . . . . . . 8 71 6. Deployment Consideration . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 This document describes the BGP encodings and procedures for 83 exchanging the information elements required by applying traffic 84 performance monitoring in MPLS/BGP VPN, as specified 85 in[I-D.dong-l3vpn-pm-framework]. 87 Current BGP Labeled VPN Route exchange procedure combines VRF VPN- 88 membership Auto-Discovery and L3VPN Label allocation together. While 89 applying PM for L3VPN needs BGP extended to support VPN membership 90 Auto-Discovery and L3VPN Label allocation in a VRF-to-VRF manner. To 91 achieve this, a new Sub address family, called VRF-to-VRF Tunnel(VT) 92 Subsequent Address Family, is introduced. 94 This document defines two kinds of routes for VT NLRI: 96 VPN-Membership A-D Route: for the use of doing VRF VPN membership 97 auto-discovery in VRF-to-VRF manner 99 VT Labeled Route: for the use of allocating VT Label from Local VRF 100 to Remote VRF to setup VRF-to-VRF Tunnel between the pair of VRFs. 102 2. Terminologies 104 This document uses the terminologies defined in [RFC4026]: 106 o ERT: Export Route Target 108 o IRT: Import Route Target 110 o PE: Provider Edge 112 o RD: Route Distinguisher 114 o VRF: Virtual Routing and Forwarding 116 o VT: VRF-to-VRF Tunnel 118 3. The New VT Sub Address Family 120 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 121 from multiple "address families". In this document a new Subsequent 122 Address Family is introduced, called "VT Sub Address Family". 124 3.1. VT Sub Address Family 126 VT Address Family uses AFI 1/2 to present IPv4/IPv6 Address Family 127 and a specific VT_SAFI(TBD) to present VT Subsequent Address Family. 129 VT MP_REACH_NLRI and MP_UNREACH_NLRI are formatted as described in 130 [RFC4760] 131 +---------------------------------------------------+ 132 | Address Family Identifier (2 octets): 1/2 | 133 +---------------------------------------------------+ 134 | Subsequent AFI (1 octet): VT_SAFI (TBD) | 135 +---------------------------------------------------+ 136 | Length of Next Hop (1 octet): 4 | 137 +---------------------------------------------------+ 138 | Next Hop: IPv4 Address | 139 +---------------------------------------------------+ 140 | Reserved (1 octet) | 141 +---------------------------------------------------+ 142 | BGP VT NLRI (Variable) | 143 +---------------------------------------------------+ 144 Figure 1 VT MP_REACH_NLRI 145 +---------------------------------------------------+ 146 | Address Family Identifier (2 octets): 1/2 | 147 +---------------------------------------------------+ 148 | Subsequent AFI (1 octet): VT_SAFI (TBD) | 149 +---------------------------------------------------+ 150 | BGP VT NLRI (Variable) | 151 +---------------------------------------------------+ 152 Figure 2 VT MP_UNREACH_NLRI 154 3.2. VT NLRI 156 BGP VT NLRI has format as depicted in following diagram: 158 +---------------------------------------------------+ 159 | Route Type (1 octet) | 160 +---------------------------------------------------+ 161 | Length (1 octet) | 162 +---------------------------------------------------+ 163 | Route Type Specific (Variable) | 164 +---------------------------------------------------+ 165 Figure 3 IPv4 VT-Family NLRI 167 Route Type indicates type of route under VT SAFI. 169 Type 1: VT VPN membership A-D Route 171 Type 2: VT Labeled Route 173 Length defines Route Type specific routes length in octets 175 Route Type specific route information field, encoded according to 176 Route Type definition. 178 3.2.1. VT VPN-membership A-D Route 180 VT VPN membership A-D Route, concisely named as VT A-D Route 181 hereafter, is utilized for VRF-to-VRF VPN Membership Auto-Discovery 182 between PEs. 184 Its format is defined as following diagram: 186 +--------------------------------------------------+ 187 | RD (8 octets) | 188 +--------------------------------------------------+ 189 | Local Router's IP Address | 190 +--------------------------------------------------+ 191 Figure 4 VT VPN Membership A-D Route 193 a) RD: RD of one VRF on advertising PE, encoded as described in 194 [RFC4364]. 196 b) Local Router's IP Address: Advertising PE's IPv4/IPv6 address is defined as Prefix of VT A-D Route. 199 3.2.2. VT Labeled Route 201 VT Labeled Route is utilized for VRF-To-VRF Label(s) allocation and 202 advertisement, its format is defined as following diagram. 204 +---------------------------------------------------+ 205 | Local RD (8 octets) | 206 +---------------------------------------------------+ 207 | Local Router's IP Address | 208 +---------------------------------------------------+ 209 | Remote VRF's RD (8 octets) | 210 +---------------------------------------------------+ 211 | Remote Router's IP Address | 212 +---------------------------------------------------+ 213 | Label (3 octets) | 214 +---------------------------------------------------+ 215 Figure 5 VT Labeled Route Format 217 a) Local RD: Route Distinguisher value of one VRF on advertising PE, 218 encoded as described in [RFC4364]. 220 b) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. 222 c) Remote VRF's RD: Route Distinguisher value of Remote VRF encoded 223 as described in [RFC4364]. 225 d) Remote Router's IP Address: Remote PE's IPv4/IPv6 address. 227 e) Label: The Label field carries one or more labels that corresponds 228 to the stack of labels [RFC3032]. Each label is encoded as 3 octets, 229 where the high-order 20 bits contain the label value, and the low- 230 order bit contains "Bottom of Stack" as defined in [RFC3032]. 232 which indicates a pair of VRFs is defined as the 234 Prefix of VT Labeled Route. 236 4. Operations 238 4.1. VRF-to-VRF VPN Membership Auto Discovery 240 For every PE, it needs to process all its VRF configured and generate 241 one VT A-D Route for each VRF respectively. 243 RD field MUST be filled with the VRF's RD value. 245 Local Router's IP Address field MUST filled with the Advertising 246 Router's IP address. 248 The VT A-D Route MUST carry all IRTs of the VRF in BGP Update's Ext- 249 Community Path Attribute, route importing request of one VRF is 250 described by its corresponding VT A-D route. In contrast VPN Labeled 251 Routes carry ERTs in BGP Update's Ext-Community Path Attribute. 253 If a VRF is created, then its corresponding VT A-D Route MUST be 254 generated and advertised. 256 If the VRF whose VT A-D Route has been advertised is deleted, then 257 the VT A-D Route Withdrawal message MUST be generated and advertised. 259 If IRT of the VRF whose VT A-D Route has been advertised is changed, 260 then a VT A-D Route Update with same Prefix and latest IRTs MUST be 261 advertised. 263 When receiving PE receives VT A-D Route, VPN relationship matching 264 MUST be checked between IRTs in VT A-D Route and ERTs of each Local 265 VRF, this process is called VRF-to-VRF VPN membership Auto Discovery. 267 Either finding one VRF-to-VRF VPN membership newly formed or 268 released, receiving PE MUST proceed to the VT Labeled Route 269 processing described in next section. 271 4.2. VRF-to-VRF Labeled Route Exchange 273 4.2.1. VT Labeled Route Update 275 If Receiving PE finds one new VRF-to-VRF VPN membership formed, it 276 MUST allocate one VT MPLS Label for the VRF-to-VRF VPN membership and 277 the label is advertised to the Remote VRF by VT Labeled Route. 279 Local RD MUST filled with RD value of the Local VRF which is found 280 belong to the same VPN with Remote VRF. 282 Local Router's IP Address Must filled with the advertising PE's IPv4/ 283 IPv6 address. 285 Remote VRF's RD MUST filled with RD value of the Remote VRF which 286 belongs to a same VPN with the Local VRF. 288 Remote Router's IP Address: Remote PE's IPv4/IPv6 address. 290 Label: MUST be filled with one or more MPLS Labels allocated by 291 advertising PE for the pair of VRFs. 293 Only both sides of a pair of VRFs learnt each other's VT Labeled 294 Route advertisement, the VRF-to-VRF tunnel between the pair of VRFs 295 is considered setup. 297 4.2.2. VT Labeled Route Withdrawal 299 If receiving PE finds one existing VRF-to-VRF VPN membership released 300 then it MUST send out the VT Labeled Route Withdrawal message, then 301 release the MPLS Label(s) allocated. 303 Local RD MUST be filled with RD value of the Local VRF. 305 Local Router's IP Address MUST be filled with the advertising PE's 306 IPv4/IPv6 address. 308 Remote VRF's RD MUST be filled with RD value of the Remote VRF. 310 Remote Router's IP Address: MUST be filled with Remote PE's IPv4/IPv6 311 address. 313 Label: MUST be filled with ZERO or the MPLS Labels value allocated 314 for the VT Labeled Route. 316 4.3. VRF-to-VRF Labeled Route Application 318 To achieve the goal of converting normal L3VPN MP2P forwarding model 319 into P2P model which is required in [I-D.zheng-l3vpn-pm-analysis], 320 after VPNv4 routes received, Receiving PE MUST apply VT Labels when 321 downloading VPNv4 Route into Data Plan which is in detail described 322 in [I-D.dong-l3vpn-pm-framework]. 324 Between a pair of PEs both support VT capability, It COULD be an 325 implementation option that VPNv4 Routes from a remote VRF WOULD NOT 326 be downloaded into a Local VRF's Forwarding Plan until a VT Labeled 327 route received from same Remote VRF for the Local VRF. 329 If VT Labeled Route withdrawal message is received, receiving PE MUST 330 delete VT Labels from Forwarding Plane and VPNv4 Routes MUST be kept 331 on Forwarding Plane with original VPNv4 Label as inner Label. 333 5. VT Route Selection Consideration 335 When receiving and processing VT A-D Route, the BGP best route 336 selection procedure described in [RFC4271] MUST be followed. 338 When receiving and processing VT Labeled Route, the BGP best route 339 selection procedure described in [RFC4271] COULD be followed. 341 Especially VT Labeled Route MUST be advertised ONLY to the BGP peer 342 from which the best VT A-D route is received, the VT A-D route 343 contains the Remote VRF's RD and Remote PE's IP address. 345 If a Peer receives VT A-D or VT Labeled Route originated from itself, 346 the route MUST be ignored. 348 6. Deployment Consideration 350 This document currently supports deploying VT SAFI in following two 351 manners: 353 a) Inner-AS L3VPN with Full-mesh IBGP sessions or Router Reflectors. 355 b)Inter-AS L3VPN with Option A(VRF-to-VRF)[RFC4364]. 357 How to support Inter-AS L3VPN Option B(MP-EBGP) and Option-C 358 [RFC4364] will be described in this draft's future version. 360 7. IANA Considerations 362 A new SAFI value to present VT Subsequent Address Family is required 363 and to be allocated by IANA. 365 8. Security Considerations 367 This extension to BGP does not change the underlying security issues. 369 9. Acknowledgements 371 TBD. 373 10. References 375 10.1. Normative References 377 [I-D.dong-l3vpn-pm-framework] 378 Dong, J., Li, Z., and B. Parise, "A Framework for L3VPN 379 Performance Monitoring", draft-dong-l3vpn-pm-framework-03 380 (work in progress), October 2014. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 388 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 389 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 390 . 392 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 393 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 394 DOI 10.17487/RFC4271, January 2006, 395 . 397 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 398 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 399 2006, . 401 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 402 "Multiprotocol Extensions for BGP-4", RFC 4760, 403 DOI 10.17487/RFC4760, January 2007, 404 . 406 10.2. Informative References 408 [I-D.zheng-l3vpn-pm-analysis] 409 Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance 410 Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm- 411 analysis-03 (work in progress), July 2014. 413 Authors' Addresses 415 Jiajia Fan 416 Huawei 417 Huawei Bld., No.156 Beiqing Rd. 418 Beijing 100095 419 China 421 Email: fanjiajia@huawei.com 423 Zhenbin Li 424 Huawei 425 Huawei Bld., No.156 Beiqing Rd. 426 Beijing 100095 427 China 429 Email: lizhenbin@huawei.com 431 Shunwan Zhuang 432 Huawei 433 Huawei Bld., No.156 Beiqing Rd. 434 Beijing 100095 435 China 437 Email: zhuangshunwan@huawei.com