idnits 2.17.1 draft-yu-bess-evpn-mass-withdraw-02.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). == 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 'MUST not' in this paragraph: When a remote PE (PE2) receives EAD containing EVPN Administrative Group Community from PE1, it first check if the corresponding (v)ES exists in the same EVI, If the (v)ES does not exist on the remote PE (PE2), the remote PE maintains a relationship between the Administrative Group and the MAC/IP routes from the corresponding (v)ES. This procedure colors the MAC/IP routes with Administrative Group. If the (v)ES exists on PE2 within the same EVI, PE2 MUST not maintain the color relationship between AG and following MAC/IP routes from PE1, as PE1 and PE2 belongs to the same multi-homed (v)ES and a failure of (v)ES in PE1 does not requires withdraw of PE2. The MAC/IP route is applicable to usage defined in [RFC7432] and also ARP/ND proxy usage defined in [I-D.ietf-bess-evpn-proxy-arp-nd] -- The document date (June 20, 2019) is 1766 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 313, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-bess-evpn-proxy-arp-nd-06 == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-virtual-eth-segment-04 Summary: 0 errors (**), 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 3 Internet-Draft June 20, 2019 4 Intended status: Standards Track 5 Expires: December 22, 2019 7 EVPN Enhanced Mass Withdraw 8 draft-yu-bess-evpn-mass-withdraw-02 10 Abstract 12 This document aims to define an enhanced mass withdraw process in 13 case of failure of multiple ESs or vESs. This document also improves 14 the withdraw efficiency of failure of single-homed ES or vES. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 22, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Solution Description . . . . . . . . . . . . . . . . . . . . 4 54 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 59 8.2. Informative References . . . . . . . . . . . . . . . . . 8 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 62 1. Introduction 64 EVPN [RFC7432] defines a mass withdraw mechanism to efficiently and 65 quickly signal to remote PE nodes in case of a connection to ES 66 fails. But there are particular scenarios that cannot be covered by 67 [RFC7432]: 69 Multi-homed scenario: 71 o EVC scenario (described in section 1.1 of 72 [I-D.ietf-bess-evpn-virtual-eth-segment]): 74 * Failure of physical port leads to failure of multiple multi- 75 homed vESs aggregating EVC. 77 * Failure of LAG leads to failure of multiple multi-homed vESs 78 aggregating EVC. 80 o PW scenario (described in section 1.2 of 81 [I-D.ietf-bess-evpn-virtual-eth-segment]): 83 * Failure of PW leads to failure of multiple multi-homed vESs in 84 EVPN. One of the example is: PW is using RAW mode (section 85 4.4.1 of [RFC4448]), with multiple VLAN services inside, and 86 EVPN is using vlan-based interface and the services. This 87 scenario is called "PW 1:N" in the following context of this 88 document. 90 * Failure of PW leads to failure of particular VLAN(s) in EVPN. 91 One of the example is: a couple of PWs terminated by a EVPN 92 using vlan-aware-bundle interface. This scenario is called "PW 93 N:1" in the following context of this document. 95 o A single point of failure leads to failure of multiple ESs/vESs 96 (e.g. failure of a line-card). 98 The mass withdraw mechanism MUST handle both single-active and 99 active-active multi-homed vES in scenarios described above. 101 Single-homed scenario: 103 o A failure of single-homed ES or vES interface requires a per-MAC 104 based flush, which brings burden to the control plane. 106 o EVC scenario: 108 * Failure of physical port leads to failure of multiple single- 109 homed vESs aggregating EVC. 111 * Failure of LAG leads to failure of multiple single-homed vESs 112 aggregating EVC. 114 o PW scenario: 116 * Failure of PW leads to failure of multiple single-homed vESs in 117 EVPN. 119 * Failure of PW leads to failure of particular VLAN(s) in EVPN. 121 o A single point of failure leads to failure of multiple single- 122 homed ESs/vESs (e.g. failure of a line-card). 124 The mass withdraw mechanism SHOULD handle a huge number of ES/vES. 125 Convergence mechanism independent of number of (v)ES and MAC/IP 126 routes is preferred when possible. 128 2. Specification of Requirements 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 131 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 132 this document are to be interpreted as described in [RFC2119]. 134 3. Terminology 136 EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432] 138 EVI: EVPN Instance 140 EVPN VPWS: Refers to [RFC8214] 141 vES: Virtual Ethernet Segment 142 [I-D.ietf-bess-evpn-virtual-eth-segment] 144 EVC: Ethernet Virtual Circuit 146 PW: Pseudowire 148 4. Solution Description 150 To achieve a fast convergence time in case of multiple (v)ES fails, a 151 concept of Administrative Group (AG) is introduced into EVPN. (v)ESs 152 belonging to the same failure domain will be set with the same 153 Administrative Group. A (v)ES MAY have more than one Administrative 154 Groups. 156 A new EVPN BGP Extended Community called EVPN Administrative Group 157 Community is defined as below. This new extended community is a 158 transitive extended community with the Type field of 0x06 (EVPN) and 159 the Sub-Type of TBD. 161 This community MUST be ignored if not supported on the the receiving 162 PE. 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type=0x06 | Sub-Type=TBD | Flags(1 octet)| Type(1 octet) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Administrative Group | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: EVPN Administrative Group Extended Community 173 EVPN Administrative Group Extended community is included along with 174 EAD route when applicable. But it needs to be included with MAC/IP 175 Advertisement Route instead of EAD route in single-homed (v)ES and PW 176 N:1 scenario. 178 When a remote PE (PE2) receives EAD containing EVPN Administrative 179 Group Community from PE1, it first check if the corresponding (v)ES 180 exists in the same EVI, If the (v)ES does not exist on the remote PE 181 (PE2), the remote PE maintains a relationship between the 182 Administrative Group and the MAC/IP routes from the corresponding 183 (v)ES. This procedure colors the MAC/IP routes with Administrative 184 Group. If the (v)ES exists on PE2 within the same EVI, PE2 MUST not 185 maintain the color relationship between AG and following MAC/IP 186 routes from PE1, as PE1 and PE2 belongs to the same multi-homed (v)ES 187 and a failure of (v)ES in PE1 does not requires withdraw of PE2. The 188 MAC/IP route is applicable to usage defined in [RFC7432] and also 189 ARP/ND proxy usage defined in [I-D.ietf-bess-evpn-proxy-arp-nd] 191 For the scenarios mentioned that AG being included in MAC/IP route, 192 if ESI is not all 0 (multi-homed), after checking the existence of 193 (v)ES in the same EVI, the color relationship is directly retrieved 194 from the MAC/IP route. If ESI is all 0 (single-homed), then 195 existence validation of the (v)ES is not required. 197 The 1 octet type field is defined to distinguish different types of 198 Administrative Group to avoid overlap of the values across each 199 other: 201 o Type 0 (0x00): This type indicates the Administrative Group is 202 managed and configured by the operator. 204 o Type 1 (0x01): The Administrative Group is retrieved via ifindex 205 of the interface (applicable to both physical and LAG interface). 206 Refer to [RFC2863] for the usage of ifindex. 208 o Type 2 (0x02): The Administrative Group is retrieved via ID of the 209 PW the EVPN is terminating. 211 o Type 3 (0x03): The Administrative Group is retrieved via service 212 instance identifier of EVPN VPWS the EVPN is terminating. There 213 is also a scenario that EVPN ELAN is terminating EVPN VPWS instead 214 of FEC128-based [RFC4762] or FEC129-based [RFC6074] PW, in such 215 case the Administrative Group is retrieved via service instance 216 identifier which is defined in [RFC8214]. 218 o Type 4 (0x04): The Administrative Group is retrieved via Ethernet 219 Tag ID of the EVPN is terminating. One example of using this is 220 failure or disabling of particular VLAN in a vlan-aware-bundle 221 interface. 223 o Self-defined (0xF0~0xFF): These values are used for proprietary 224 implementations to retrieve system parameters to generate self- 225 defined value of the Administrative Group. An example is to use a 226 type in this range to color the MAC address with ID of the line- 227 card, which is a single-point-of-failure of a series of (v)ESs. 228 In case of failure of the line-card, a withdraw message with the 229 self-defined type plus ID of the line-card can be sent to remote 230 PE to withdraw all impacted (v)ESs. The remote PE is not required 231 to understand the meaning of self-defined type. There is no 232 difference on the coloring and flushing procedure when using self- 233 defined type. 235 Examples are given below to demonstrate the usage of Administrative 236 Group. 238 o Example 1: vES1~vES1000 are under the same LAG interface, and are 239 used to terminate EVC. In such case, these vESs belong to the 240 same AG, the identifier of the AG is the ifindex of the LAG. 242 o Example 2: vES1001~vES2000 are terminating the same RAW PW. In 243 such case, these vESs belong to the same AG, the identifier of the 244 AG is set to the PW-ID. 246 o Example 3: vES2001 is a vlan-aware-bundle service interface in an 247 EVPN, and terminating VLAN 3000~3100 (PW N:1 scenario). Each VLAN 248 is accessed via a corresponding PW. In case of failure of a PW, 249 only a VLAN under the vES is impacted. So the vES requires an AG 250 for each PW with index of PW-ID (type 2). In this case, the AG 251 community is included in MAC/IP routes instead of EAD route. 253 The 1 octet flags field is defined as below: 255 o Value 1 (0x01): Means "flush-all-from-me". When a remote PE 256 receives a withdraw message with flags=0x01, a MAC flush procedure 257 for MAC colored with the corresponding AG in the withdraw message 258 is executed on both control and forwarding plane. For a single- 259 homed (v)ES, this procedure withdraws the MAP/IP routes from 260 remote PEs. For a multi-homed (v)ES, after the withdraw of the 261 failed (v)ES and flush procedure of remote PEs, the MAC address 262 will be learned again from other active (v)ES and advertised to 263 the remote PEs. 265 o Value 2 (0x02): Means "frr-all-from-me". Only when the MPLS label 266 assigned in the MAC/IP Address route of the source PE is not 267 mapped to more than one Administrative Group, the flag is allowed 268 be set to 0x02. For example, a PE is using label assignment per 269 , and the Administrative Group is retrieved via 270 Type 1 (ifindex). In such case, the remote PE can identify the 271 impacted ES and set the corresponding MPLS label as invalid 272 without impact on traffic of other ESs under other interfaces 273 within the same EVI. Another example is per based, with 274 this assignment method, the other (v)ESs without failure is 275 impacted if remote PE set the label invalid. For detailed 276 information on the assignment of label in MAC/IP Address route, 277 refer to section 9.2.1 of [RFC7432]. When a remote PE receives a 278 withdraw message with flags=0x02, it requires a validation of 279 existence of aliasing labels. If the aliasing label (section 8.4 280 of [RFC7432]) does not exist, the procedure downgrades to "flush- 281 all-from-me". If the aliasing label exists, the PE should process 282 a Fast-Re-Route procedure, directly set the MPLS label of impacted 283 (v)ES to invalid on the control and forwarding plane. This will 284 speed up the convergence time and independent of amount of MAP/IP 285 routes. At the same time, the remote PE needs to start a timer 286 (T0) on control plane, to mark the corresponding MAP/IP routes to 287 "polluted" status. During T0, if new MAC/IP routes are learned 288 via other multi-homed PEs, update the routing table and clear the 289 "polluted" flag of corresponding MAC/IP routes. After T0 expires, 290 MAC/IP routes with "polluted" flag SHOULD be cleared on both 291 control plane and forwarding plane. The length of T0 SHOULD be 292 configurable and RECOMMENDED to be equal to MAC aging time. 294 To construct a flushing message, ESI of the EAD route filled with 295 MAX-ESI, Ethernet Tag and MPLS field with all 0 and the 296 Administrative Group Community together with a list of Route Targets 297 corresponding to the impacted service instances. If the number of 298 Route Targets is more than they can fit into a single attribute, then 299 can split the RTs into multiple messages with same Administrative 300 Group Community attached. 302 5. Acknowledgments 304 TBD 306 6. Security Considerations 308 TBD 310 7. IANA Considerations 312 IANA is requested to allocate a new "EVPN Extended Community Sub- 313 Types" registry defined in [RFC7153] as follow: 315 SUB-TYPE NAME Reference 316 ------------------------------------------------------------------- 317 TBD EVPN Administrative Group Community This document 319 This document creates registry below. 321 Administrative Group Type: 323 Value Meaning Reference 324 --------------------------------------------------------------------- 325 0x00 Manually managed Administrative Group This document 326 0x01 AG is retrieved via ifindex This document 327 0x02 AG is retrieved via ID of PW This document 328 0x03 AG is retrieved via EVPN service instance id This document 329 0x04 AG is retrieved via Ethernet Tag ID of EVPN This document 330 0xF0~0xFF Reserved for proprietary implementation This document 331 Administrative Group Flags: 333 Value Meaning Reference 334 --------------------------------------------------------------------- 335 0x01 Flush-all-from-me This document 336 0x02 FRR-all-from-me This document 338 8. References 340 8.1. Normative References 342 [I-D.ietf-bess-evpn-proxy-arp-nd] 343 Rabadan, J., Sathappan, S., Nagaraj, K., Henderickx, W., 344 Hankins, G., King, T., Melzer, D., and E. Nordmark, 345 "Operational Aspects of Proxy-ARP/ND in EVPN Networks", 346 draft-ietf-bess-evpn-proxy-arp-nd-06 (work in progress), 347 April 2019. 349 [I-D.ietf-bess-evpn-virtual-eth-segment] 350 Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. 351 Rabadan, "EVPN Virtual Ethernet Segment", draft-ietf-bess- 352 evpn-virtual-eth-segment-04 (work in progress), January 353 2019. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 361 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 362 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 363 2015, . 365 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 366 Rabadan, "Virtual Private Wire Service Support in Ethernet 367 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 368 . 370 8.2. Informative References 372 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 373 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 374 . 376 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 377 "Encapsulation Methods for Transport of Ethernet over MPLS 378 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 379 . 381 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 382 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 383 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 384 . 386 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 387 "Provisioning, Auto-Discovery, and Signaling in Layer 2 388 Virtual Private Networks (L2VPNs)", RFC 6074, 389 DOI 10.17487/RFC6074, January 2011, 390 . 392 Author's Address 394 Tianpeng Yu 396 EMail: yutianpeng.ietf@gmail.com