diff options
Diffstat (limited to 'doc/rfc/rfc9541.txt')
| -rw-r--r-- | doc/rfc/rfc9541.txt | 589 |
1 files changed, 589 insertions, 0 deletions
diff --git a/doc/rfc/rfc9541.txt b/doc/rfc/rfc9541.txt new file mode 100644 index 0000000..13bc25c --- /dev/null +++ b/doc/rfc/rfc9541.txt @@ -0,0 +1,589 @@ + + + + +Internet Engineering Task Force (IETF) J. Rabadan, Ed. +Request for Comments: 9541 S. Sathappan +Category: Standards Track K. Nagaraj +ISSN: 2070-1721 Nokia + M. Miyake + T. Matsuda + Softbank + March 2024 + + + Flush Mechanism for Customer MAC Addresses Based on Service Instance + Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN) + +Abstract + + Provider Backbone Bridging (PBB) can be combined with Ethernet + Virtual Private Networks (EVPNs) to deploy Ethernet Local Area + Network (E-LAN) services in large Multiprotocol Label Switching + (MPLS) networks. That combination is what we refer to as "PBB-EVPN." + Single-Active multihoming and per Service Instance Identifier (I-SID) + load-balancing can be provided to access devices and aggregation + networks. In order to speed up the network convergence in case of + failures on Single-Active multihomed Ethernet Segments (ESs), PBB- + EVPN defines a flush mechanism for Customer MACs (C-MACs) called + "C-MAC flush" that works for different Ethernet Segment Backbone MAC + (B-MAC) address allocation models. This document complements those + C-MAC flush procedures for cases in which no PBB-EVPN ESs are defined + (i.e., the attachment circuit is associated with a zero Ethernet + Segment Identifier (ESI)) and the C-MAC flush requires 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). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9541. + +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. + +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 + + [RFC7623] defines how Provider Backbone Bridging (PBB) can be + combined with Ethernet Virtual Private Networks (EVPNs) to deploy + E-LAN services in very large MPLS networks. [RFC7623] 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). In order + to speed up the network convergence in case of failures on Single- + Active multihomed ESs, [RFC7623] defines a Customer MAC flush + mechanism that works for different ES B-MAC address allocation + models. + + In some cases, the administrative entities that manage the access + devices or aggregation networks do not demand multihomed ESs from the + PBB-EVPN provider, but simply demand multiple single-homed ESs. + Single-homed ESs use null ESIs, whereas multihomed ESs use non-null + ESIs. If using single-homed ESs, the PBB-EVPN network is no longer + aware of the redundancy offered by the access administrative entity. + Figure 1 shows an example where the PBB-EVPN network provides four + different Attachment Circuits (ACs) for I-SID1, with those ACs not + being part of any ES or virtual ES. (Therefore, they are referred to + as 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 example in Figure 1, CE1, CE2, and CE3 are attached to the + same service, identified by I-SID1, in the PBB-EVPN PEs. CE1 and CE2 + are connected to the PEs via "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 a dedicated Backbone MAC address as + a source MAC address (B-MAC1, B-MAC2, B-MAC3, and B-MAC4, + respectively) when encapsulating customer frames in PBB packets and + forwarding those PBB packets to the remote PEs as per [RFC7623]. + There are no multihomed ESs defined in the PBB-EVPN network of the + example; that is why the four ACs in Figure 1 show the text "ESI + null", which means the Ethernet Segment Identifier on those ACs is + zero. Since there are no multihomed ESs defined, the PEs keep their + ACs active as long as the physical connectivity is established and + the CEs are responsible for managing the redundancy, avoiding loops, + and providing per-I-SID load-balancing to the PBB-EVPN network. + Examples of CEs managing their own redundancy are described in + [G.8032], or [RFC4762] for active/standby PWs. + + For instance, in normal conditions, CE2 will block its link to CE1 + and CE3 will block its forwarding path to PE4. In this situation, a + failure in one of the redundant ACs will trigger 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], since + the PEs are not 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 due to the PW going operationally down. + + * However, if the active PW from CE3 (to PE3) fails (but PE3 is + still operationally up), following the procedures in [RFC7623], + neither PE3 nor PE4 issue a C-MAC flush message. Therefore, the + remote PEs will continue pointing at PE3's B-MAC to reach CE3's + C-MACs, until the 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 is exposed when the active PW from CE3 switches + over from PE3 to PE4 due to a manual operation on CE3; that is, + neither PE3 nor PE4 trigger any C-MAC flush notification and the + remote PEs continue sending the 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. However, the procedure is only used + along with multihomed ESs. Even if that procedure could be used for + null ESs, as in the example of Figure 1, the Customer MAC flush + procedure in [RFC7623] would result in unnecessary flushing of + unaffected I-SIDs on the remote PEs, and subsequent flooding of + unknown unicast traffic in the network. For instance, in the case + that CE3 switches its active PW over to PE4, a potential solution + reusing 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. However, this update would cause + unnecessary Customer MAC flushing for all the I-SIDs attached to PE3 + (supposing multiple I-SIDs in PE3) rather than for only I-SID1. + + This document describes an extension of 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. In order to do so, 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 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 + + The following requirements are followed by the C-MAC flush solution + described in this document: + + 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 + + The solution does not use any new BGP attributes but 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. As a 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 will be 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 + + 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 + + [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>. + + [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>. + + [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. + Henderickx, "Provider Backbone Bridging Combined with + Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, + September 2015, <https://www.rfc-editor.org/info/rfc7623>. + + [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>. + +8.2. Informative References + + [EVPN-VIRTUAL-ES] + Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. + Rabadan, "EVPN Virtual Ethernet Segment", Work in + Progress, Internet-Draft, draft-ietf-bess-evpn-virtual- + eth-segment-15, 28 February 2024, + <https://datatracker.ietf.org/doc/html/draft-ietf-bess- + evpn-virtual-eth-segment-15>. + + [G.8032] ITU-T, "Ethernet ring protection switching", ITU-T + Recommendation G.8032/Y.1344, March 2020, + <https://www.itu.int/rec/T-REC-G.8032-202003-I/en>. + + [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, + <https://www.rfc-editor.org/info/rfc4762>. + +Acknowledgments + + The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi + Padakanti, and Ranganathan Boovaraghavan for their review and + contributions. + +Authors' Addresses + + 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 |