idnits 2.17.1 draft-wang-bess-l3-accessible-evpn-04.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 ([RFC7432]), 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 (March 12, 2021) is 1141 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) == Unused Reference: 'I-D.ietf-bess-mvpn-evpn-aggregation-label' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC2890' is defined on line 392, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-05 ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group W. Wang 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: September 13, 2021 H. Wang 6 Huawei Technologies 7 March 12, 2021 9 Layer-3 Accessible EVPN Services 10 draft-wang-bess-l3-accessible-evpn-04 12 Abstract 14 This draft describes layer-3 accessible EVPN service interfaces 15 according to [RFC7432], and proposes a new solution which can 16 simplify the deployment of layer-3 accessible EVPN service. This 17 solution allows each PE in EVPN network to maintain only one IP-VRF. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Service Interfaces in layer-3 accessible EVPN . . . . . . . . 5 57 5. Solutions of LSI-aware bundle service interface . . . . . . . 6 58 6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 59 6.1. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 8 60 6.1.1. Extensions to VxLAN . . . . . . . . . . . . . . . . . 8 61 6.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 [RFC7432]defines three service interfaces for layer-2 accessible 70 EVPN: VLAN-Based Service Interface, VLAN-Bundle Service Interface and 71 VLAN-Aware Bundle Service Interface. These three types of service 72 interfaces can realize the isolation of layer-2 traffic of customers 73 in different ways, as shown in Figure 1. 75 1:1 1:1 76 +------+ +---------+ +------+ 77 |VID 11+---+ EVI 1 +---+VID 12| 78 +------+ +---------+ +------+ 79 |VID 21+---+ EVI 2 +---+VID 22| 80 +------+ +---------+ +------+ 81 |VID 31+---+ EVI 3 +---+VID 32| 82 +------+ +---------+ +------+ 83 |VID 41+---+ EVI 4 +---+VID 42| 84 +------+ +---------+ +------+ 86 VLAN-based Service Interface 88 N:1 1:N 89 +------+ +---------+ +------+ 90 |VID 11---------+ +--------+VID 12| 91 +------+ + + +------+ 92 |VID 21+--------+ +--------+VID 22| 93 +------+ + EVI 1 + +------+ 94 |VID 31+--------+ +--------+VID 32| 95 +------+ + + +------+ 96 |VID 41+--------+ +--------+VID 42| 97 +------+ +---------+ +------+ 99 VLAN-bundle Service Interface 101 N:1 1:N 102 +----------------------+ 103 +------+ |+--------------------+| +------+ 104 |VID 11+--++ Broadcast Domain 1 ++--+VID 12| 105 +------+ |+--------------------+| +------+ 106 |VID 21+--++ Broadcast Domain 2 ++--+VID 22| 107 +------+ |+--------------------+| +------+ 108 |VID 31+--++ Broadcast Domain 3 ++--+VID 32| 109 +------+ |+--------------------+| +------+ 110 |VID 41+--++ Broadcast Domain 4 ++--+VID 42| 111 +------+ |+--------------------+| +------+ 112 | | 113 | EVI 1 | 114 +----------------------+ 116 VLAN-Aware Bundle Service Interface 118 Figure 1: EVPN Service Interfaces Overview 120 For VLAN-based service interface, there is a one to one mapping 121 between VID and EVI. Each EVI has a single broadcast domain so that 122 traffic from different customers can be isolated. 124 For VLAN-bundle service interface, there is a N to one mapping 125 between VID and EVI. Each EVI has a single broadcast domain, but the 126 MAC address MUST be unique that can be used for customer traffic 127 isolation. 129 For VLAN-aware bundle service interface, there is a N to one mapping 130 between VID and EVI. Each EVI has multiple broadcast domains while 131 the MAC address can overlap. One broadcast domain corresponds to one 132 VID, which can be used to customer traffic isolation. 134 In the scenarios corresponding to these service interfaces, CE-PE 135 should be placed in the same Layer-2 network. In most of provider 136 network, CE-PE need to cross a Layer-3 network, then the above 137 service interfaces should be extended to adapt to the layer-3 138 network. 140 In this draft, we describe three layer-3 accessible interfaces for 141 EVPN, summarize the existing layer-3 accessible EVPN solutions, and 142 propose a new solution which can simplify the depolyment of layer-3 143 accessible EVPN service. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119] . 151 3. Terminology 153 The following terms are defined in this draft: 155 o CE: Client Edge 157 o PE: Provider Edge 159 o EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] 161 o VxLAN: Virtual eXtensible Local Area Network, defined in [RFC7348] 163 o IPSec: Internet Protocol Security, defined in [RFC4301] 165 4. Service Interfaces in layer-3 accessible EVPN 167 In most of provider network, CE-PE need to cross a Layer-3 network. 168 With this scenario, service interfaces defined in [RFC7432] should be 169 extended to adapt to the layer-3 network. To achieve the traffic 170 isolation, tunnel encapsulation technologies can be used. 172 We define Logical Session Identifier(LSI) to distinguish the packets 173 from different tunnels, which is related to VNI/SPI. The length of 174 LSI is 16 bits. 176 The layer-3 accessible interfaces for EVPN are shown in Figure 2, 177 refer to [RFC7432] 179 1:1 1:1 180 +------+ +---------+ +------+ 181 |LSI 11+---+ IP-VRF1 +---+LSI 12| 182 +------+ +---------+ +------+ 183 |LSI 21+---+ IP-VRF2 +---+LSI 22| 184 +------+ +---------+ +------+ 185 |LSI 31+---+ IP-VRF3 +---+LSI 32| 186 +------+ +---------+ +------+ 187 |LSI 41+---+ IP-VRF4 +---+LSI 42| 188 +------+ +---------+ +------+ 190 LSI-based Service Interface 192 N:1 1:N 193 +------+ +---------+ +------+ 194 |LSI 11---------+ +--------+LSI 12| 195 +------+ + + +------+ 196 |LSI 21+--------+ +--------+LSI 22| 197 +------+ + IP-VRF1 + +------+ 198 |LSI 31+--------+ +--------+LSI 32| 199 +------+ + + +------+ 200 |LSI 41+--------+ +--------+LSI 42| 201 +------+ +---------+ +------+ 203 LSI-bundle Service Interface 205 N:1 1:N 206 +----------------------+ 207 +------+ |+--------------------+| +------+ 208 |LSI 11+--++ Logical Plane 1 ++--+LSI 12| 209 +------+ |+--------------------+| +------+ 210 |LSI 21+--++ Logical Plane 2 ++--+LSI 22| 211 +------+ |+--------------------+| +------+ 212 |LSI 31+--++ Logical Plane 3 ++--+LSI 32| 213 +------+ |+--------------------+| +------+ 214 |LSI 41+--++ Logical Plane 4 ++--+LSI 42| 215 +------+ |+--------------------+| +------+ 216 | | 217 | IP-VRF 1 | 218 +----------------------+ 220 LSI-Aware Bundle Service Interface 222 Figure 2: Layer-3 accessible EVPN Service Interfaces Overview 224 For LSI-based service interface, there is a one to one mapping 225 between LSI and IP-VRF. Each IP-VRF has a single logical plane so 226 that traffic from different customers can be isolated. 228 For LSI-bundle service interface, there is a N to one mapping between 229 LSI and IP-VRF. Each IP-VRF has a single logical plane, but the IP 230 address MUST be unique that can be used for customer traffic 231 isolation. 233 For LSI-aware bundle service interface, there is a N to one mapping 234 between LSI and IP-VRF. Each IP-VRF has multiple logical planes 235 while the IP address can overlap. One logical plane corresponds to 236 one LSI, which can be used to customer traffic isolation. 238 5. Solutions of LSI-aware bundle service interface 240 Let's assume a scenario as shown in Figure 3. PE1, PE2 and PE3 are 241 EVPN peers, the customer data transmission between PEs relies on 242 VxLAN. CE1, CE2 and CE3 are connected to the sites of customer for 243 its department A and B. 245 Department A 247 Department B 248 +---+ 249 |CE1| 250 +-+-+ 251 +-------------------+------------------+ 252 | +-+-+ | 253 | +-----------+PE1+----------+ | 254 | | +---+ | | 255 | | | | 256 | | | | 257 | | | | 258 Department A | | | | Department A 259 | | | | 260 Department B | | | | Department B 261 +---+ | +++-+ +-+++ | +---+ 262 |CE2+--+---+PE2+----------------------+PE3+---+--+CE3| 263 +---+ | +---+ +---+ | +---+ 264 | | 265 | | 266 | EVPN | 267 +--------------------------------------+ 269 Figure 3: LSI-aware bundle service interface scenario 271 If each VNI has its own IP-VRF, each PE and CE maintain an IP-VRF for 272 each deployment. In this situation, customer traffic can be isolated 273 by different VNIs, and there is no need for extending control plane/ 274 forwarding plane protocols. 276 For deployment, we expect a simpler way, such as assign an IP-VRF to 277 each customer, not to each department. That is to say, all VNIs 278 share one IP-VRF on PEs. In this situation, each CE still maintain 279 an IP-VRF for each deployment, but each PE maintains only one VRF for 280 all deployments. In this situation, customer traffic cannot be 281 isolated by VNIs. We propose a solution for this scenario: 283 o Using LSI information to identify different customer routes / 284 traffic. As described above, LSI can be generated by VNI/SPI, and 285 there is a one to one mapping between LSI and VNI/SPI. PEs should 286 maintain the mapping table of LSI and VNI/SPI, so that they can 287 distinguish different customer routes / traffic. LSI information 288 can be transmitted by using Ethernet Tag ID or a newly defined ESI 289 type. 291 o TBD (more solutions are welcome). 293 6. Protocol Extensions 295 6.1. Forwarding Plane 297 6.1.1. Extensions to VxLAN 299 When the forwarding plane uses VxLAN tunnel technologes, we should 300 extend the VxLAN GPE header to carry the LSI information, the 301 extentions to the VxLAN GPE header is shown in Figure 4: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |R|S|Ver|I|P|B|O| LSI |Next Protocol | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | VXLAN Network Identifier (VNI) | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 4: The extentions to VxLAN GPE header 313 We define a S bit. If S is set to 1, it means the field after O bit 314 contains LSI information. 316 6.2. Control Plane 318 We proposed two methods to identify the routes that related to 319 different LSI information: 321 o Reusing the Ethernet Tag ID. This method requires the update of 322 [I-D.ietf-bess-evpn-prefix-advertisement] (Etherenet Tag ID is set 323 to 0 for route type 5), and may arises some confuse with the 324 original defination of Ethernet Tag ID. 326 o Using the newly defined ESI type as shown in Figure 5. This 327 method can preserve the original purpose of ESI defination (multi- 328 homing). 330 +---+---+---+---+---+---+---+---+---+---+ 331 | T | Reserved | CE Identifier | LSI | 332 +---+---+---+---+---+---+---+---+---+---+ 334 Figure 5: The format of new ESI type 336 Where: 338 o T (1 octet): specifys the ESI Type. The recommended value is 339 0x06. 341 o CE Identifier (3 octets): the route ID/IPv4 address of CE. 343 o LSI (2 octets): the LSI information. 345 Since the length of LSI is 16 bits, while the length of Ethernet Tag 346 ID and ESI are 80 bits and 32 bits, respectively. We can only use 347 the lower 16 bits of Ethernet Tag ID / ESI field to carry LSI 348 information, the other locations MUST set to 0. 350 7. Security Considerations 352 TBD 354 8. IANA Considerations 356 This draft extends the VxLAN GPE header, S bit of Flag and LSI field 357 are added: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |R|S|Ver|I|P|B|O| LSI |Next Protocol | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | VXLAN Network Identifier (VNI) | Reserved | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 This draft also define a new ESI type: 369 +---+---+---+---+---+---+---+---+---+---+ 370 | T | Reserved | CE Identifier | LSI | 371 +---+---+---+---+---+---+---+---+---+---+ 373 9. Normative References 375 [I-D.ietf-bess-evpn-prefix-advertisement] 376 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 377 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 378 bess-evpn-prefix-advertisement-11 (work in progress), May 379 2018. 381 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 382 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 383 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 384 ietf-bess-mvpn-evpn-aggregation-label-05 (work in 385 progress), January 2021. 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, 389 DOI 10.17487/RFC2119, March 1997, 390 . 392 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 393 RFC 2890, DOI 10.17487/RFC2890, September 2000, 394 . 396 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 397 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 398 December 2005, . 400 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 401 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 402 eXtensible Local Area Network (VXLAN): A Framework for 403 Overlaying Virtualized Layer 2 Networks over Layer 3 404 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 405 . 407 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 408 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 409 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 410 2015, . 412 Authors' Addresses 414 Wei Wang 415 China Telecom 416 Beiqijia Town, Changping District 417 Beijing, Beijing 102209 418 China 420 Email: weiwang94@foxmail.com 422 Aijun Wang 423 China Telecom 424 Beiqijia Town, Changping District 425 Beijing, Beijing 102209 426 China 428 Email: wangaj3@chinatelecom.cn 429 Haibo Wang 430 Huawei Technologies 431 Huawei Building, No.156 Beiqing Rd. 432 Beijing, Beijing 100095 433 China 435 Email: rainsword.wang@huawei.com