idnits 2.17.1 draft-yu-bess-evpn-l2-attributes-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (December 5, 2018) is 1969 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: 0 errors (**), 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 Huawei Technologies 4 Intended status: Standards Track December 5, 2018 5 Expires: June 8, 2019 7 EVPN Layer 2 Attributes Extended Community Usage in EVPN 8 draft-yu-bess-evpn-l2-attributes-01 10 Abstract 12 This document aims to define a negotiation mechanism for L2 13 capabilities in an EVPN scenario. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 8, 2019. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specification of Requirements . . . . . . . . . . . . . . . . 2 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 4. EVPN Layer 2 Attributes Extended Community . . . . . . . . . 3 53 5. Usage of Control Flags . . . . . . . . . . . . . . . . . . . 4 54 6. L2 MTU Processing . . . . . . . . . . . . . . . . . . . . . . 7 55 7. Instructions of using control word and Flow Label . . . . . . 7 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 61 1. Introduction 63 EVPN [RFC7432] is lacking a negotiation mechanism on L2 capabilities. 64 If the L2 capabilities between PE devices are different, they are not 65 able to communicate properly. 67 This document aims to define a negotiation mechanism for L2 68 capabilities in an EVPN scenario. 70 2. Specification of Requirements 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 73 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 74 this document are to be interpreted as described in [RFC2119]. 76 3. Terminology 78 EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432] 80 EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN speficies 81 EVPN defined in [RFC7432] 83 CW: Control Word defined in [RFC4448] 85 CI: Control word indicator, defined in Section 4 of this document 87 PE: Provider Edge 89 FL: Flow label, defined in [RFC6391] 91 4. EVPN Layer 2 Attributes Extended Community 93 EVPN Layer 2 Attributes Extended Community is defined in EVPN VPWS 94 [RFC8214]. This document describes the behaviors how it adapts to 95 EVPN ELAN. A mechanism to achieve interoperability between devices 96 with and without CW capabilities is defined. Flow Label mechanism is 97 defined. EVPN Layer 2 Attributes Extended Community is advertised 98 along with Ethernet Auto-discovery. The definition of EVPN Layer 2 99 Attributes Extended Community is same with [RFC8214]. it is listed as 100 below for convenience. 102 +-------------------------------------------+ 103 | Type (0x06) / Sub-type (0x04) (2 octets) | 104 +-------------------------------------------+ 105 | Control Flags (2 octets) | 106 +-------------------------------------------+ 107 | L2 MTU (2 octets) | 108 +-------------------------------------------+ 109 | Reserved (2 octets) | 110 +-------------------------------------------+ 112 Figure 1: EVPN Layer 2 Attributes Extended Community 114 The definition of Control Flags is as below: 116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 117 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ 118 | MBZ |CI|F|C|P|B| (MBZ = MUST Be Zero) 119 +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ 121 Figure 2: Control Flags 123 The P bit and B bit defined in [RFC8214] must be zero when used in 124 EVPN ELAN mode. This is because [RFC7432] has defined ESI Label 125 Extended Community to achieve single-active redundancy mode. 127 C bit indicates the control word enable status of known unicast 128 traffic. C bit MUST set 0 when advertising A-D route if PE has no 129 capability of processing control word. C bit SHOULD be same across 130 all Ethernet Segments within one EVI on a local PE. BUM traffic 131 SHOULD NOT include control word when forwarded no matter C bit is set 132 to 1 or 0 when working in ELAN mode. 134 CI bit is defined to achieve interoperability between devices with 135 and without control word capability. Control Word Indicator is one 136 octet with value 0xFF. CI bit MUST NOT set 1 if C bit is set 0. The 137 usage of CI bit is described in Section 4. 139 F bit is defined to achieve Flow-Aware Transport Labels [RFC6391] in 140 EVPN. It can be used in both EVPN ELAN and VPWS. When F bit is set 141 to 1, the PE announces it has the capability of both sending and 142 receiving flow label. F bit MUST be same across all Ethernet 143 Segments within one EVI on a local PE. BUM traffic SHOULD NOT 144 include Flow label when forwarded no matter F bit is set to 1 or 0 145 when working in ELAN mode. 147 Other bits in Control Flags are reserved for future investigation and 148 MUST be zero. 150 L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes. It 151 MUST be same across all ES within one EVI on a local PE. 153 If local PE does not support EVPN Layer 2 Attributes Extended 154 Community, this community MUST be ignored. 156 When a PE receives A-D routes with C, CI or F bits enabled, the 157 behavior SHOULD be spreaded to all MAC tables towards the 158 corresponding ES when applicable. 160 5. Usage of Control Flags 162 The description below is based on the network topology showed in 163 Figure 3: 165 +--------+ +--------+ 166 | PE1 | | PE2 | 167 | (CW) |-------| (CW) | 168 +--------+ +--------+ 169 \ / 170 \ / 171 +--------+ 172 | PE3 | 173 | (NCW) | 174 +--------+ 176 Figure 3: Network Topology for Control Word Interoperability 178 PE1 and PE2 are routers with control word capability and PE3 is 179 router control word disabled or without control word capability. It 180 is assumed that PE1, PE2 and PE3 are working in same EVI. 182 When local PE receives auto-discovery routes from remote PE, if CI=0, 183 then goes process A, if CI=1, then goes to process B. 185 Process A: 187 Compare the value of C bit with local control word enable status. If 188 same, local PE treats remote PE as a valid EVPN destination. If not 189 same, local PE treats remote PE as an invalid EVPN destination. 190 After such process, PE1 treat PE2 as a valid destination and PE3 as 191 an invalid destination. PE2 treat PE1 as a valid destination and PE3 192 as an invalid destination. PE3 treat both PE1 and PE2 as an invalid 193 destination. PE1 and PE2 will forward traffic with control word 194 encapsulated. PE1 and PE2 will not be able to interoperate with PE3, 195 due to control word status difference. 197 Process B: 199 In this process, if C is set 0, then remote PE is treated as valid 200 EVPN destination. If C is set 1, then only when CI and C bit status 201 is same with local, remote PE is treated as a valid EVPN destination. 202 When local PE forwards a packet to remote PE, if remote PE is control 203 word enabled, then the unicast packet MUST be encapsulated with a 204 control word indicator before control word. If remote PE is control 205 word disabled or no control word capability, then unicast packet is 206 directly encapsulated after MPLS label as payload. 208 For example: 210 PE1 advertises A-D route with CI and C bit set 1, packet forwarding 211 behavior is as below: 213 PE2->PE1: Transport Label + EVPN Label to PE1 + CI + CW + Payload 215 PE3->PE1: Transport Label + EVPN Label to PE1 + Payload 217 PE2 advertises A-D route with CI and C bit set 1, PE3 advertise A-D 218 route with CI and C bit set 0, packet forwarding from PE1 to PE2 and 219 PE3 is as below:: 221 PE1->PE2: Transport Label + EVPN Label to PE2 + CI + CW + Payload 223 PE1->PE3: Transport Label + EVPN Label to PE3 + Payload 225 After a PE receives a packet, after looking into EVPN label, if the 226 first byte is "0xFF", it indicates control word is included behind. 227 If the first byte is not "0xFF", it indicates control word is not 228 included behind. 230 The control word interoperability mechanism described above is not 231 applicable to EVPN VPWS, it is applicable to EVPN ELAN. 233 When working in EVPN VPWS mode, in case of C bit status is not 234 consistent on both ends, VPWS SHOULD be teared up and behave like 235 control word not enabled. 237 +--------+ +--------+ 238 | PE1 | | PE2 | 239 | (FL) |-------| (FL) | 240 +--------+ +--------+ 241 \ / 242 \ / 243 +--------+ 244 | PE3 | 245 | (NFL) | 246 +--------+ 248 Figure 4: Network Topology for Flow Label Interoperability 250 Flow label is introduced allowing to archieve better load-balancing 251 in the network in conditions mentioned below: 253 o Services in EVPN instance is not sensitive to misordering. 255 o Transit network has no capability parsing payload inside MPLS 256 label as hash factor. 258 PE1 and PE2 are routers with flow label capability and flow label 259 enabled and PE3 is router flow label disabled or without flow label 260 capability. It is assumed that PE1, PE2 and PE3 are working in same 261 EVI. 263 When local PE receives auto-discovery routes from remote PE, F bit 264 does not impact validation process of EVPN auto-discovery routes. 265 Even F bit of remote PE does not match with local status, local PE 266 SHOULD still add remote PE as a valid EVPN destination. 268 When sending traffic from PE1 towards PE2 and PE3, as PE1 has already 269 learnt the FL status of PE2 and PE3, packet encapulation is as below: 271 PE1->PE2: Transport Label + EVPN Label to PE2 + FL + Payload 273 PE1->PE3: Transport Label + EVPN Label to PE3 + Payload 275 When sending traffic from PE2 and PE3 towarding PE1, packet 276 encapulation is as below: 278 PE2->PE1: Transport Label + EVPN Label to PE1 + FL + Payload 280 PE3->PE1: Transport Label + EVPN Label to PE1 + Payload 281 When PE1 recieves packets, after looking at EVPN label, it can be 282 both bottom of stack or not. When EVPN label is bottom of stack, and 283 flow label enabled locally, packet MUST be treated as valid and parse 284 following bytes as payload. 286 The flow label mechanism described above is applicable to both EVPN 287 ELAN and EVPN VPWS. 289 When interoperating with devices not supporting EVPN Layer 2 290 Attributes Extended Community, A-D routes received will not contain 291 such community. Local PE MAY assume the behavior of all remote PE is 292 same with local. 294 When data plane is not using MPLS, all bits in control flags MUST be 295 0. Control word and Flow Label are only applicable to MPLS data 296 plane. 298 6. L2 MTU Processing 300 If a non-zero MTU attribute is received, it MUST be checked against 301 local MTU value if the local value is not zero. If there is a 302 mismatch, the local PE MUST NOT add the remote PE as the EVPN 303 destination. 305 7. Instructions of using control word and Flow Label 307 In EVPN, CW is used avoid misordering caused by transit node using 308 MPLS payload as hash factor. The detailed reason of this refers to 309 [RFC8469]. CW is mandatory for an EVPN carrying misordering 310 sensitive service, when CW is not available, mitigations described in 311 section 6 of [RFC8469] also apply to EVPN. 313 Flow Label MUST NOT be used in EVPN carrying services sensitive to 314 misordering. Flow Label MAY be used to achieve better load-balancing 315 in network, when transit node has no capability to look inside MPLS 316 payload as hash factor. 318 It has been recognized that some transit nodes treat payload after 319 MPLS label as MAC address info and use as hash factor directly. When 320 it is bearing services sensitive to misordering, such load balancing 321 function MUST be disabled, otherwise control word will be treated as 322 part of MAC address mistakenly. 324 Similarly, entropy label [RFC6790] MUST NOT be used in EVPN carrying 325 services sensitive to misordering. 327 8. Security Considerations 329 There are no new security considerations due to the text of this 330 document. 332 9. IANA Considerations 334 This document does not make any requests from IANA. 336 10. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, 340 DOI 10.17487/RFC2119, March 1997, 341 . 343 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 344 "Encapsulation Methods for Transport of Ethernet over MPLS 345 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 346 . 348 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 349 Regan, J., and S. Amante, "Flow-Aware Transport of 350 Pseudowires over an MPLS Packet Switched Network", 351 RFC 6391, DOI 10.17487/RFC6391, November 2011, 352 . 354 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 355 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 356 RFC 6790, DOI 10.17487/RFC6790, November 2012, 357 . 359 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 360 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 361 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 362 2015, . 364 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 365 Rabadan, "Virtual Private Wire Service Support in Ethernet 366 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 367 . 369 [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to 370 Use the Ethernet Control Word", RFC 8469, 371 DOI 10.17487/RFC8469, November 2018, 372 . 374 Author's Address 376 Tianpeng Yu 377 Huawei Technologies 379 EMail: yutianpeng.ietf@gmail.com