rfc9541.original   rfc9541.txt 
BESS Workgroup J. Rabadan, Ed. Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Internet-Draft S. Sathappan Request for Comments: 9541 S. Sathappan
Intended status: Standards Track K. Nagaraj Category: Standards Track K. Nagaraj
Expires: 25 April 2024 Nokia ISSN: 2070-1721 Nokia
M. Miyake M. Miyake
T. Matsuda T. Matsuda
Softbank Softbank
23 October 2023 February 2024
PBB-EVPN ISID-based C-MAC-Flush Flush Mechanism for Customer MAC Addresses Based on Service Instance
draft-ietf-bess-pbb-evpn-isid-cmacflush-09 Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)
Abstract Abstract
Provider Backbone Bridging (PBB) can be combined with Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet
Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network Virtual Private Networks (EVPNs) to deploy Ethernet Local Area
(ELAN) services in large Multi-Protocol Label Switching (MPLS) Network (E-LAN) services in large Multiprotocol Label Switching
networks. That combination is what we refer to as PBB-EVPN. Single- (MPLS) networks. That combination is what we refer to as "PBB-EVPN."
Active Multi-homing and per-I-SID (per Service Instance Identifier) Single-Active multihoming and per Service Instance Identifier (I-SID)
Load-Balancing can be provided to access devices and aggregation load-balancing can be provided to access devices and aggregation
networks. In order to speed up the network convergence in case of networks. In order to speed up the network convergence in case of
failures on Single-Active Multi-Homed Ethernet Segments (ES), PBB- failures on Single-Active multihomed Ethernet Segments (ESs), PBB-
EVPN defines a flush mechanism for Customer MACs (C-MAC-flush) that EVPN defines a flush mechanism for Customer MACs (C-MACs) called
works for different Ethernet Segment Backbone MAC (B-MAC) address "C-MAC flush" that works for different Ethernet Segment Backbone MAC
allocation models. This document complements those C-MAC-flush (B-MAC) address allocation models. This document complements those
procedures for cases in which no PBB-EVPN Ethernet Segments are C-MAC flush procedures for cases in which no PBB-EVPN ESs are defined
defined (the attachment circuit is associated to a zero Ethernet (i.e., the attachment circuit is associated with a zero Ethernet
Segment Identifier) and a Service Instance Identifier based (I-SID- Segment Identifier (ESI)) and the C-MAC flush requires I-SID-level
based) C-MAC-flush granularity is required. granularity.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 April 2024. 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 Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology and Conventions . . . . . . . . . . . . . . . 5 1.1. Abbreviations
2. Solution requirements . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology and Conventions
3. EVPN BGP Encoding for ISID-based C-MAC-flush . . . . . . . . 7 2. Solution Requirements
4. Solution description . . . . . . . . . . . . . . . . . . . . 8 3. EVPN BGP Encoding for I-SID-Based C-MAC Flush
4.1. ISID-based C-MAC-Flush activation procedures . . . . . . 9 4. Solution Description
4.2. C-MAC-Flush generation . . . . . . . . . . . . . . . . . 9 4.1. I-SID-Based C-MAC Flush Activation Procedures
4.3. C-MAC-flush process upon receiving a CMAC-flush 4.2. C-MAC Flush Generation
notification . . . . . . . . . . . . . . . . . . . . . . 10 4.3. C-MAC Flush Process upon Receiving a C-MAC Flush
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 Notification
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Conclusions
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
[RFC7623] defines how Provider Backbone Bridging (PBB) can be [RFC7623] defines how Provider Backbone Bridging (PBB) can be
combined with Ethernet Virtual Private Networks (EVPN) to deploy ELAN combined with Ethernet Virtual Private Networks (EVPNs) to deploy
services in very large MPLS networks. [RFC7623] also describes how E-LAN services in very large MPLS networks. [RFC7623] also describes
Single-Active Multi-homing and per-I-SID Load-Balancing can be how Single-Active multihoming and per-I-SID load-balancing can be
provided to access devices and aggregation networks. When Access provided to access devices and aggregation networks. When Access
Ethernet/MPLS Networks exists, Ethernet and/or MPLS networks exist, [EVPN-VIRTUAL-ES] describes how
[I-D.ietf-bess-evpn-virtual-eth-segment] describes how virtual virtual Ethernet Segments (ESs) can be associated with a group of
Ethernet Segments (ES) can be associated to a group of Ethernet Ethernet Virtual Circuits (EVCs) or even pseudowires (PWs). In order
Virtual Circuits (EVCs) or even Pseudowires (PWs). In order to speed to speed up the network convergence in case of failures on Single-
up the network convergence in case of failures on Single-Active Active multihomed ESs, [RFC7623] defines a Customer MAC flush
Multi-Homed Ethernet Segments, [RFC7623] defines a Customer MAC flush mechanism that works for different ES B-MAC address allocation
mechanism that works for different Ethernet Segment B-MAC address models.
allocation models.
In some cases, the administrative entities that manage the access In some cases, the administrative entities that manage the access
devices or aggregation networks do not demand Multi-Homing Ethernet devices or aggregation networks do not demand multihomed ESs from the
Segments (ES) from the PBB-EVPN provider, but simply multiple single- PBB-EVPN provider, but simply demand multiple single-homed ESs.
homed ES. Single-homed ES use null ESIs, whereas multi-homed ES use Single-homed ESs use null ESIs, whereas multihomed ESs use non-null
non-null ESIs. If case of using single-homed ES, the PBB-EVPN ESIs. If using single-homed ESs, the PBB-EVPN network is no longer
network is no longer aware of the redundancy offered by the access aware of the redundancy offered by the access administrative entity.
administrative entity. Figure 1 shows an example where the PBB-EVPN Figure 1 shows an example where the PBB-EVPN network provides four
network provides four different Attachment Circuits for I-SID1, with different Attachment Circuits (ACs) for I-SID1, with those ACs not
those Attachment Circuits not being part of any Ethernet Segment or being part of any ES or virtual ES. (Therefore, they are referred to
virtual Ethernet Segment (therefore they are referred to as null as null virtual Ethernet Segments.)
virtual Ethernet Segment).
<----G.8032--><--PBB-EVPN Network---><----MPLS----> <----G.8032----><--PBB-EVPN Network-----><----MPLS---->
Access MPLS Access Access MPLS Access
Ring Network Ring Network
I-SID1 ESI +------+ +------+ I-SID1 ESI +------+ +------+
+----+ null| PE1 |---------| PE3 | +----+ null| PE1 |---------| PE3 |
|CE1 |--------|B-MAC1| |B-MAC3| ESI null |CE1 |----------|B-MAC1| |B-MAC3| ESI null
+----+ active| | | |----+ PW +----+ active| | | |----+ PW
| +------+ +------+ \active | +------+ +------+ \active
| | | \ +----+ | | | \ +----+
| | | ==|CE3 |I-SID1 | | | ==|CE3 |I-SID1
| | | / +----+ | | | / +----+
|stb ESI +------+ +------+ / PW |standby ESI +------+ +------+ / PW
+----+ null| PE2 | | PE4 |----+ standby +----+ null| PE2 | | PE4 |----+ standby
|CE2 |--------|B-MAC2| |B-MAC4| ESI null |CE2 |----------|B-MAC2| |B-MAC4| ESI null
+----+ active| |---------| | +----+ active| |---------| |
I-SID1 +------+ +------+ I-SID1 +------+ +------+
Figure 1: PBB-EVPN and non-ES based redundancy Figure 1: PBB-EVPN and Non-ES-Based Redundancy
In the example in Figure 1, CE1, CE2 and CE3 are attached to the same In the example in Figure 1, CE1, CE2, and CE3 are attached to the
service, identified by I-SID1, in the PBB-EVPN PEs. CE1 and CE2 are same service, identified by I-SID1, in the PBB-EVPN PEs. CE1 and CE2
connected to the PEs via G.8032 Ethernet Ring Protection Switching, are connected to the PEs via "Ethernet ring protection switching" as
and their Attachment Circuits to PE1 and PE2 are represented by a specified in [G.8032], and their ACs to PE1 and PE2 are represented
port and VLAN identifier. CE3 is dual-homed to PE3 and PE4 through by a port and VLAN identifier. CE3 is dual-homed to PE3 and PE4
an active-standby PW, and its Attachment Circuit to the PEs is through an active/standby PW, and its AC to the PEs is represented by
represented by a PW. Each of the four PEs uses a dedicated Backbone a PW. Each of the four PEs uses a dedicated Backbone MAC address as
MAC address as source MAC address (B-MAC1, B-MAC2, B-MAC3 and B-MAC4, a source MAC address (B-MAC1, B-MAC2, B-MAC3, and B-MAC4,
respectively) when encapsulating customer frames in PBB packets and respectively) when encapsulating customer frames in PBB packets and
forwarding those PBB packets to the remote PEs as per [RFC7623]. forwarding those PBB packets to the remote PEs as per [RFC7623].
There are no multi-homed Ethernet Segments defined in the PBB-EVPN There are no multihomed ESs defined in the PBB-EVPN network of the
network of the example, that is why the four Attachment Circuits in example; that is why the four ACs in Figure 1 show the text "ESI
Figure 1 show the text "ESI null", which means the Ethernet Segment null", which means the Ethernet Segment Identifier on those ACs is
Identifier on those Attachment Circuits is zero. Since there are no zero. Since there are no multihomed ESs defined, the PEs keep their
multi-homed ES defined, the PEs keep their Attachment Circuits active ACs active as long as the physical connectivity is established and
as long as the physical connectivity is established and the CEs are the CEs are responsible for managing the redundancy, avoiding loops,
responsible for managing the redundancy, avoiding loops and providing and providing per-I-SID load-balancing to the PBB-EVPN network.
per-I-SID load balancing to the PBB-EVPN network. Examples of CEs Examples of CEs managing their own redundancy are described in
managing their own redundancy are described in [G.8032], or [RFC4762] [G.8032], or [RFC4762] for active/standby PWs.
for active/standby Pseudowires.
For instance, in normal conditions, CE2 will block its link to CE1 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 and CE3 will block its forwarding path to PE4. In this situation, a
failure in one of the redundant Attachment Circuits will trigger the failure in one of the redundant ACs will trigger the CEs to start
CEs to start using their redundant paths, however those failures will using their redundant paths; however, those failures will not trigger
not trigger any Customer MAC flush procedures in the PEs that any C-MAC flush procedures in the PEs that implement [RFC7623], since
implement [RFC7623], since the PEs are not using the PBB-EVPN multi- the PEs are not using the PBB-EVPN multihoming procedures. For
homing procedures. For example: example:
* if the active PW from CE3 (to PE3) fails and the failure is due to * 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] the entire PE3 node failing, then the procedures in [RFC7623]
guarantee that all the remote PEs flush all the Customer MACs guarantee that all the remote PEs flush all the C-MACs associated
associated with B-MAC3 (the B-MAC of PE3). In this case, CE3 with B-MAC3 (the B-MAC of PE3). In this case, CE3 detects the
detects the fault due to the PW going operationally down. fault due to the PW going operationally down.
* however, if the active PW from CE3 (to PE3) fails (but PE3 is * However, if the active PW from CE3 (to PE3) fails (but PE3 is
still operationally up), following the procedures in [RFC7623], still operationally up), following the procedures in [RFC7623],
neither PE3 nor PE4 issue a Customer MAC flush message and neither PE3 nor PE4 issue a C-MAC flush message. Therefore, the
therefore the remote PEs will continue pointing at PE3's Backbone remote PEs will continue pointing at PE3's B-MAC to reach CE3's
MAC to reach CE3's Customer MACs, until the Customer MACs age out C-MACs, until the C-MACs age out in the I-SID1 forwarding tables.
in the I-SID1 forwarding tables. In this case, PE3 may use any of In this case, PE3 may use any of the existing PW notifications so
the existing PW notifications so that CE3 switches the active PW that CE3 switches the active PW to PE4.
to PE4.
* the same issue is exposed when the active PW from CE3 switches * 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, over from PE3 to PE4 due to a manual operation on CE3; that is,
neither PE3 nor PE4 trigger any Customer MAC flush notification neither PE3 nor PE4 trigger any C-MAC flush notification and the
and the remote PEs continue sending the traffic to PE3 until the remote PEs continue sending the traffic to PE3 until the C-MACs
Customer MACs age out. age out.
[RFC7623] provides a Customer MAC flush solution based on a shared [RFC7623] provides a C-MAC flush solution based on a shared B-MAC
Backbone MAC update along with the MAC Mobility extended community update along with the MAC Mobility extended community where the
where the sequence number is incremented. However, the procedure is sequence number is incremented. However, the procedure is only used
only used along with multi-homed Ethernet Segments. Even if that along with multihomed ESs. Even if that procedure could be used for
procedure could be used for null Ethernet Segments, as in the example null ESs, as in the example of Figure 1, the Customer MAC flush
of Figure 1, the [RFC7623] Customer MAC flush procedure would result procedure in [RFC7623] would result in unnecessary flushing of
in unnecessary flushing of unaffected I-SIDs on the remote PEs, and unaffected I-SIDs on the remote PEs, and subsequent flooding of
subsequent flooding of unknown unicast traffic in the network. For unknown unicast traffic in the network. For instance, in the case
instance, in case CE3 switches its active PW over to PE4, a potential that CE3 switches its active PW over to PE4, a potential solution
solution reusing the existing C-MAC Flush notifications in [RFC7623] reusing the existing C-MAC flush notifications in [RFC7623] is for
could be for PE3 to issue an update for the MAC/IP Advertisement PE3 to issue an update for the MAC/IP Advertisement route of B-MAC3
route of B-MAC3 with a higher sequence number. However, this update with a higher sequence number. However, this update would cause
would have caused unnecessary Customer MAC flushing for all the unnecessary Customer MAC flushing for all the I-SIDs attached to PE3
I-SIDs attached to PE3 (supposing multiple I-SIDs in PE3), and not (supposing multiple I-SIDs in PE3) rather than for only I-SID1.
only I-SID1.
This document describes an extension of the [RFC7623] Customer MAC This document describes an extension of the Customer MAC flush
flush procedures, so that in the above failure example, PE3 can procedures in [RFC7623], so that in the failure example above, PE3
trigger a Customer MAC flush notification that makes PE1, PE2 and PE4 can trigger a Customer MAC flush notification that makes PE1, PE2,
flush all the Customer MACs associated to PE3's B-MAC3 and (only) and PE4 flush all the Customer MACs associated with PE3's B-MAC3 and
I-SID1. In order to do so, this specification introduces the (only) I-SID1. In order to do so, this specification introduces the
encoding of the I-SID in the MAC/IP Advertisement routes advertised encoding of the I-SID in the MAC/IP Advertisement routes advertised
for the B-MACs. The Customer MAC flush procedure explained in this for the B-MACs. The C-MAC flush procedure explained in this document
document is referred to as "PBB-EVPN I-SID-based C-MAC-flush" and can is referred to as "PBB-EVPN I-SID-based C-MAC flush" and can be used
be used in PBB-EVPN networks with null or non-null (virtual) Ethernet in PBB-EVPN networks with null or non-null (virtual) ESs.
Segments.
This specification assumes that the reader is familiar with the This specification assumes that the reader is familiar with the
procedures in [RFC7623]. procedures in [RFC7623].
1.1. Terminology and Conventions 1.1. Abbreviations
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.
AC: Attachment Circuit. AC: Attachment Circuit
B-MAC: Backbone MAC address. B-MAC: Backbone MAC
B-MAC/0 route: an EVPN MAC/IP Advertisement route that uses a B-MAC CE: Customer Edge
in the MAC address field and a zero Ethernet Tag ID.
B-MAC/I-SID route: an EVPN MAC/IP Advertisement route that uses a C-MAC: Customer MAC
B-MAC in the MAC address field and an I-SID in the Ethernet Tag
field, and 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.
CE: Customer Edge router. ES: Ethernet Segment
C-MAC: Customer MAC address. ESI: Ethernet Segment Identifier
ES, and ESI: Ethernet Segment and Ethernet Segment Identifier. EVI: EVPN Instance
EVI: EVPN Instance. EVPN: Ethernet Virtual Private Network (as in [RFC7432])
EVPN: Ethernet Virtual Private Networks, as in [RFC7432]. I-SID: Service Instance Identifier
G.8032: Ethernet Ring Protection [G.8032]. MAC: Media Access Control
I-SID: Service Instance Identifier. MAC-VRF: MAC Virtual Routing and Forwarding
MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses. PBB-EVPN: Provider Backbone Bridging and EVPN (as in [RFC7623])
PBB-EVPN: Provider-Backbone-Bridging and EVPN, as in [RFC7623]. PE: Provider Edge
PE: Provider Edge router. 1.2. Terminology and Conventions
Familiarity with the terminology in [RFC7623] is expected. Familiarity with the terminology in [RFC7623] is expected.
2. Solution requirements 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.
The following requirements are followed by the C-MAC-flush solution 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: described in this document:
a. The solution MUST prevent black-hole scenarios in case of a. The solution MUST prevent packet-loss scenarios in case of
failures on null ES ACs (Attachment Circuits not associated to failures on null ES ACs (Attachment Circuits not associated with
ES, that is, their corresponding ESI is zero) when the access an ES; that is, their corresponding ESI is zero) when the access
device/network is responsible for the redundancy. device or access network is responsible for the redundancy.
b. This extension described in this document MUST work with Single- b. This extension described in this document MUST work with Single-
Active non-null ES and virtual ES, irrespective of the PE B-MAC 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 address assignment (dedicated per-ES B-MAC or shared B-MAC, as in
[RFC7623]). [RFC7623]).
c. In case of failure on the egress PE, the solution MUST provide a c. In case of failure on the egress PE, the solution MUST provide a
C-MAC-flush notification at B-MAC and I-SID granularity level. 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 d. The solution MUST provide a reliable C-MAC flush notification in
PBB-EVPN networks that use Route-Reflectors (RRs). MAC flushing PBB-EVPN networks that use Route Reflectors (RRs). MAC flushing
needs to be provided to all affected I-SIDs in spite of the BGP needs to be provided to all affected I-SIDs in spite of the BGP
flush notification messages being aggregated at the RR. flush notification messages being aggregated at the RR.
e. The solution MUST coexist in [RFC7623] networks where there are e. The solution MUST coexist in [RFC7623] networks where there are
PEs that do not support this specification. PEs that do not support this specification.
f. The solution SHOULD be enabled/disabled by an administrative f. The solution SHOULD be enabled or disabled by an administrative
option on a per-PE and per-I-SID basis (as opposed to be always option on a per-PE and per-I-SID basis (as opposed to always
enabled for all the I-SIDs). being enabled for all the I-SIDs).
3. EVPN BGP Encoding for ISID-based C-MAC-flush 3. EVPN BGP Encoding for I-SID-Based C-MAC Flush
The solution does not use any new BGP attributes but reuses the MAC 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 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 [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 EVPN MAC/IP advertisement route. As a reference, Figure 2 shows the
MAC Mobility extended community and the EVPN MAC/IP advertisement MAC Mobility extended community and the EVPN MAC/IP advertisement
route that are used specified in [RFC7432] and used in this document route that are used as specified in [RFC7432] and used in this
as a C-MAC-flush notification message. 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 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 | | Type=0x06 | Sub-Type=0x03 | Flags | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------+ +---------------------------------------+
| Route Distinguisher | | Route Distinguisher |
skipping to change at page 7, line 38 skipping to change at line 317
+---------------------------------------+ +---------------------------------------+
| MAC Address Length = 48 | | MAC Address Length = 48 |
+---------------------------------------+ +---------------------------------------+
| B-MAC Address | | B-MAC Address |
+---------------------------------------+ +---------------------------------------+
| IP Address Length = 0 | | IP Address Length = 0 |
+---------------------------------------+ +---------------------------------------+
| MPLS Label1 | | MPLS Label1 |
+---------------------------------------+ +---------------------------------------+
Figure 2: CMAC-Flush notification encoding: BMAC/ISID route Figure 2: C-MAC Flush Notification Encoding: B-MAC/I-SID Route
Where: Where:
* The route's route distinguisher and route targets are the ones * The route's route distinguisher and route targets are the ones
corresponding to its EVI. Alternatively to the EVI's RT, the corresponding to its EVI. Alternatively to the EVI's Route Target
route MAY be tagged with an RT auto-derived from the Ethernet Tag (RT), the route MAY be tagged with an RT auto-derived from the
(I-SID) instead. [RFC7623] describes how the EVPN MAC/IP Ethernet Tag (I-SID) instead. [RFC7623] describes how the EVPN
Advertisement routes can be advertised along with the EVI RT or an MAC/IP Advertisement routes can be advertised along with the EVI
RT that is derived from the I-SID. RT or an RT that is derived from the I-SID.
* The Ethernet Tag encodes the I-SID for which the PE that receives
the route must flush the C-MACs upon reception of the route.
* The MAC address field encodes the B-MAC Address for which the PE * The Ethernet Tag encodes the I-SID. This indicates to the PE that
that receives the route must flush the C-MACs upon reception of it must flush the C-MACs for that encoded I-SID, upon reception of
the route. 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 * The MAC Mobility extended community is used as in [RFC7623], where
an increment in the sequence number between two updates for the 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 same B-MAC/I-SID will be interpreted as a C-MAC flush notification
for the corresponding B-MAC and I-SID. for the corresponding B-MAC and I-SID.
All the other fields are set and used as defined in [RFC7623]. This 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 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 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 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 document uses the term "B-MAC/0 route" to represent a B-MAC route
advertised with Ethernet Tag ID = 0. advertised with an Ethernet Tag ID = 0.
Note that this B-MAC/I-SID route will be accepted and reflected by Note that this B-MAC/I-SID route will be accepted and reflected by
any [RFC7432] RR, since no new attributes or values are used. A PE any RR as specified in [RFC7432], since no new attributes or values
receiving the route will process the received B-MAC/I-SID update only are used. A PE receiving the route will process the received B-MAC/
in case of supporting the procedures described in this document. I-SID update only in the case of supporting the procedures described
in this document.
4. Solution description 4. Solution Description
Figure 1 will be used in the description of the solution. CE1, CE2 Figure 1 will be used in the description of the solution. CE1, CE2,
and CE3 are connected to ACs associated to I-SID1, where no (Multi- and CE3 are connected to ACs associated with I-SID1, where no
Homed) Ethernet Segments have been enabled, and the ACs and PWs are (multihomed) ESs have been enabled, and the ACs and PWs are in active
in active or standby state as per Figure 1. or standby state as per Figure 1.
Enabling or disabling I-SID-based C-MAC-flush SHOULD be an Enabling or disabling I-SID-based C-MAC flush SHOULD be an
administrative choice on the system that MAY be configured per I-SID administrative choice on the system that MAY be configured per I-SID
(I-Component, Service Instance Component), as opposed to being (I-Component, Service Instance Component), as opposed to being
configured for all I-SIDs. When enabled on a PE: 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 a. The PE will be able to generate B-MAC/I-SID routes as C-MAC Flush
notifications for the remote PEs. notifications for the remote PEs.
b. The PE will be able to process B-MAC/I-SID routes received from b. The PE will be able to process B-MAC/I-SID routes received from
remote PEs. remote PEs.
The PE MUST follow the [RFC7623] procedures for C-MAC-flush. This The PE MUST follow the procedures in [RFC7623] for C-MAC flush. This
specification brings some additional procedures when I-SID-based C- specification provides some additional procedures when I-SID-based
MAC-flush is enabled. C-MAC flush is enabled.
This C-MAC-flush specification is described in three sets of This C-MAC flush specification is described in three sets of
procedures: procedures:
* I-SID-based C-MAC-flush activation * 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 * C-MAC flush notification generation upon AC failures
4.1. ISID-based C-MAC-Flush activation procedures * 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 The following behavior MUST be followed by the PBB-EVPN PEs following
this specification. Figure 1 is used as a reference. this specification. Figure 1 is used as a reference.
* As in [RFC7623], each PE advertises a shared B-MAC in a B-MAC/0 * 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 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 field, respectively). This is the B-MAC that each PE will use as
B-MAC SA (Source Address) when encapsulating the frames received B-MAC SA (Source Address) when encapsulating the frames received
on any local single-homed AC. Each PE will import the 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 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 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 will advertise B-MAC1/0 and will install B-MAC2, B-MAC3, and
in its MAC-VRF. B-MAC4 in its MAC-VRF.
* Assuming I-SID-based C-MAC-flush is activated for I-SID 1, the PEs * Assuming I-SID-based C-MAC flush is activated for I-SID1, the PEs
will advertise the shared B-MAC with I-SID 1 encoded in the will advertise the shared B-MAC with I-SID1 encoded in the
Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will 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 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 use these B-MAC/I-SID routes only for C-MAC flush procedures and
they MUST NOT be used them to add/withdraw any B-MAC entry in the they MUST NOT be used to add/withdraw any B-MAC entry in the MAC-
MAC-VRFs. As per [RFC7623], only B-MAC/0 routes can be used to VRFs. As per [RFC7623], only B-MAC/0 routes can be used to add/
add/withdraw B-MACs in the MAC-VRFs. withdraw B-MACs in the MAC-VRFs.
* The above procedure MAY also be used for dedicated B-MACs (B-MACs * The above procedure MAY also be used for dedicated B-MACs (B-MACs
allocated per Ethernet Segment). allocated per ES).
4.2. C-MAC-Flush generation 4.2. C-MAC Flush Generation
If, for instance, there is a failure on PE1's AC, PE1 will generate 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 an update including B-MAC1/1 along with the MAC Mobility extended
community where the Sequence Number has been incremented. The community where the Sequence Number has been incremented. The
reception of the B-MAC1/1 with an increment in the sequence number reception of the B-MAC1/1 with an increment in the sequence number
will trigger the C-MAC-flush procedures on the receiving PEs. 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 * 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 higher Sequence Number. If the AC going down makes the entire
local I-SID go operationally down, the PE will withdraw the B-MAC/ local I-SID go operationally down, the PE will withdraw the B-MAC/
I-SID route for the I-SID. I-SID route for the I-SID.
* An AC going operationally up SHOULD NOT generate any B-MAC/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 update, unless it activates its corresponding I-SID, in which case
the PE will advertise the B-MAC/I-SID route. the PE will advertise the B-MAC/I-SID route.
* An AC receiving a G.8032 flush notification or a flush message in * 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 any other protocol from the access network MAY propagate it to the
remote PEs by generating a B-MAC/I-SID route update with higher remote PEs by generating a B-MAC/I-SID route update with a higher
Sequence Number. Sequence Number.
4.3. C-MAC-flush process upon receiving a CMAC-flush notification 4.3. C-MAC Flush Process upon Receiving a C-MAC Flush Notification
A PE receiving a C-MAC-flush notification will follow these A PE receiving a C-MAC flush notification will follow these
procedures: procedures:
* A received B-MAC/I-SID route (with non-zero I-SID) MUST NOT add/ * 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. remove any B-MAC to/from the MAC-VRF.
* An update of a previously received B-MAC/I-SID route with an * An update of a previously received B-MAC/I-SID route with an
increment Sequence Number, MUST flush all the C-MACs associated to increment Sequence Number MUST flush all the C-MACs associated
that I-SID and B-MAC. C-MACs associated to the same I-SID but with that I-SID and B-MAC. C-MACs associated with the same I-SID
different B-MAC MUST NOT be flushed. but different B-MAC MUST NOT be flushed.
* A received B-MAC/I-SID withdraw (with non-zero I-SID) MUST flush * A received B-MAC/I-SID withdraw (with a non-zero I-SID) MUST flush
all the C-MACs associated to that B-MAC and I-SID. all the C-MACs associated with that B-MAC and I-SID.
Note that the C-MAC-flush procedures described in [RFC7623] for 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- B-MAC/0 routes are still valid and a PE receiving [RFC7623] C-MAC
flush notification messages MUST observe the behavior specified in flush notification messages MUST observe the behavior specified in
[RFC7623]. [RFC7623].
5. Conclusions 5. Conclusions
The I-SID-based C-MAC-flush solution described in this document has The I-SID-based C-MAC flush solution described in this document has
the following benefits: the following benefits:
a. The solution solves black-hole scenarios in case of failures on a. The solution solves packet-loss scenarios in case of failures on
null ES ACs, since the C-MAC-flush procedures are independent of null ES ACs, since the C-MAC flush procedures are independent of
the Ethernet Segment definition. the ES definition.
b. This extension can also be used with Single-Active non-null ES b. This extension can also be used with Single-Active non-null ESs
and virtual ES, irrespective of the PE B-MAC address assignment and virtual ESs, irrespective of the PE B-MAC address assignment
(dedicated per-ES B-MAC or shared B-MAC). (dedicated per-ES B-MAC or shared B-MAC).
c. It provides a C-MAC-flush notification at B-MAC and I-SID c. It provides a C-MAC flush notification at B-MAC and I-SID
granularity level, therefore flushing a minimum number of C-MACs granularity level, therefore flushing a minimum number of C-MACs
and reducing the amount of unknown unicast flooding in the and reducing the amount of unknown unicast flooding in the
network. network.
d. It provides a reliable C-MAC-flush notification in PBB-EVPN d. It provides a reliable C-MAC flush notification in PBB-EVPN
networks that use RRs. RRs will propagate the C-MAC-flush networks that use RRs. RRs will propagate the C-MAC flush
notifications for all the affected I-SIDs and irrespective of the notifications for all the affected I-SIDs, irrespective of the
order in which the notifications make it to the RR. order in which the notifications make it to the RR.
e. The solution can coexist in a network with systems supporting or e. The solution can coexist in a network with systems supporting or
not supporting this specification. Non-supporting systems ignore not supporting this specification. Non-supporting systems ignore
the B-MAC/I-SID routes, however they still follow the C-MAC-flush the B-MAC/I-SID routes; however, they still follow the C-MAC
procedures in [RFC7623]. flush procedures in [RFC7623].
6. Security Considerations 6. Security Considerations
Security considerations described in [RFC7623] apply to this Security considerations described in [RFC7623] apply to this
document. document.
In addition, this document suggests additional procedures, that can In addition, this document suggests additional procedures that can be
be activated on a per I-SID basis, and generate additional EVPN MAC/ activated on a per I-SID basis and generate additional EVPN MAC/IP
IP Advertisement routes in the network. The format of these Advertisement routes in the network. The format of these additional
additional EVPN MAC/IP Advertisement routes is backwards compatible EVPN MAC/IP Advertisement routes is backwards compatible with the
with [RFC7623] procedures and should not create any issues on procedures in [RFC7623] and should not create any issues for
receiving PEs not following this specification, however, the receiving PEs that do not follow this specification. However, the
additional routes may consume extra memory and processing resources additional routes may consume extra memory and processing resources
on the receiving PEs. Because of that, it is RECOMMENDED to activate on the receiving PEs. Because of that, it is RECOMMENDED to activate
this feature only when necessary (when multi-homed networks or this feature only when necessary (when multihomed networks or devices
devices are attached to the PBB-EVPN PEs), and not by default in any are attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN
PBB-EVPN PE. PE.
7. IANA Considerations 7. IANA Considerations
This document requests no actions from IANA. This document has no IANA actions.
8. Acknowledgments
The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi
Padakanti, Ranganathan Boovaraghavan for their review and
contributions.
9. Contributors
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Henderickx, "Provider Backbone Bridging Combined with Requirement Levels", BCP 14, RFC 2119,
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, DOI 10.17487/RFC2119, March 1997,
September 2015, <https://www.rfc-editor.org/info/rfc7623>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Requirement Levels", BCP 14, RFC 2119, Henderickx, "Provider Backbone Bridging Combined with
DOI 10.17487/RFC2119, March 1997, Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
<https://www.rfc-editor.org/info/rfc2119>. September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 8.2. Informative References
[I-D.ietf-bess-evpn-virtual-eth-segment] [EVPN-VIRTUAL-ES]
Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. Sajassi, A., Brissette, P., Schell, R., Drake, J., and J.
Rabadan, "EVPN Virtual Ethernet Segment", Work in Rabadan, "EVPN Virtual Ethernet Segment", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-virtual- Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
eth-segment-14, 23 September 2023, eth-segment-14, 23 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess- <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-virtual-eth-segment-14>. evpn-virtual-eth-segment-14>.
[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 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
[G.8032] "Recommendation ITU-T G.8032/Y.1344, Ethernet ring Acknowledgments
protection switching", March 2020.
The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi
Padakanti, and Ranganathan Boovaraghavan for their review and
contributions.
Authors' Addresses Authors' Addresses
Jorge Rabadan (editor) Jorge Rabadan (editor)
Nokia Nokia
520 Almanor Avenue 520 Almanor Avenue
Sunnyvale, CA 94085 Sunnyvale, CA 94085
United States of America United States of America
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 101 change blocks. 
303 lines changed or deleted 305 lines changed or added

This html diff was produced by rfcdiff 1.48.