RFC 9541

Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)

📅 published March 2024, from ietf

RFC 9541: Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN) 🎀

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Request for Comments: 9541
  • Authors: J. Rabadan (Ed.), S. Sathappan, and K. Nagaraj from Nokia, plus M. Miyake and T. Matsuda from Softbank 👑
  • Category: Standards Track 🦋
  • ISSN: 2070-1721
  • Date: March 2024 🌈
  • Obsoletes / Updates: nothing! This header doesn't list any RFCs it obsoletes or updates 💅

Abstract ✨

Okay so, Provider Backbone Bridging (PBB) can team up with Ethernet Virtual Private Networks (EVPNs) to run Ethernet Local Area Network (E-LAN) services across big Multiprotocol Label Switching (MPLS) networks. We call that combo "PBB-EVPN" 🫶. Single-Active multihoming and per Service Instance Identifier (I-SID) load-balancing can be offered to access devices and aggregation networks.

To make the network converge faster when Single-Active multihomed Ethernet Segments (ESs) fail, PBB-EVPN has a flush mechanism for Customer MACs (C-MACs) called "C-MAC flush." It works with different Ethernet Segment Backbone MAC (B-MAC) address allocation models 🔥.

This document adds to those C-MAC flush procedures for the cases where no PBB-EVPN ESs are defined (so the attachment circuit is tied to a zero Ethernet Segment Identifier (ESI)) and where the C-MAC flush needs I-SID-level granularity 🍓.

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). You can find more about Internet Standards in Section 2 of RFC 7841 ✨.

For info on the current status of this document, any errata, and how to send feedback, check out https://www.rfc-editor.org/info/rfc9541 💜.

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) as they stand on the date this document is published. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty, as described in the Revised BSD License.

Table of Contents 🌸

1.  Introduction
  1.1.  Abbreviations
  1.2.  Terminology and Conventions
2.  Solution Requirements
3.  EVPN BGP Encoding for I-SID-Based C-MAC Flush
4.  Solution Description
  4.1.  I-SID-Based C-MAC Flush Activation Procedures
  4.2.  C-MAC Flush Generation
  4.3.  C-MAC Flush Process upon Receiving a C-MAC Flush
        Notification
5.  Conclusions
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 💖

Okay, so [RFC7623] explains how PBB can be combined with EVPNs to deploy E-LAN services in very large MPLS networks. It also describes how Single-Active multihoming and per-I-SID load-balancing can be provided to access devices and aggregation networks. When Access Ethernet and/or MPLS networks exist, [EVPN-VIRTUAL-ES] describes how virtual Ethernet Segments (ESs) can be associated with a group of Ethernet Virtual Circuits (EVCs) or even pseudowires (PWs). To speed up convergence when Single-Active multihomed ESs fail, [RFC7623] defines a Customer MAC flush mechanism that works with different ES B-MAC address allocation models 🦋.

Now here's the thing 👀. Sometimes the admins who run the access devices or aggregation networks don't ask the PBB-EVPN provider for multihomed ESs. They just ask for multiple single-homed ESs. Single-homed ESs use null ESIs, while multihomed ESs use non-null ESIs. If you go with single-homed ESs, the PBB-EVPN network no longer knows about the redundancy that the access administrative entity offers 😭. Figure 1 shows an example where the PBB-EVPN network provides four different Attachment Circuits (ACs) for I-SID1, and none of those ACs are part of any ES or virtual ES. (That's why they're called null virtual Ethernet Segments.)

<----G.8032----><--PBB-EVPN Network-----><----MPLS---->
     Access          MPLS                Access
      Ring                               Network
I-SID1      ESI +------+         +------+
+----+      null| PE1  |---------| PE3  |
|CE1 |----------|B-MAC1|         |B-MAC3| ESI null
+----+    active|      |         |      |----+ PW
  |             +------+         +------+     \active
  |               |                 |          \  +----+
  |               |                 |           ==|CE3 |I-SID1
  |               |                 |          /  +----+
  |standby  ESI +------+         +------+     / PW
