idnits 2.17.1 draft-yu-bess-evpn-l2-attributes-05.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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o C bit SHOULD not set 1 if Layer 2 Attributes Extended Community is used in IMET route for P2MP or MP2MP LSPs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o F bit SHOULD not set 1 if Layer 2 Attributes Extended Community is used in IMET route for P2MP or MP2MP LSPs. -- The document date (April 3, 2019) is 1849 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: 'RFC7153' is mentioned on line 483, but not defined == Unused Reference: 'RFC6790' is defined on line 541, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup T. Yu, Ed. 3 Internet-Draft 4 Updates: RFC7432, RFC8214 (if approved) H. Wang 5 Intended status: Standards Track Huawei Technologies 6 Expires: October 5, 2019 April 3, 2019 8 Usage of Layer 2 Attributes Extended Community in EVPN 9 draft-yu-bess-evpn-l2-attributes-05 11 Abstract 13 This document adopts Layer 2 Attributes Extended Community defined in 14 [RFC8214] to EVPN allowing negotiate Layer2 information in the 15 control plane. 17 An interoperability mechanism between PEs with and without control 18 word capability is described for EVPN and VPWS in this document. 20 Flow label signaling mechanism is also described for EVPN ELAN and 21 VPWS with interoperability capability considered. 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 https://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 October 5, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 (https://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. Specification of Requirements . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. EVPN Layer 2 Attributes Extended Community . . . . . . . . . 4 61 4.1. Control Flag Attribute . . . . . . . . . . . . . . . . . 6 62 4.2. L2 MTU Attribute . . . . . . . . . . . . . . . . . . . . 7 63 5. Control Word Indicator Extended Community . . . . . . . . . . 7 64 6. Usage of Control Word . . . . . . . . . . . . . . . . . . . . 8 65 6.1. EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1.1. Deterministic mode . . . . . . . . . . . . . . . . . 8 67 6.1.2. Interoperable mode . . . . . . . . . . . . . . . . . 9 68 6.2. EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.2.1. Deterministic mode . . . . . . . . . . . . . . . . . 9 70 6.2.2. Interoperable mode . . . . . . . . . . . . . . . . . 9 71 7. Usage of Flow Label . . . . . . . . . . . . . . . . . . . . . 10 72 8. Instructions on Using Control Word and Flow Label . . . . . . 10 73 9. Other Considerations . . . . . . . . . . . . . . . . . . . . 11 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 13.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Example of using Layer 2 Attributes Extended 81 Community . . . . . . . . . . . . . . . . . . . . . 13 82 A.1. Example 1: ELAN Control Word Deterministic mode . . . . . 13 83 A.2. Example 2: ELAN Control Word Interoperable mode . . . . . 13 84 A.3. Example 3: Usage of Flow Label . . . . . . . . . . . . . 14 85 A.4. Example 4: Combination of Control Word and Flow Label . . 14 86 A.5. Example 5: Combination of CW Interoperable mode and FL . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 EVPN [RFC7432] lacks a negotiation mechanism on L2 capabilities. 92 Lacking such capabilities will lead to malformed packets on 93 forwarding plane without any prevention from the control plane 94 signaling. Issues caused due to mismatch of Layer 2 capabilities are 95 listed below: 97 o Mismatching of MTU across interfaces attached within one EVPN ELAN 98 or VPWS leads to consistent packet loss on the interface with 99 smaller MTU than the other interfaces, due to fragmentation is not 100 possible in the Layer 2 network. 102 o Mismatching of control word enable status between PEs within the 103 same EVPN ELAN or VPWS leads to control word being treated as 104 payload of the EVPN instead of being stripped off. 106 [RFC8214] defines Layer 2 Attributes Extended Community but there is 107 no definition on how it is used in EVPN ELAN. 109 There are scenarios that PEs are deployed in a mixed environment 110 where some PEs support Control Word but others not. The behavior and 111 interoperate mechanism of such scenario is needed. 113 There is also a requirement on flow label capability on EVPN ELAN and 114 VPWS in absence of entropy label. The signaling capability of flow 115 label on the control plane is also necessary. 117 In summary, this document aims to describe how Layer 2 Attributes 118 Extended Community to be used in EVPN ELAN, with targets listed 119 below: 121 o MTU consistency validation for EVPN ELAN. 123 o CW (Control Word) consistency validation for EVPN ELAN. 125 o Introduce a CW interoperate mechanism in case not all devices 126 within the EVPN ELAN or VPWS support Control Word. 128 o Introduce flow label signaling mechanism allowing EVPN ELAN and 129 VPWS to achieve better load balancing, with interoperability 130 capability considered. 132 2. Specification of Requirements 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. Terminology 142 EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432]. 144 EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN specifies 145 EVPN defined in [RFC7432]. 147 EVI: An EVPN ELAN Instance. 149 EVPN VPWS: EVPN Virtual Private Wire Service, refers to [RFC8214]. 151 EVPN E-Tree: Ethernet VPN Ethernet-Tree defined in [RFC8317]. 153 CW: Control Word defined in [RFC4448]. 155 CI: Control Word Indicator, defined in Section 4 of this document. 157 PE: Provider Edge device. 159 FL: Flow-Aware Transport Label, defined in [RFC6391]. 161 BUM: Broadcast, Unknown-Unicast, Multicast. 163 P2MP: Point to Multi-Point. 165 MP2P: Multi-Point to Point. 167 MP2MP: Multi-Point to Multi-Point. 169 LSP: Label-Switched Path. 171 EAD Route: Ethernet Auto-discovery Route Route defined in [RFC7432]. 173 IMET Route: Inclusive Multicast Ethernet Tag Route defined in 174 [RFC7432]. 176 BoS: Bottom-of-Stack. 178 4. EVPN Layer 2 Attributes Extended Community 180 The definition of EVPN Layer 2 Attributes Extended Community is the 181 same with [RFC8214]. it is listed as below for convenience. 183 +-------------------------------------------+ 184 | Type (0x06) / Sub-type (0x04) (2 octets) | 185 +-------------------------------------------+ 186 | Control Flags (2 octets) | 187 +-------------------------------------------+ 188 | L2 MTU (2 octets) | 189 +-------------------------------------------+ 190 | Reserved (2 octets) | 191 +-------------------------------------------+ 193 Figure 1: EVPN Layer 2 Attributes Extended Community 195 Layer 2 Attributes Extended Community SHOULD be included in Ethernet 196 Auto-discovery Route route and Inclusive Multicast Ethernet Tag 197 Route. Layer 2 Attributes Extended Community is necessary for per 198 Ethernet Segment based EAD (section 8.2.1 of [RFC7432]) and optional 199 for per EVPN instance based EAD (section 8.4.1 of [RFC7432]). 201 For a single-homed ES in ELAN, the Layer 2 Attributes Extended 202 Community is advertised along with a per EVI based EAD route with an 203 all-zero ESI and a set of RTs corresponding to the EVI on the PE. 204 This updates the behavior defined in section 8.2.1 of [RFC7432], 205 which says "The Ethernet A-D route is not needed when the Segment 206 Identifier is set to 0". 208 For an EVPN ELAN, Layer 2 Attributes Extended Community included in 209 EAD route applies to unicast traffic and IMET Route applies to BUM 210 traffic. 212 Layer 2 Attributes Extended Community for unicast SHOULD be same 213 across all Ethernet Segments in EAD routes within one EVI on a local 214 PE when used in EVPN ELAN. 216 Layer 2 Attributes Extended Community for BUM SHOULD be same across 217 EVIs in IMET route sharing the same P-Tunnel within a PE. 219 Any inconsistency on L2 Attributes Extended Community of interfaces 220 attached to the same EVI (EAD route) MUST or EVIs sharing same 221 P-tunnel (IMET route) SHOULD be resolved before the corresponding 222 route being advertised. 224 Layer 2 Attributes Extended Community MAY be different between EAD 225 route and IMET Route for one EVI. For example, EAD route advertises 226 control word capability but IMET route advertises no control word 227 capability. This means, the validation of Layer 2 Attributes 228 Extended Community in EAD and IMET route are independent. 230 When a PE receives routes without L2 Attributes Extended Community, 231 the local PE SHOULD assume the values of Layer 2 Attributes Extended 232 Community of all corresponding PEs are same with local. This allows 233 backward compatibility of introducing L2 Attributes Extended 234 Community into EVPN ELAN. 236 If a local PE does not support EVPN Layer 2 Attributes Extended 237 Community, this community MUST be ignored. 239 4.1. Control Flag Attribute 241 The definition of Control Flags is as below: 243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 244 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ 245 | MBZ |CI|F|C|P|B| (MBZ = MUST Be Zero) 246 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ 248 Figure 2: Control Flags in EVPN Layer 2 Attributes Extended Community 250 The P bit and B bit defined in [RFC8214] must be zero when used in 251 EVPN ELAN mode. 253 C bit indicates the control word enable status: 255 o When C bit is set to 1, the PE announces it has the capability of 256 both sending and receiving CW. 258 o C bit MUST set 0 if PE has no capability of sending or receiving 259 control word. 261 o C bit SHOULD not set 1 if Layer 2 Attributes Extended Community is 262 used in IMET route for P2MP or MP2MP LSPs. 264 F bit is defined to achieve flow label signaling capability in EVPN: 266 o When F bit is set to 1, the PE announces it has the capability of 267 both sending and receiving flow label. 269 o F bit MUST set 0 if PE has no capability of sending or receiving 270 flow label. 272 o F bit SHOULD not set 1 if Layer 2 Attributes Extended Community is 273 used in IMET route for P2MP or MP2MP LSPs. 275 CI bit is defined to achieve interoperability between devices with 276 and without control word capability. Control Word Indicator is a 277 MPLS label. CI bit MUST NOT set 1 if C bit is set 0. The target of 278 CI is to allow equipments with CW capability and a higher level of 279 programmability to be able to communicate together with equipments 280 has and does not have CW capability together in an MP2MP ELAN 281 network. 283 CI label MUST NOT be a MPLS reserved label [RFC3032], MUST be with 284 TTL=1. CI label MUST NOT be used to direct forwarding behavior in 285 any cases. 287 When a PE sends packets with CI label, it MUST keep value CI labels 288 consistent for traffic towards the same ES. 290 There are two ways of filling CWI label value: 292 o Use the label value advertised in Control Word Indicator Extended 293 Community (refer to section 5). 295 o In case absence of Control Word Indicator Extended Community, EVPN 296 service label MAY be copied into CWI. 298 The usage of CI bit is described in Section 6. 300 Other bits in Control Flag are reserved for future investigation and 301 MUST be zero. 303 When a PE receives Auto-discovery routes with C or F bit enabled, the 304 behavior SHOULD be spread to all MAC tables towards the corresponding 305 ES. 307 4.2. L2 MTU Attribute 309 L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes. If 310 a non-zero MTU attribute is received, it MUST be checked against 311 local MTU value if the local value is not zero. If there is a 312 mismatch, the local PE SHOULD NOT add the remote PE as the EVPN ELAN 313 or VPWS destination. The process described is applicable to both EAD 314 and IMET routes. 316 5. Control Word Indicator Extended Community 318 This extended community is a new transitive extended community having 319 a Type field value of 0x06 (EVPN) and the Sub-Type TBD. It is used 320 to indicate that the frame contains a CW after MPLS Bottom-of-Stack. 321 This extended community MAY be advertised along Ethernet Auto- 322 discovery Route route and Inclusive Multicast Ethernet Tag Route when 323 CI bit is 1 in EVPN Layer 2 Attributes Extended Community. 325 When a PE advertising the community, it MUST ensure value of CWI 326 label same across Ethernet Segments within one EVI in EAD route and 327 EVIs sharing the same P-Tunnel in IMET route. CI label value 328 advertised SHOULD NOT be same with EVPN service labels. Control Word 329 Indicator Extended Community MUST NOT be included if CI is 0. 331 If a PE contains Control Word Indicator Extended Community when 332 establishing the MP2P LSP, when receiving packets from MP2P LSP, it 333 uses the CI label value been advertised to identify existence of CW. 334 If a PE does not contain Control Word Indicator Extended Community 335 when establishing the MP2P LSP, it relies on the MPLS Bottom-of-Stack 336 bit to identify existence of CW. 338 When CI bit and F bit set 1 together, Control Word Indicator Extended 339 Community MUST be included. The packet encapsulation from ingress PE 340 is: transport label(s) + EVPN service label(s) + CI + FL (BoS) + CW + 341 payload. Forwarding plane on egress PE MUST use CI value in the 342 extended community to identify CW and identify FL in between if 343 exits. When working in such mode, source PE MUST ensure FL value 344 calculated locally does not equal CI value learnt from EVPN routes. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type=0x06 | Sub-Type=TBD | Flags(1 Octet)| Reserved=0 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reserved=0 | CI Label | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 3: Control Word Indicator Extended Community 356 6. Usage of Control Word 358 6.1. EVPN ELAN 360 6.1.1. Deterministic mode 362 PE advertises CW local enable status via Layer 2 Attributes Extended 363 Community. A validation procedure is added in procedure of Auto- 364 discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit 365 status in L2 attribute of received routes are same with local statue, 366 the received routes are treated valid. CI bit is not used in this 367 mode. 369 6.1.2. Interoperable mode 371 1. Disable CW function on all devices and keep CW status consistent 372 within EVI, then the EVI can work in the deterministic mode. 374 2. An interoperable mode based on CI MAY be implemented to achieve 375 interoperability with such devices. 377 An egress PE can receive packets from MP2P LSP with same EVPN label 378 but with different CW status from different remote PEs. This brings 379 challenge on CW interoperate mechanism. To overcome this challenge, 380 CI is introduced to allow a PE identifying CW status on forwarding 381 plane. 383 When an EVPN ELAN working in interoperable mode, if CW on a PE is 384 enabled, the PE MUST set both C and CI bit = 1. If CW on a PE is 385 disabled or the PE is not capable to add CW, the PE MUST set both C 386 and CI bit = 0. 388 In this mode, A validation procedure is added in procedure of Auto- 389 discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit 390 = CI bit in L2 attribute of received routes, received routes are 391 treated valid. 393 With such procedure, an egress PE is able to identify existence of CW 394 on forwarding plane via CI for packets received from MP2P LSP. 396 6.2. EVPN VPWS 398 6.2.1. Deterministic mode 400 When an EVPN VPWS working in deterministic mode, each PE advertises 401 CW capability based on local status in Auto-discovery route via l2 402 attribute. After a PE receives EVPN Auto-discovery route, it 403 compares the value of C bit with local control word enable status. 404 If not same, local PE MUST NOT bring up the EVPN VPWS. 406 6.2.2. Interoperable mode 408 Considering some devices has no capability of adding and parsing CW, 409 there are two ways to interoperate such devices: 411 1. Disable CW function on PE1 and keep CW status consistent within 412 EVPN VPWS towards PE3, then the EVPN VPWS can work in the 413 deterministic mode. 415 2. An interoperable mode MAY be implemented to achieve 416 interoperability with such devices. 418 When an EVPN VPWS working in interoperable mode, in case of C bit 419 status is not consistent on both ends, VPWS MUST tear up with control 420 word disabled on both ends. 422 When working in interoperable mode, impact of lacking complete CW 423 between PEs SHOULD be evaluated based on section 8 of this document. 425 7. Usage of Flow Label 427 PE advertises FL local enable status via Layer 2 Attributes Extended 428 Community. Different from CW, flow label signaling on control plane 429 uses a loose validation procedure, which means FL status in received 430 routes MAY be different from local. 432 For MP2P LSP, when sending packet towards remote PE, FL is added if 433 both local and remote PEs are enabled. If a PE has no FL capability, 434 it will not receive packets with FL from MP2P LSP as all source PEs 435 will not send packets with FL towards this PE. If a PE has FL 436 capability, it MAY receive packets with and without FL from MP2P LSP 437 as source PEs MAY have or haven't FL capability. In such case, the 438 PE SHOULD treat packet without FL valid on forwarding plane even 439 though local FL status is enabled. MPLS Bottom-of-Stack bit is used 440 to identify whether FL is contained in the packets. 442 The flow label mechanism described above is applicable to both EVPN 443 ELAN, E-Tree and EVPN VPWS. 445 8. Instructions on Using Control Word and Flow Label 447 In EVPN, CW is used to avoid misordering caused by transit node using 448 MPLS payload as hash factor. The detailed reason for this refers to 449 [RFC8469]. CW is mandatory for an EVPN carrying misordering 450 sensitive service, when CW is not available, mitigations described in 451 section 6 of [RFC8469] also apply to EVPN. 453 Flow Label MAY be used to achieve better load-balancing in network, 454 when transit node has no capability to look inside MPLS payload as 455 hash factor. 457 It has been recognized that some transit nodes treat payload after 458 MPLS label as MAC address info and use as hash factor directly. When 459 it is bearing services sensitive to misordering, such load balancing 460 function SHOULD be disabled, otherwise control word will be treated 461 as part of MAC address mistakenly. 463 9. Other Considerations 465 When data plane is not using MPLS, C, F and CI bits in control flags 466 MUST be 0. Control word and Flow Label are only applicable to MPLS 467 data plane. 469 10. Acknowledgements 471 TBD 473 11. Security Considerations 475 This document updates the behavior specified in [RFC7432] and 476 [RFC8214]. The security considerations listed in these two documents 477 apply. However, there are no new security considerations due to the 478 text of this document. 480 12. IANA Considerations 482 IANA is requested to allocate a new "EVPN Extended Community Sub- 483 Types" registry defined in [RFC7153] as follow: 485 SUB-TYPE NAME Reference 486 ------------------------------------------------------------------- 487 TBD Control Word Indicator Extended Community This document 489 13. References 491 13.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 499 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 500 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 501 2015, . 503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 505 May 2017, . 507 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 508 Rabadan, "Virtual Private Wire Service Support in Ethernet 509 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 510 . 512 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 513 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 514 Support in Ethernet VPN (EVPN) and Provider Backbone 515 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 516 January 2018, . 518 [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to 519 Use the Ethernet Control Word", RFC 8469, 520 DOI 10.17487/RFC8469, November 2018, 521 . 523 13.2. Informative References 525 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 526 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 527 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 528 . 530 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 531 "Encapsulation Methods for Transport of Ethernet over MPLS 532 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 533 . 535 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 536 Regan, J., and S. Amante, "Flow-Aware Transport of 537 Pseudowires over an MPLS Packet Switched Network", 538 RFC 6391, DOI 10.17487/RFC6391, November 2011, 539 . 541 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 542 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 543 RFC 6790, DOI 10.17487/RFC6790, November 2012, 544 . 546 Appendix A. Example of using Layer 2 Attributes Extended Community 548 The procedures described below are applicable to both EAD and IMET 549 routes, if the applicable route is not explicitly specified. 551 A.1. Example 1: ELAN Control Word Deterministic mode 553 Assume PE1 and PE2 have CW capability and announce C=1, PE3 has no CW 554 capability and announces C=0. When working in control word 555 deterministic mode, CI is announced with 0. 557 After validation of Layer2 Attribute Extended community, PE1 and PE2 558 treat each other as valid destination, and PE3 as invalid 559 destination. 561 Packet encapsulation is as below: 563 o PE1 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE2 565 o PE1 <-- Not allowed --> PE3 567 o PE2 <-- Not allowed --> PE3 569 A.2. Example 2: ELAN Control Word Interoperable mode 571 Assume PE1 and PE2 have CW capability and announce C=1, CI=1, PE3 has 572 no CW capability and announces C=0 and CI=0. 574 After validation of Layer2 Attribute Extended community, PE1, PE2 and 575 PE3 treat each other as valid destination. 577 Packet encapsulation is as below: 579 o PE1 <-- Transport label(s) + EVPN label(s) + CI (BoS) + CW + 580 Payload --> PE2 582 o PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 584 o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 586 In this scenario, CI label can be either the EVPL label closest to 587 the BoS, or signaled via Control Word Indicator Extended Community. 588 existence of CI can be identified via EVPN labels not being BoS or CI 589 label being advertised. 591 A.3. Example 3: Usage of Flow Label 593 Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL 594 capability and announces F=0. Assume control word of PE1, PE2 and 595 PE3 are disabled and C=0. 597 After validation of Layer2 Attribute Extended community, PE1, PE2 and 598 PE3 treat each other as valid destination. 600 Packet encapsulation is as below: 602 o PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + Payload 603 --> PE2 605 o PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 607 o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 609 A.4. Example 4: Combination of Control Word and Flow Label 611 Considering it is possible that transit node looks into flow label 612 (BoS), parse the first nibble of payload wrongly and lead to 613 misordering, control word mechanism is still applicable when flow 614 label being used. 616 Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL 617 capability and announces F=0. Assume control word of PE1, PE2 and 618 PE3 are enabled and C=1. 620 After validation of Layer2 Attribute Extended community, PE1, PE2 and 621 PE3 treat each other as valid destination. 623 Packet encapsulation is as below: 625 o PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + CW + 626 Payload --> PE2 628 o PE1 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE3 630 o PE2 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE3 632 A.5. Example 5: Combination of CW Interoperable mode and FL 634 Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL 635 capability and announces F=0. Assume control word of PE1 and PE2 are 636 enabled and C=1, CI=1, control word of PE3 is disabled and C=0 CI=0. 638 After validation of Layer2 Attribute Extended community, PE1, PE2 and 639 PE3 treat each other as valid destination. 641 Packet encapsulation is as below: 643 o PE1 <-- Transport label(s) + EVPN label(s) + CI + FL (BoS) + CW + 644 Payload --> PE2 646 o PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 648 o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 650 In this scenario, when F=1 and CI=1, value of CI MUST be signaled via 651 Control Word Indicator Extended Community. existence of CI is 652 identified via CI value being advertised instead of BoS. existence of 653 FL is identified via CI not being BoS. 655 Another possibility is: PE1 and PE2 announce F=1, PE3 announces F=0. 656 PE1 and PE3 announce C=1 and CI=1, PE2 announces C=0. 658 After validation of Layer2 Attribute Extended community, PE1, PE2 and 659 PE3 treat each other as valid destination. 661 Packet encapsulation is as below: 663 o PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + Payload 664 --> PE2 666 o PE1 <-- Transport label(s) + EVPN label(s) + CI (BoS) + CW + 667 Payload --> PE3 669 o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3 671 In this scenario, when F=1 and CI=1 on PE1, value of CI on PE1 MUST 672 be signaled via Control Word Indicator Extended Community. existence 673 of CI is identified via CI value being advertised instead of BoS. 675 Authors' Addresses 677 Tianpeng Yu (editor) 679 EMail: yutianpeng.ietf@gmail.com 681 Haibo Wang 682 Huawei Technologies 684 EMail: rainsword.wang@huawei.com