BESS Working Group INTERNET-DRAFT Kiran Thimmappa Intended status: Standards Track Commscope Expires: 23 January 2025 22 July 2024 Framework for efficient Service Carving in EVPN Multihoming draft-kiran-bess-service-carving-evpn-multi-homing-00 Abstract This document proposes a new approach for the Designated Forwarder (DF) selection algorithm. This is besides the existing algorithm types discussed in RFC7432 and RFC8584. A DF is a PE part of an Ethernet-Segment, forwarding BUM traffic to multi-homed hosts. This document discusses methods to achieve efficient service carving in Evpn Multi-homed networks by extending the DF selection algorithm type in RFC7432 by suggesting a new approach for service carving. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 January 2025. Kiran Expires 23 January 2025 [Page 1] Internet-Draft DF Election and Service Carving July 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Glossary DF Designated Forwarder NDF Non Designated Forwarder ES Ethernet Segment PE Provider Edge (device) EVPN Ethernet over VPN EVI Evpn Instance Identifier ES-Route Ethernet Segment Route EAD-ES Ethernet Auto Discovery for Ethernet Segment EAD-EVI Ethernet Auto Discovery for an Evpn Instance BFD Bidirectional Forwarding Detection Table of Contents 1. Introduction ................................................ 2 2. Terminology and Notation ..................................... 2 3. Problem Statement ........................................... 2 4. Proposed Solution ........................................... 3 5. Network events impacting service carving .................... 4 Kiran Expires 23 January 2025 [Page 2] Internet-Draft DF Election and Service Carving July 2024 6. Solution benefits ........................................... 8 7. IANA Considerations ......................................... 8 8. Compatibility with RFC8584 .................................. 9 9. Backward compatibility ...................................... 10 10. Security considerations ..................................... 10 11. References .................................................. 11 1. Introduction In vendor implementations as per RFC7432, the default DF election algorithm is used for computing the DF and NDF for an ES which is referred to as "service carving". In post RFC7432, as in RFC8584, a DF extended community is introduced where the PEs of an ES can share their individual preferred DF election type along with their capabilities. If all PEs prefer an identical election type, they proceed with the preferred election type. Even if 1 PE differs from the preferred election type, all PEs revert to default DF election type as mandated in RFC7432. 2. Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Problem statement By default, the EVPN uses a DF election algorithm as described in RFC7432 which is referred to as "service carving". The DF election algorithm is based on a modulus function (V mod N) that takes the number of PEs in the ES (N) and the VLAN value (V) as input. Kiran Expires 23 January 2025 [Page 3] Internet-Draft DF Election and Service Carving July 2024 The ordinal number of the PE matching the result of the modulus operation becomes the DF for the VLAN (V). In this method, efficent service-carving may not be always achieved. As already pointed out in RFC8584, if all vlans are numbered only odd or only even, then only 1 PE gets to become the DF for all vlans based on its ordinal number. Due to this, load-balancing is defeated in the multi-homed PEs where a single PE may end up taking the load of all BUM traffic. This can become critical in scaled Evpn multi-homed networks when handling BUM traffic for vlans running in thousands per ES. 4. Proposed solution This draft proposes a more generic method to achieve efficient Service-carving among PEs of an ES. Dual-homing is taken into consideration as part of this approach and for ease of explanation. But the same idea is extensible when PEs are more than two as well. The procedures specified in RFC7432 and RFC8584 are referenced here to simplify reader's context as and when required. More precisely, this draft proposes a DF election mechanism such that the resulting DFs within the ES achieves maximum service-carving across all PEs in the ES. In existing functional DF behaviors, with 2 PEs, PE1 and PE2, service carving procedures kick start dynamically with expiry of DF hold-down timer. As described in RFC7432, all PEs in ES align themselves in ascending order based on tunnel-ip address and ordinal numbers are assigned accordingly. As part of the new approach, besides assigning of ordinal numbers to the PEs, the received Vlans (from a combination of EAD-ES and EAD-EVI routes) SHOULD be arranged in ascending order. This is on the same lines how ordinal numbers are assigned to the PEs of ES. With Vlans arranged in this order, PE with lowest ordinal number (say PE1) takes up DF role for all Vlans at even numbered places (0,2,4..) and NDF role for vlans at odd numbered places (1,3,5..). PE2 takes up DF responsibility for Vlans in odd numbered places and NDF responsibility for Vlans in even numbered places. Kiran Expires 23 January 2025 [Page 4] Internet-Draft DF Election and Service Carving July 2024 This method (referred as Ordered_Vlan method in this draft) SHOULD be adopted when PEs are booted up with pre-configured multi-homing configurations along with Vlans. Below table depicts the DF and NDF information for an ES across PE1 and PE2 nodes after applying Ordered_Vlan approach as part of DF election. As we can see, irrespective of the vlan values, whether odd or even, they get equally load balanced between the 2 PEs thereby achieving maximum service-carving. PE1 is DF for vlans 10,32,54,76 at even numbered places 0,2,4,6 and NDF for vlans 21,43,65 at odd numbered places 1,3,5. PE2 is DF for vlans 21,43,65 at odd numbered places 1,3,5 and NDF for vlans 10,32,54,76 at even numbered places 0,2,4,6. ----------------------------------------------------------------- |Ordinal| PEs | Provisioned Vlans | DF | NDF | |Number | | | | | |---------------------------------------------------------------- | 0 | PE1 | 10 21 32 43 54 65 76 | 10 32 54 76 | 21 43 65 | |---------------------------------------------------------------- | 1 | PE2 | 10 21 32 43 54 65 76 | 21 43 65 | 10 32 54 76| ----------------------------------------------------------------- Table-1 5. Network events impacting service carving The maximum service-carving obtained via Ordered_Vlan approach should be retained even when dynamic events occur in the network. The below events are discussed - One or more new Vlans getting commissioned into the ES. - One or more existing Vlans getting de-commissioned from the ES. - PE losing connectivity with its ES. - PE goes down or crashes When the above dynamic events occur, following procedural methods are introduced and discussed below to ensure service-carving remains unimpacted. Kiran Expires 23 January 2025 [Page 5] Internet-Draft DF Election and Service Carving July 2024 5.1 New vlan provisioning in the ES Lets say PE1 and PE2 are running with a set of vlans as discussed and shown in Table-1. A new vlan is provisioned on the dual-homed PEs of the ES. Service carving is achieved as described below. The PE meeting the below 2 criteria's becomes DF for new vlan. Rule(1) PE's DF_count <= NDF_count Rule(2) PE's DF_count <= (Total_vlan_count/2) (Note: if (1) and (2) are true, (3) acts as the tie-breaker) Rule(3) PE is first in the ordinal list Ex, PE1 and PE2 are DF and NDF for 2 vlans each for a total of 4 vlans in the ES. When a 5th vlan is provisioned, both (1) and (2) will be true for PE1 and PE2, in this case, (3) ensures PE1 becomes DF. In the above discussed example (refer Table-1), if a new Vlan is provisioned, the above 3 rules ensure PE2 becomes DF for the new Vlan. More specifically, PE1 fails to satisfy Rule (1) and becomes NDF, PE2 satisfies Rules (1) and (2) and becomes DF for the new Vlan. 5.2 Two or more vlans newly provisioned in the ES Suggested new approach: Incremental Service-carving based on the earlier described Ordered_Vlan method. In this case, Ordered_Vlan method SHOULD be followed as there are more than 1 Vlans provisioned. This service-carving is incremental as the Ordered_Vlan method is applied only on newly provisioned Vlans keeping existing Vlans untouched, thus minimizing internal churn within the system of dual-homed PEs. Kiran Expires 23 January 2025 [Page 6] Internet-Draft DF Election and Service Carving July 2024 5.3 One or more provisioned Vlans are de-commissioned in the ES When one or more Vlans are de-commissioned from the PE devices, it MAY create an imbalance in the service-carving status of multi-homed PE devices based on the Vlans de-commissioned. From the service-carving shown in Table-1, if Vlans 43 and 65 are de-commissioned from both PEs, the resulting service-carving status is as shown below. ----------------------------------------------------------------- |Ordinal| PEs | Provisioned Vlans | DF | NDF | |Number | | | | | |---------------------------------------------------------------- | 0 | PE1 | 10 21 32 54 76 | 10 32 54 76 | 21 | |---------------------------------------------------------------- | 1 | PE2 | 10 21 32 54 76 | 21 | 10 32 54 76| ----------------------------------------------------------------- Table-2 As we can see, the service-carving status is sub-optimal in both PEs PE1 and PE2. To mitigate this, a threshold value may be administratively provisioned indicating the tolerance level in the imbalance of the total DF and NDF count of the PEs. If the difference between total DF and NDF count goes beyond this threshold value, both PEs SHOULD re-trigger DF election by applying the Ordered_Vlan method on remaining set of Vlans. This restores service-carving in both PEs of the ES as shown below in Table-3. The operator MUST ensure the same threshold value is configured on all PE devices of the ES. ----------------------------------------------------------------- |Ordinal| PEs | Provisioned Vlans | DF | NDF | |Number | | | | | |---------------------------------------------------------------- | 0 | PE1 | 10 21 32 54 76 | 10 32 76 | 21 54 | |---------------------------------------------------------------- | 1 | PE2 | 10 21 32 54 76 | 21 54 | 10 32 76 | ----------------------------------------------------------------- Table-3 5.4 One of the dual-homed PE loses its ES connectivity Re-trigger DF election in other PE node across all EVIs of the ES. Let say PE1 loses its ES connectivity. PE1 withdraws its ES-Route Kiran Expires 23 January 2025 [Page 7] Internet-Draft DF Election and Service Carving July 2024 from PE2 resulting in PE2 triggering DF re-election and assuming DF role for all vlans for which it was performing NDF role (when PE1 was connected to ES). Meaning, as part of DF selection criterias mandated in RFC7432 and RFC8584, PE2 triggers DF re-election, becomes DF for all vlans for which it was NDF. When PE1 is up again, it sends out ES-Route EAD-ES and EAD-EVI routes to PE2, on receipt of which PE2 SHOULD follow the Ordered_Vlan approach for all Vlans as discussed earlier. PE1 SHOULD follow the same when it receives those routes from PE2. 5.5 One of the dual-homed PE is down or crashes Re-trigger DF election in other PE node across all EVIs of the ES. This is almost similar to the previous event, with the exception that PE2 doesnt receive withdraw of ES-Route from its peer PE1. Meaning, if PE1 goes down, PE2 will realize PE1 is no longer operational only when its BGP neighborship times out or if BFD times out provided BFD is operational between them. As in the previous case, PE2 MUST re-trigger DF election and assume DF role for all vlans for which it was NDF. As part of the DF election criterias mandated in RFC7432 and RFC8584, PE2 becomes DF for all vlans for which it was NDF. Likewise, when PE1 is up, it sends ES-Route, EAD-ES and EAD-EVI routes to PE2, on receipt of which PE2 SHOULD follow Ordered_Vlan approach as discussed earlier. PE1 SHOULD do the same when it receives those routes from PE2. Kiran Expires 23 January 2025 [Page 8] Internet-Draft DF Election and Service Carving July 2024 6. Solution benefits The methods described in this document provides following benefits. It extends the DF election as defined in RFC7432 to address unfair load balancing and potential black-holing issues with the default DF election algorithm. It proposes ways to mitigate unfair load balancing resulting out of commissioning new Vlans or decommissioning of existing Vlans from the PEs of the ES. It proposes to define a new algorithm type referred to as the "DF Election with Service-Carving" as part of the DF-Alg field in the DF Election Extended Community. This allows PEs to signal the new approach as part of its DF election procedures. It is backward compatible with the procedures defined in RFC7432. If one or more PEs in the ES do not support the new procedures, they will all follow DF election as defined in RFC7432. 7. IANA Considerations IANA has setup registry called "DF-Alg" for DF-Alg field in the DF election extended community. The following are the initial values existing in the registry: Alg Name Reference ---- ----------------------------- ------------- 0 Default DF Election RFC 8584 1 HRW Algorithm RFC 8584 2-30 Unassigned 31 Reserved for Experimental Use RFC 8584 Kiran Expires 23 January 2025 [Page 9] Internet-Draft DF Election and Service Carving July 2024 The approach proposed in this document requires a new value to be assigned for explicitly identifying this approach and for communicating the same across all PEs of the ES. Presently, the DF-Alg field holds the following values - Type-0: Default DF election algorithm as defined in RFC7432. - Type-1: HRW (Highest Random Weight) algorithm. - Types 2-30: Unassigned. - Type-31: Reserved for Experimental Use. New value proposed: - Type-2: DF Election with Service-Carving To signal this new approach, need to incorporate this new value as part of the DF-Alg field. For this, a new registration will have to be requested through the "RFC Required" procedure defined in [RFC8126]. With this incorporated, values of the registry will be as follows Alg Name Reference ---- ----------------------------- ------------- 0 Default DF Election RFC 8584 1 HRW Algorithm RFC 8584 2 DF Election with Service-Carving This document 3-30 Unassigned 31 Reserved for Experimental Use RFC 8584 8. Compatibility with RFC8584 The alternatives proposed in this document doesnt impact the using and processing of AC-DF based capabilities as part of current implementations. The implementations can choose to include or exclude AC-DF based capability as part of their DF extended community information. Kiran Expires 23 January 2025 [Page 10] Internet-Draft DF Election and Service Carving July 2024 9. Backward compatibility As suggested in RFC7432, if any one of the PEs in the ES doesnt support this capability of this approach, all PEs can revert back to the default election algorithm type. 10. Security Considerations This document addresses some identified issues in DF election procedures described in RFC7432 and targets to achieve an efficient way of service-carving by defining an alternative approach to existing DF election framework. In general, the proposed framework allows PEs part of the same ES to exchange a new DF-Alg type indicating support of this new framework. By following the procedures in this document, the administrator will achieve efficient service-carving thereby minimizing service disruptions occuring with traffic outage or black-holing. A malicious user's intent to trigger such service disruptions can be negated by this approach. Particularly, a malicious user having access to a PEs configuration can configure Vlan values such that a single PE ends up performing DF role for all Vlans resulting in traffic outage due to interface back-pressures that can occur espeically in scaled scenarios. This approach circumvents this by ensuring maximum service-carving is achieved across all PEs of the ES irrespective of the kind of vlan values configured. This also enables operator to configure Vlan values not bothering about inherent issues within implementations. The operator need not be concerned about odd or even Vlan values being configured for efficient load-balancing of traffic across the PE devices in the ES. Additionally, if new Vlans are commissioned or existing Vlans are de-commissioned, efficient service-carving is still maintained across all PEs of the ES. Finally, it is imperative to note that network will not benefit from the new procedures if the DF election algorithm related configurational parameters are not consistently configured across all PEs of ES. In such a case, all PEs revert back to default DF election algorithm as suggested in RFC7432, as it can negate the service carving and hence become susceptible to a user's malicious intent of service disruption. Kiran Expires 23 January 2025 [Page 11] Internet-Draft DF Election and Service Carving July 2024 In addition, the new framework is extensible and allows for new security enhancements in future. Note that such enhancements are out of scope for this document. Finally, as this document extends the procedures in RFC7432 and RFC8584, the same security considerations as those described in RFC7432 and RFC8584 stands valid for this document. 11 References 11.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8126] M. Cotton, B. Leiba, T Narten, Guidelines for Writing an IANA Considerations Section in RFCs 11.2 Informative References RFC7432 Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . RFC8584 Kiran Nagaraj, Senthil Sathappan, John Drake, Ali Sajassi Satya Mohanty, Jorge Rabadan Author's Address Kiran Thimmappa Commscope Bengaluru India Email: kiran.kalidevapurathimmappa@commscope.com Kiran Expires 23 January 2025 [Page 12]