idnits 2.17.1 draft-yu-bess-evpn-l2-attributes-03.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 ([RFC8214]), 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 21, 2019) is 1920 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup T. Yu 3 Internet-Draft 4 Intended status: Standards Track H. Wang 5 Expires: July 25, 2019 Huawei Technologies 6 January 21, 2019 8 Usage of Layer 2 Attributes Extended Community in EVPN 9 draft-yu-bess-evpn-l2-attributes-03 11 Abstract 13 This document adopts Layer 2 Attributes Extended Community defined in 14 [RFC8214] to EVPN allowing signalling L2 information in control 15 plane. 17 An interoperability mechanism of control word is described for EVPN 18 and VPWS in this document. 20 Also flow label signalling mechanism is described for EVPN and VPWS. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 25, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. EVPN Layer 2 Attributes Extended Community . . . . . . . . . 3 60 5. Usage of Control Word . . . . . . . . . . . . . . . . . . . . 5 61 5.1. EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1.1. Deterministic mode . . . . . . . . . . . . . . . . . 5 63 5.1.2. Interoperable mode . . . . . . . . . . . . . . . . . 6 64 5.2. EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.2.1. Deterministic mode . . . . . . . . . . . . . . . . . 7 66 5.2.2. Interoperable mode . . . . . . . . . . . . . . . . . 8 67 5.3. EVPN E-Tree . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Usage of Flow Label . . . . . . . . . . . . . . . . . . . . . 9 69 7. L2 MTU Processing . . . . . . . . . . . . . . . . . . . . . . 10 70 8. Instructions on Using Control Word and Flow Label . . . . . . 10 71 9. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 12.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 EVPN [RFC7432] lacks of a negotiation mechanism on L2 capabilities. 82 If the L2 capabilities between PE devices are different, they are not 83 able to communicate properly. [RFC8214] defines Layer 2 Attributes 84 Extended Community but there is no description on how to be used in 85 EVPN ELAN. This document describes how Layer 2 Attributes Extended 86 Community is used in EVPN ELAN. 88 Considering some devices have no capability to support control word 89 and there are legacy devices without control word function supported, 90 an interoperability mechanism on control word is described. 92 To achieve better load balancing on EVPN ELAN and VPWS services, flow 93 label function in EVPN is described in this document. 95 2. Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 98 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in [RFC2119]. 101 3. Terminology 103 EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432]. 105 EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN specifies 106 EVPN defined in [RFC7432]. 108 EVI: An EVPN Instance spanning the Provider Edge (PE) devices 109 participating in that EVPN ELAN. 111 EVPN VPWS: EVPN Virtual Private Wire Service, refers to [RFC8214]. 113 EVPN E-Tree: Ethernet VPN Ethernet-Tree defined in [RFC8317]. 115 CW: Control Word defined in [RFC4448]. 117 CI: Control Word Indicator, defined in Section 4 of this document. 119 PE: Provider Edge device. 121 FL: Flow-Aware Transport Label, defined in [RFC6391]. 123 4. EVPN Layer 2 Attributes Extended Community 125 The definition of EVPN Layer 2 Attributes Extended Community is same 126 with [RFC8214]. it is listed as below for convenience. 128 +-------------------------------------------+ 129 | Type (0x06) / Sub-type (0x04) (2 octets) | 130 +-------------------------------------------+ 131 | Control Flags (2 octets) | 132 +-------------------------------------------+ 133 | L2 MTU (2 octets) | 134 +-------------------------------------------+ 135 | Reserved (2 octets) | 136 +-------------------------------------------+ 138 Figure 1: EVPN Layer 2 Attributes Extended Community 140 The definition of Control Flags is as below: 142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 143 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ 144 | MBZ |CI|F|C|P|B| (MBZ = MUST Be Zero) 145 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ 147 Figure 2: Control Flags 149 The P bit and B bit defined in [RFC8214] must be zero when used in 150 EVPN ELAN mode. This is because [RFC7432] has defined ESI Label 151 Extended Community to achieve single-active redundancy mode. 153 C bit indicates the control word enable status of known unicast 154 traffic. C bit MUST set 0 when advertising A-D route if PE has no 155 capability of processing control word. C bit SHOULD be same across 156 all Ethernet Segments within one EVI on a local PE when used in EVPN 157 ELAN. BUM traffic SHOULD NOT include control word when forwarded no 158 matter C bit is set to 1 or 0 when working in EVPN ELAN. 160 CI bit is defined to achieve interoperability between devices with 161 and without control word capability. Control Word Indicator is a 162 MPLS label. CI bit MUST NOT set 1 if C bit is set 0. 164 CI label MUST NOT be an MPLS reserved label [RFC3032] and MUST be 165 with TTL=1. CI label MUST NOT be used for directing forwarding 166 behavior in any cases. 168 When a PE sends packet with CI label, it MUST keep CI label value 169 consistent for traffic towards one ES. EVI service label value, 170 including type1 and type2, MAY be used as CI value directly. 172 The usage of CI bit is described in Section 5. 174 F bit is defined to achieve flow label signalling capability in both 175 EVPN ELAN and VPWS. When F bit is set to 1, the PE announces it has 176 the capability of both sending and receiving flow label. F bit 177 SHOULD be same across all Ethernet Segments within one EVI on a local 178 PE when used in EVPN ELAN. BUM traffic in EVPN ELAN SHOULD NOT 179 include Flow label when forwarded no matter F bit is set to 1 or 0 180 when working in ELAN mode. 182 C bit and F bit MUST NOT set 1 together. 184 Other bits in Control Flags are reserved for future investigation and 185 MUST be zero. 187 L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes. It 188 MUST be same across all ES within one EVI on a local PE. 190 If local PE does not support EVPN Layer 2 Attributes Extended 191 Community, this community MUST be ignored. 193 When a PE receives A-D routes with C, CI or F bit enabled, the 194 behavior SHOULD be spread to all MAC tables towards the corresponding 195 ES. 197 5. Usage of Control Word 199 5.1. EVPN ELAN 201 The description on EVPN ELAN CW mechanism is based on the network 202 topology showed in Figure 3: 204 +--------+ +--------+ 205 | PE1 | | PE2 | 206 | (CW) |-------| (CW) | 207 +--------+ +--------+ 208 \ / 209 \ / 210 +--------+ 211 | PE3 | 212 | (NCW) | 213 +--------+ 215 Figure 3: Network Topology for EVPN ELAN Control Word 217 PE1 and PE2 are routers with CW enabled and PE3 is router CW disabled 218 or without CW capability. It is assumed that PE1, PE2 and PE3 are 219 working in the same EVI. 221 5.1.1. Deterministic mode 223 When an EVPN ELAN working in deterministic mode, each PE advertises 224 CW capability based on local status in auto-discovery route via l2 225 attribute. CI bit is not used in this mode. In such case, C bit of 226 devices in Figure 3 is: C bit of PE1 and PE2 is 1, C bit of PE3 is 0. 227 After a PE receives EVPN auto-discovery route, it compares the value 228 of C bit with local control word enable status. If same, local PE 229 treats remote PE as a valid EVPN destination. If not same, local PE 230 treats remote PE as an invalid EVPN destination. 232 After such process: 234 PE1 treats PE2 as valid destination and PE3 as invalid destination. 236 PE2 treats PE1 as valid destination and PE3 as invalid destination. 238 PE3 treats PE1 and PE2 as invalid destination. 240 PE1 and PE2 will forward traffic with control word encapsulated. PE1 241 and PE2 will not be able to interoperate with PE3, due to control 242 word status being different. 244 5.1.2. Interoperable mode 246 Considering some devices has no capability of adding and parsing CW, 247 there are two ways to interoperate such devices: 249 1. Disable CW function on all devices and keep CW status consistent 250 within EVI, then the EVI can work in the deterministic mode. 252 2. An interoperable mode based on CI MAY be implemented to achieve 253 interoperability with such devices. 255 Considering EVPN label is "upstream-assigned", a PE can receive 256 packets with same label but with different CW status from different 257 remote PEs. This brings challenge on CW interoperate mechanism. To 258 overcome this challenge, CI is introduced to allow a PE identifying 259 CW status on forwarding plane. 261 When an EVPN ELAN working in interoperable mode, if CW on a PE is 262 enabled, the PE MUST set both C and CI bit = 1. If CW on a PE is 263 disabled, the PE MUST set both C and CI bit = 0. 265 After a PE receives EVPN auto-discovery route, it compares the value 266 of C bit and CI: 268 o If C=CI: remote PE is treated as valid EVPN destination. 270 o Else: remote PE is treated as invalid EVPN destination. 272 After such process, PE1, PE2 and PE3 treat each other as valid EVPN 273 destination. 275 When local PE forwards a packet to remote PE, if remote PE is control 276 word enabled (C=1), then the unicast packet MUST be encapsulated with 277 a control word indicator before control word. If remote PE is 278 control word disabled or no control word capability (C=0), then 279 unicast packet is directly encapsulated after MPLS label as payload. 281 For example: 283 PE1 advertises A-D route with CI and C bit set 1, packet forwarding 284 behavior is as below: 286 PE2->PE1: Transport Label + EVPN Label to PE1 + CI + CW + Payload 288 PE3->PE1: Transport Label + EVPN Label to PE1 + Payload 290 PE2 advertises A-D route with CI and C bit set 1, PE3 advertise A-D 291 route with CI and C bit set 0, packet forwarding from PE1 to PE2 and 292 PE3 is as below:: 294 PE1->PE2: Transport Label + EVPN Label to PE2 + CI + CW + Payload 296 PE1->PE3: Transport Label + EVPN Label to PE3 + Payload 298 After a PE receives a packet, after looking at EVPN label, if it is 299 bottom of stack, it indicates CW is not included behind. If it is 300 not bottom of stack, it indicates CW is included behind CI. 302 When working in interoperable mode, impact of lacking complete CW 303 between PEs SHOULD be evaluated based on section 8 of this document. 305 5.2. EVPN VPWS 307 The description on EVPN VPWS CW mechanism is based on the network 308 topology showed in Figure 4: 310 +--------+ +--------+ 311 | PE1 | | PE2 | 312 | (CW) |-------| (CW) | 313 +--------+ +--------+ 314 \ 315 \ 316 +--------+ 317 | PE3 | 318 | (NCW) | 319 +--------+ 321 Figure 4: Network Topology for EVPN VPWS Control Word 323 PE1 and PE2 are routers with CW enabled and PE3 is router CW disabled 324 or without CW capability. It is assumed that there is one EVPN VPWS 325 between PE1 and PE2 and another VPWS between PE1 and PE3. 327 5.2.1. Deterministic mode 329 When an EVPN VPWS working in deterministic mode, each PE advertises 330 CW capability based on local status in auto-discovery route via l2 331 attribute. In such case, C bit of devices in Figure 4 is: C bit of 332 PE1 is 1, C bit of PE2 is 0. After a PE receives EVPN auto-discovery 333 route, it compares the value of C bit with local control word enable 334 status. If not same, local PE MUST NOT bring up the EVPN VPWS. 336 After such process: 338 EVPN VPWS between PE1 and PE2 is up. 340 EVPN VPWS between PE1 and PE3 is down. 342 PE1 and PE2 will forward traffic with control word encapsulated. 344 5.2.2. Interoperable mode 346 Considering some devices has no capability of adding and parsing CW, 347 there are two ways to interoperate such devices: 349 1. Disable CW function on PE1 and keep CW status consistent within 350 EVPN VPWS towards PE3, then the EVPN VPWS can work in the 351 deterministic mode. 353 2. An interoperable mode MAY be implemented to achieve 354 interoperability with such devices. 356 When an EVPN VPWS working in interoperable mode, in case of C bit 357 status is not consistent on both ends, VPWS MUST tear up. 359 In such case: 361 EVPN VPWS between PE1 and PE2 is up. 363 EVPN VPWS between PE1 and PE3 is up. 365 PE1 and PE2 will forward traffic with CW encapsulated. PE1 and PE3 366 forward traffic without CW encapsulated. 368 When working in interoperable mode, impact of lacking complete CW 369 between PEs SHOULD be evaluated based on section 8 of this document. 371 CI MUST NOT set 1 when working in EVPN VPWS. 373 5.3. EVPN E-Tree 375 The procedure described in section 5.1 applies to EVPN E-Tree, both 376 "two RTs" and "single RT" via "leaf" flag solution. 378 When using "single RT" E-Tree, there is a particular case that 379 devices with and without CW capability can interoperate without CI 380 involved. This case is: root device is CW disabled but (part of) the 381 leaf devices CW enabled. In such case, leaf PE SHOULD treat root and 382 other leaves as valid EVPN destination, even C bit status is not 383 consistent. Leaf PEs with CW enabled forward known unicast traffic 384 without CW encapsulated towards root. Similarly when an E-tree is 385 working in interoperable mode instead of deterministic mode, impact 386 of lacking complete CW between PEs SHOULD be evaluated based on 387 section 8 of this document. 389 6. Usage of Flow Label 391 +--------+ +--------+ 392 | PE1 | | PE2 | 393 | (FL) |-------| (FL) | 394 +--------+ +--------+ 395 \ / 396 \ / 397 +--------+ 398 | PE3 | 399 | (NFL) | 400 +--------+ 402 Figure 5: Network Topology for Flow Label Usage 404 Flow label is introduced allowing to achieve better load-balancing in 405 the network in conditions mentioned below: 407 o Services in EVPN is not sensitive to misordering. 409 o Transit network has no capability parsing payload inside MPLS 410 label as hash factor. 412 PE1 and PE2 are routers with flow label capability and flow label 413 enabled and PE3 is router flow label disabled or without flow label 414 capability. It is assumed that PE1, PE2 and PE3 are working in same 415 EVI. 417 When local PE receives auto-discovery routes from remote PE, F bit 418 does not impact validation process of EVPN auto-discovery routes. 419 Even F bit of remote PE does not match with local status, local PE 420 SHOULD still add remote PE as a valid EVPN destination. 422 When sending traffic from PE1 towards PE2 and PE3, as PE1 has already 423 learnt the FL status of PE2 and PE3, packet encapsulation is as 424 below: 426 PE1->PE2: Transport Label + EVPN Label to PE2 + FL + Payload 428 PE1->PE3: Transport Label + EVPN Label to PE3 + Payload 429 When sending traffic from PE2 and PE3 towardsPE1, packet 430 encapsulation is as below: 432 PE2->PE1: Transport Label + EVPN Label to PE1 + FL + Payload 434 PE3->PE1: Transport Label + EVPN Label to PE1 + Payload 436 When PE1 receives a packet, after looking at EVPN label, if it is 437 bottom of stack, it indicates FL is not included behind. If it is 438 not bottom of stack, it indicates FL is included behind. 440 The flow label mechanism described above is applicable to both EVPN 441 ELAN, E-Tree and EVPN VPWS. 443 7. L2 MTU Processing 445 If a non-zero MTU attribute is received, it MUST be checked against 446 local MTU value if the local value is not zero. If there is a 447 mismatch, the local PE MUST NOT add the remote PE as the EVPN ELAN or 448 VPWS destination. 450 8. Instructions on Using Control Word and Flow Label 452 In EVPN, CW is used avoid misordering caused by transit node using 453 MPLS payload as hash factor. The detailed reason for this refers to 454 [RFC8469]. CW is mandatory for an EVPN carrying misordering 455 sensitive service, when CW is not available, mitigations described in 456 section 6 of [RFC8469] also apply to EVPN. 458 Flow Label SHOULD NOT be used in EVPN carrying services sensitive to 459 misordering. Flow Label MAY be used to achieve better load-balancing 460 in network, when transit node has no capability to look inside MPLS 461 payload as hash factor. 463 It has been recognized that some transit nodes treat payload after 464 MPLS label as MAC address info and use as hash factor directly. When 465 it is bearing services sensitive to misordering, such load balancing 466 function SHOULD be disabled, otherwise control word will be treated 467 as part of MAC address mistakenly. 469 Similarly, entropy label [RFC6790] SHOULD NOT be used in EVPN 470 carrying services sensitive to misordering. 472 9. Other Considerations 474 When data plane is not using MPLS, C, F and CI bits in control flags 475 MUST be 0. Control word and Flow Label are only applicable to MPLS 476 data plane. 478 When working with legacy devices without L2 attribute in EVPN ELAN, 479 local PE SHOULD assume the behavior of all remote PE is same with 480 local. This allows backward compatibility of using L2 attribute. 481 Also a route policy MAY be implemented to specify L2 behavior 482 manually in case l2 attribute is absent. This function SHOULD be 483 used only for interoperability. A PE SHOULD NOT overwrite existing 484 l2 attribute in a received route. 486 10. Security Considerations 488 This document updates the behavior specified in [RFC7432] and 489 [RFC8214]. The security considerations listed in these two documents 490 apply. However, there are no new security considerations due to the 491 text of this document. 493 11. IANA Considerations 495 This document does not make any requests from IANA. 497 12. References 499 12.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 507 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 508 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 509 2015, . 511 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 512 Rabadan, "Virtual Private Wire Service Support in Ethernet 513 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 514 . 516 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 517 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 518 Support in Ethernet VPN (EVPN) and Provider Backbone 519 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 520 January 2018, . 522 [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to 523 Use the Ethernet Control Word", RFC 8469, 524 DOI 10.17487/RFC8469, November 2018, 525 . 527 12.2. Informative References 529 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 530 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 531 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 532 . 534 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 535 "Encapsulation Methods for Transport of Ethernet over MPLS 536 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 537 . 539 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 540 Regan, J., and S. Amante, "Flow-Aware Transport of 541 Pseudowires over an MPLS Packet Switched Network", 542 RFC 6391, DOI 10.17487/RFC6391, November 2011, 543 . 545 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 546 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 547 RFC 6790, DOI 10.17487/RFC6790, November 2012, 548 . 550 Authors' Addresses 552 Tianpeng Yu 554 EMail: yutianpeng.ietf@gmail.com 556 Haibo Wang 557 Huawei Technologies 558 Huawei Bld., No.156 Beiqing Road 559 Beijing 100085 560 China 562 EMail: rainsword.wang@huawei.com