+----+      null| PE2  |         | PE4  |----+ standby
|CE2 |----------|B-MAC2|         |B-MAC4| ESI null
+----+    active|      |---------|      |
I-SID1          +------+         +------+

            Figure 1: PBB-EVPN and Non-ES-Based Redundancy

In the Figure 1 example, CE1, CE2, and CE3 are all attached to the same service, identified by I-SID1, on the PBB-EVPN PEs. CE1 and CE2 connect to the PEs using "Ethernet ring protection switching" as specified in [G.8032], and their ACs to PE1 and PE2 are represented by a port and VLAN identifier. CE3 is dual-homed to PE3 and PE4 through an active/standby PW, and its AC to the PEs is represented by a PW. Each of the four PEs uses its own dedicated Backbone MAC address as a source MAC address (B-MAC1, B-MAC2, B-MAC3, and B-MAC4, respectively) when it encapsulates customer frames in PBB packets and forwards them to the remote PEs as per [RFC7623] 🌈.

There are no multihomed ESs defined in the PBB-EVPN network of this example. That's why the four ACs in Figure 1 show the text "ESI null," which means the Ethernet Segment Identifier on those ACs is zero. Since no multihomed ESs are defined, the PEs keep their ACs active as long as the physical connectivity is up. The CEs handle the redundancy, avoid loops, and provide per-I-SID load-balancing to the PBB-EVPN network. Examples of CEs managing their own redundancy are described in [G.8032], or in [RFC4762] for active/standby PWs 🧚.

For instance, in normal conditions, CE2 blocks its link to CE1, and CE3 blocks its forwarding path to PE4. In this situation, a failure in one of the redundant ACs triggers the CEs to start using their redundant paths. However, those failures will not trigger any C-MAC flush procedures in the PEs that implement [RFC7623], because the PEs aren't using the PBB-EVPN multihoming procedures. For example:

  • If the active PW from CE3 (to PE3) fails, and the failure is due to the entire PE3 node failing, then the procedures in [RFC7623] guarantee that all the remote PEs flush all the C-MACs associated with B-MAC3 (the B-MAC of PE3). In this case, CE3 detects the fault because the PW goes operationally down.
  • However, if the active PW from CE3 (to PE3) fails while PE3 is still operationally up, then, following the procedures in [RFC7623], neither PE3 nor PE4 issue a C-MAC flush message. So the remote PEs keep pointing at PE3's B-MAC to reach CE3's C-MACs, until those C-MACs age out in the I-SID1 forwarding tables. In this case, PE3 may use any of the existing PW notifications so that CE3 switches the active PW to PE4 🙈.
  • The same issue shows up when the active PW from CE3 switches over from PE3 to PE4 due to a manual operation on CE3. In other words, neither PE3 nor PE4 triggers any C-MAC flush notification, and the remote PEs keep sending traffic to PE3 until the C-MACs age out 💀.

[RFC7623] provides a C-MAC flush solution based on a shared B-MAC update, along with the MAC Mobility extended community where the sequence number is incremented. But that procedure is only used along with multihomed ESs. Even if it could be used for null ESs, as in the Figure 1 example, the Customer MAC flush procedure in [RFC7623] would end up unnecessarily flushing unaffected I-SIDs on the remote PEs, followed by flooding of unknown unicast traffic across the network. For instance, when CE3 switches its active PW over to PE4, a possible solution that reuses the existing C-MAC flush notifications in [RFC7623] is for PE3 to issue an update for the MAC/IP Advertisement route of B-MAC3 with a higher sequence number. But this update would cause unnecessary Customer MAC flushing for all the I-SIDs attached to PE3 (assuming PE3 has multiple I-SIDs), rather than only I-SID1 😤.

This document extends the Customer MAC flush procedures in [RFC7623], so that in the failure example above, PE3 can trigger a Customer MAC flush notification that makes PE1, PE2, and PE4 flush all the Customer MACs associated with PE3's B-MAC3 and (only) I-SID1 ✨. To do that, this specification introduces the encoding of the I-SID in the MAC/IP Advertisement routes advertised for the B-MACs. The C-MAC flush procedure explained in this document is referred to as "PBB-EVPN I-SID-based C-MAC flush," and it can be used in PBB-EVPN networks with null or non-null (virtual) ESs 🦋.

