Framework for efficient Service Carving in EVPN Multihoming
draft-kiran-bess-service-carving-evpn-multi-homing-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]     Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[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, <https://www.rfc-editor.org/info/rfc7432>.

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]