This specification assumes that the reader is familiar with the procedures in [RFC7623].

1.1. Abbreviations 🔤

  • AC: Attachment Circuit
  • B-MAC: Backbone MAC
  • CE: Customer Edge
  • C-MAC: Customer MAC
  • ES: Ethernet Segment
  • ESI: Ethernet Segment Identifier
  • EVI: EVPN Instance
  • EVPN: Ethernet Virtual Private Network (as in [RFC7432])
  • I-SID: Service Instance Identifier
  • MAC: Media Access Control
  • MAC-VRF: MAC Virtual Routing and Forwarding
  • PBB-EVPN: Provider Backbone Bridging and EVPN (as in [RFC7623])
  • PE: Provider Edge

1.2. Terminology and Conventions 🌸

Familiarity with the terminology in [RFC7623] is expected.

  • B-MAC/0 route: This is an EVPN MAC/IP Advertisement route that uses a B-MAC in the MAC address field and a zero Ethernet Tag ID.
  • B-MAC/I-SID route: This is an EVPN MAC/IP Advertisement route that uses a B-MAC in the MAC address field and an I-SID in the Ethernet Tag field. It is used to notify remote PEs about the required C-MAC flush procedure for the C-MACs associated with the advertised B-MAC and I-SID 🧚.
  • G.8032: Refers to Ethernet ring protection switching as described in [G.8032].

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 💅.

2. Solution Requirements ✨

okay so bestie, this part is where the solution lays out its ground rules 💅 The C-MAC flush solution in this document follows these requirements:

a. The solution MUST prevent packet-loss scenarios in case of failures on null ES ACs (Attachment Circuits not associated with an ES; that is, their corresponding ESI is zero) when the access device or access network is responsible for the redundancy. 🛡️

b. This extension described in this document MUST work with Single-Active non-null ESs and virtual ESs, irrespective of the PE B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC, as in [RFC7623]). 🦋

c. In case of failure on the egress PE, the solution MUST provide a C-MAC flush notification at the B-MAC and I-SID granularity level. 🎀

d. The solution MUST provide a reliable C-MAC flush notification in PBB-EVPN networks that use Route Reflectors (RRs). MAC flushing needs to be provided to all affected I-SIDs in spite of the BGP flush notification messages being aggregated at the RR. 👑

e. The solution MUST coexist in [RFC7623] networks where there are PEs that do not support this specification. 🫶

f. The solution SHOULD be enabled or disabled by an administrative option on a per-PE and per-I-SID basis (as opposed to always being enabled for all the I-SIDs). 🌸

3. EVPN BGP Encoding for I-SID-Based C-MAC Flush 🧚

ngl this is the fun part 😭 The solution doesn't add any new BGP attributes. Instead it reuses the MAC Mobility extended community as an indication of C-MAC flush (as in [RFC7623]) and encodes the I-SID in the Ethernet Tag field of the EVPN MAC/IP advertisement route. For reference, Figure 2 shows the MAC Mobility extended community and the EVPN MAC/IP advertisement route that are used as specified in [RFC7432] and used in this document as a C-MAC flush notification message.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=0x06     | Sub-Type=0x03 |   Flags       |   Reserved=0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               +---------------------------------------+
               |  Route Distinguisher                  |
               +---------------------------------------+
               |  ESI = 0                              |
               +---------------------------------------+
               |  Ethernet Tag ID = I-SID              |
               +---------------------------------------+
               |  MAC Address Length = 48              |
               +---------------------------------------+
               |  B-MAC Address                        |
               +---------------------------------------+
               |  IP Address Length = 0                |
               +---------------------------------------+
               |  MPLS Label1                          |
               +---------------------------------------+

       Figure 2: C-MAC Flush Notification Encoding: B-MAC/I-SID Route

Where:

  • The route's route distinguisher and route targets are the ones corresponding to its EVI. Alternatively to the EVI's Route Target (RT), the route MAY be tagged with an RT auto-derived from the Ethernet Tag (I-SID) instead. [RFC7623] describes how the EVPN MAC/IP Advertisement routes can be advertised along with the EVI RT or an RT that is derived from the I-SID. 💜
  • The Ethernet Tag encodes the I-SID. This indicates to the PE that it must flush the C-MACs for that encoded I-SID, upon reception of the route. 🍓
  • The MAC address field encodes the B-MAC address. This indicates to the PE that it must flush the C-MACs associated with that encoded B-MAC, upon reception of the route. 🌈
  • The MAC Mobility extended community is used as in [RFC7623], where an increment in the sequence number between two updates for the same B-MAC/I-SID will be interpreted as a C-MAC flush notification for the corresponding B-MAC and I-SID. ⭐

All the other fields are set and used as defined in [RFC7623]. This document will refer to this route as the "B-MAC/I-SID route", as opposed to the EVPN MAC/IP Advertisement route used in [RFC7623] that contains a specific B-MAC and the Ethernet Tag ID set to zero. This document uses the term "B-MAC/0 route" to represent a B-MAC route advertised with an Ethernet Tag ID = 0. 🦋

Note that this B-MAC/I-SID route will be accepted and reflected by any RR as specified in [RFC7432], since no new attributes or values are used. A PE receiving the route will process the received B-MAC/I-SID update only in the case of supporting the procedures described in this document. 🫧

4. Solution Description 🌷

Figure 1 is used in the description of the solution. CE1, CE2, and CE3 are connected to ACs associated with I-SID1, where no (multihomed) ESs have been enabled, and the ACs and PWs are in active or standby state as per Figure 1.

Enabling or disabling I-SID-based C-MAC flush SHOULD be an administrative choice on the system that MAY be configured per I-SID (I-Component, Service Instance Component), as opposed to being configured for all I-SIDs. When enabled on a PE:

a. The PE will be able to generate B-MAC/I-SID routes as C-MAC Flush notifications for the remote PEs. 📣

b. The PE will be able to process B-MAC/I-SID routes received from remote PEs. 📥

The PE MUST follow the procedures in [RFC7623] for C-MAC flush. This specification provides some additional procedures when I-SID-based C-MAC flush is enabled.

This C-MAC flush specification is described in three sets of procedures:

  • I-SID-based C-MAC flush activation
  • C-MAC flush notification generation upon AC failures
  • C-MAC flush process upon receiving a C-MAC flush notification

4.1. I-SID-Based C-MAC Flush Activation Procedures 🎀

The following behavior MUST be followed by the PBB-EVPN PEs following this specification. Figure 1 is used as a reference.

  • As in [RFC7623], each PE advertises a shared B-MAC in a B-MAC/0 route (with B-MAC1, B-MAC2, B-MAC3, and B-MAC4 in the MAC address field, respectively). This is the B-MAC that each PE will use as B-MAC SA (Source Address) when encapsulating the frames received on any local single-homed AC. Each PE will import the received B-MAC/0 routes from the remote PEs and will install the B-MACs in its B-component (Backbone Component) MAC-VRF. For instance, PE1 will advertise B-MAC1/0 and will install B-MAC2, B-MAC3, and B-MAC4 in its MAC-VRF. 🌸
  • Assuming I-SID-based C-MAC flush is activated for I-SID1, the PEs will advertise the shared B-MAC with I-SID1 encoded in the Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will receive B-MAC2/1, B-MAC3/1, and B-MAC4/1. The receiving PEs MUST use these B-MAC/I-SID routes only for C-MAC flush procedures and they MUST NOT be used to add/withdraw any B-MAC entry in the MAC-VRFs. As per [RFC7623], only B-MAC/0 routes can be used to add/withdraw B-MACs in the MAC-VRFs. 🙈
  • The above procedure MAY also be used for dedicated B-MACs (B-MACs allocated per ES). 🧚

4.2. C-MAC Flush Generation 💖

If, for instance, there is a failure on PE1's AC, PE1 will generate an update including B-MAC1/1 along with the MAC Mobility extended community where the Sequence Number has been incremented. The reception of the B-MAC1/1 with an increment in the sequence number will trigger the C-MAC flush procedures on the receiving PEs.

  • An AC going operationally down MUST generate a B-MAC/I-SID with a higher Sequence Number. If the AC going down makes the entire local I-SID go operationally down, the PE will withdraw the B-MAC/I-SID route for the I-SID. 📉
  • An AC going operationally up SHOULD NOT generate any B-MAC/I-SID update, unless it activates its corresponding I-SID, in which case the PE will advertise the B-MAC/I-SID route. 📈
  • An AC receiving a G.8032 flush notification or a flush message in any other protocol from the access network MAY propagate it to the remote PEs by generating a B-MAC/I-SID route update with a higher Sequence Number. 📨

4.3. C-MAC Flush Process upon Receiving a C-MAC Flush Notification 🦋

A PE receiving a C-MAC flush notification will follow these procedures:

  • A received B-MAC/I-SID route (with a non-zero I-SID) MUST NOT add/remove any B-MAC to/from the MAC-VRF. 🚫
  • An update of a previously received B-MAC/I-SID route with an increment Sequence Number MUST flush all the C-MACs associated with that I-SID and B-MAC. C-MACs associated with the same I-SID but different B-MAC MUST NOT be flushed. 🧹
  • A received B-MAC/I-SID withdraw (with a non-zero I-SID) MUST flush all the C-MACs associated with that B-MAC and I-SID. 🗑️

Note that the C-MAC flush procedures described in [RFC7623] for B-MAC/0 routes are still valid and a PE receiving [RFC7623] C-MAC flush notification messages MUST observe the behavior specified in [RFC7623]. 💅

5. Conclusions 👑

The I-SID-based C-MAC flush solution described in this document has the following benefits:

a. The solution solves packet-loss scenarios in case of failures on null ES ACs, since the C-MAC flush procedures are independent of the ES definition. 🎉

b. This extension can also be used with Single-Active non-null ESs and virtual ESs, irrespective of the PE B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC). 🌈

c. It provides a C-MAC flush notification at B-MAC and I-SID granularity level, therefore flushing a minimum number of C-MACs and reducing the amount of unknown unicast flooding in the network. ✨

d. It provides a reliable C-MAC flush notification in PBB-EVPN networks that use RRs. RRs will propagate the C-MAC flush notifications for all the affected I-SIDs, irrespective of the order in which the notifications make it to the RR. 🫶

e. The solution can coexist in a network with systems supporting or not supporting this specification. Non-supporting systems ignore the B-MAC/I-SID routes; however, they still follow the C-MAC flush procedures in [RFC7623]. 🦋

6. Security Considerations 💀

Okay this one is serious bestie, so read it properly 🙈

Security considerations described in [RFC7623] apply to this document.

In addition, this document suggests additional procedures that can be activated on a per I-SID basis and generate additional EVPN MAC/IP Advertisement routes in the network. The format of these additional EVPN MAC/IP Advertisement routes is backwards compatible with the procedures in [RFC7623] and should not create any issues for receiving PEs that do not follow this specification. However, the additional routes may consume extra memory and processing resources on the receiving PEs. Because of that, it is RECOMMENDED to activate this feature only when necessary (when multihomed networks or devices are attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN PE. 🔥

7. IANA Considerations 🌸

This document has no IANA actions. 🫧

8. References 📚

8.1. Normative References

okay bestie, these are the must-read docs 📚 the spec leans on them so you can't skip 'em 🫶

8.2. Informative References

these ones are more like bonus reading 🌈 nice to know, not strictly needed to get the core vibe ✨

Acknowledgments 🫶

huge thank-you to Vinod Prabhu, Sriram Venkateswaran, Laxmi Padakanti, and Ranganathan Boovaraghavan 💖 the authors are so grateful for your reviews and contributions, you literally made this spec better ✨

Authors' Addresses 💌

Here's where to find the authors. Jorge Rabadan is the editor 👑

Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Senthil Sathappan
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: senthil.sathappan@nokia.com
Kiran Nagaraj
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: kiran.nagaraj@nokia.com
M. Miyake
Softbank
Email: masahiro.miyake@g.softbank.co.jp
T. Matsuda
Softbank
Email: taku.matsuda@g.softbank.co.jp
📦 where this page comes from