| Internet-Draft | MC-LAG Failure Recovery | October 2026 |
| Yang, et al. | Expires 3 May 2027 | [Page] |
When a downlink member of a Multi-Chassis Link Aggregation Group (MC-LAG) fails, a common recovery method flushes the MAC forwarding table and relies on flooding to re-establish the forwarding paths, which can cause a period of congestion and disruption. This document specifies two complementary forwarding-plane failure recovery procedures for MC-LAG. The first procedure preserves the forwarding state by adjusting the LAG group's member set, adding an inter-chassis link (ICL) port in place of the failed downlink, so that MAC table entries remain valid and traffic is redistributed without a table flush and without flooding. The second procedure extends recovery beyond a single Provider Edge (PE) pair: when the immediate peer cannot satisfy a failover request, the request is relayed over a secondary ICL to the next PE along a configured relay path, which allows recovery across three or more PEs in the redundancy domain. The procedures operate primarily in the forwarding plane and do not require Ethernet VPN (EVPN) infrastructure.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 May 2027.¶
Copyright (c) 2026 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.¶
Multi-Chassis Link Aggregation Group (MC-LAG) technology allows two or more Provider Edge (PE) devices to present a single Link Aggregation Group (LAG) interface toward a Customer Edge (CE) device [RFC7275] [IEEE802.1AX]. An inter-chassis link (ICL, also called a peer link) connects the PE devices and carries both Inter-Chassis Communication Protocol (ICCP) signaling [RFC7275] and redirected data traffic.¶
When a downlink member fails, a common recovery method flushes the MAC address table entries associated with the affected LAG group and relies on flooding of unknown unicast to relearn the forwarding paths. In a large deployment the flooding phase can last for hundreds of milliseconds and cause congestion and application-level disruption. EVPN-based solutions [RFC7432] reduce this through control-plane mass-withdraw signaling, but require EVPN infrastructure.¶
This document specifies two procedures that operate primarily in the forwarding plane and do not require EVPN infrastructure.¶
The first procedure, forwarding state preservation (Section 4), responds to the removal of a downlink member from a LAG group by adding an ICL port to the same group. Because MAC table entries reference the LAG group identifier rather than an individual port, the entries remain valid and traffic is redistributed by the LAG hash function without a table flush and without flooding.¶
The second procedure, ICL relay (Section 5), applies in topologies with three or more PEs. A PE that receives a failover request but cannot satisfy it locally relays the request over a secondary ICL to the next PE. The relay continues hop by hop until a PE with an operational downlink is reached.¶
The two procedures are independent and can be deployed separately or together. When combined, forwarding state preservation handles local failover within a PE pair and ICL relay extends recovery to additional PEs in the redundancy domain.¶
The procedures carry MUST-level requirements on PE forwarding and signaling behavior and request an IANA code point for the relay messages, and so this document is on the Standards Track.¶
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.¶
This document uses the terminology of [RFC7275] and [IEEE802.1AX]. The following terms are defined.¶
The topology in Figure 1 is the reference for both procedures. PE1 and PE2 are connected by a primary ICL, and PE2 and PE3 by a secondary ICL. Each PE has downlink members toward the CE.¶
+------+ primary +------+ secondary +------+
| PE1 |---ICL---| PE2 |----ICL----| PE3 |
+------+ +------+ +------+
| | | | |
m1 m2 m3 m4 m5
| | | | |
+-+--+--------------+--+---------------+-+
| CE Device |
+----------------------------------------+
PE1: LAG group G1, member set = {m1, m2}
PE2: LAG group G2, member set = {m3, m4}
PE3: LAG group G3, member set = {m5}
MAC table on PE1: <dst-MAC> -> G1
This procedure preserves the forwarding state during a downlink member failure by adjusting the LAG group's member set.¶
The ICL port MUST be pre-provisioned with the VLAN membership, quality-of-service (QoS) policies, and access control lists (ACLs) of every MC-LAG group for which it may serve as a member. This ensures that adding the ICL to a member set requires only a forwarding-plane table update.¶
A configurable threshold determines when the ICL is added to the member set. The default threshold is the loss of all local downlink members. An implementation MAY allow the operator to specify a minimum local member count below which the ICL is added.¶
When a PE detects a link-down event on a downlink member, it removes the failed port from the affected LAG group's member set. If the remaining local member count falls below the configured threshold, the PE MUST add one or more ICL ports to the member set.¶
The LAG Group ID does not change. MAC table entries continue to resolve to the same group, and the hash function redistributes traffic across the updated member set. A flow hashed to the ICL reaches the peer PE, which performs its own lookup and forwards the flow over its operational downlinks.¶
+--------+ +--------+
| PE1 |----ICL----| PE2 |
+--------+ +--------+
| | | |
m1 m2 m3 m4
(down)X | | |
G1 member set: {m1} removed, ICL added -> {m2, ICL}
MAC table: <dst-MAC> -> G1 (UNCHANGED)
Hash over {m2, ICL}: some flows via m2, some via ICL
Flows via ICL -> PE2 -> forwarded via m3/m4
After modifying the member set, the PE SHOULD notify its MC-LAG peer over ICCP that the ICL now carries redirected traffic for the affected group. The peer uses this notification to adjust split-horizon behavior: traffic that arrives from the ICL for this group MUST be eligible for forwarding out local downlinks and MUST NOT be sent back to the ICL.¶
When a failed downlink recovers, the PE adds the recovered port back to the member set and removes the ICL. The LAG Group ID does not change and no MAC table flush occurs. The PE SHOULD notify its peer that the ICL is no longer carrying redirected traffic.¶
A configurable hold timer, with a default of 1 second, SHOULD delay reversion to prevent repeated membership changes when the downlink flaps.¶
For known unicast, the MAC table entry resolves to the LAG Group ID and the hash function distributes frames across the current member set. No relearning is needed.¶
For broadcast, unknown unicast, and multicast (BUM) traffic, the ICL is typically already part of the flooding domain in an MC-LAG deployment. Adding the ICL to the member set does not change BUM behavior, but an implementation MUST enforce split-horizon rules to prevent duplicate frames.¶
The ICL port maintains a per-MC-LAG-group state.¶
+---------+
| Standby |<---------------------+
+---------+ |
| |
threshold crossed table update done
| |
v +----------+
+---------+ | Leaving |
| Joining | +----------+
+---------+ ^
| |
table update done downlink recovered
| |
v |
+---------------+----------------+
| Active-Member |
+---------------+
This section specifies procedures for relaying failover requests across multiple PEs when the immediate peer cannot satisfy the request.¶
The ICL relay procedures apply to MC-LAG domains comprising three or more PEs where correlated downlink failures can exhaust the failover capacity of the immediate peer pair. Each participating PE MUST have a pre-configured relay path that identifies its secondary ICL and the next-hop PE in the relay sequence.¶
A PE that detects downstream isolation for a given MC-LAG group MUST first attempt local recovery (including the forwarding state preservation procedure of Section 4.2 if configured). If the PE remains unable to reach the CE, it originates a Failover-Request message and sends it to its primary MC-LAG peer over the primary ICL.¶
The message carries the originating PE's identifier (Originator-PE-ID), a sequence number, the affected MC-LAG Group ID, and a hop count initialized to one.¶
A PE receiving a Failover-Request evaluates whether it can satisfy the request:¶
If the PE has an available downlink member, it brings the member into service (or confirms it is already operational) and replies with a Failover-Response indicating success. Redirected traffic then flows along the chain of ICLs from the originating PE to this PE.¶
If the PE cannot satisfy the request and a secondary ICL toward a next-hop PE exists, the PE increments the hop count and forwards the Failover-Request over the secondary ICL.¶
If no further relay path exists, or if the hop count has reached the configured maximum (see Section 7), the PE replies with a Failover-Response indicating No-Resource, or the more specific Hop-Limit-Exceeded status when the hop count is the cause.¶
After a successful relay, each PE along the path MUST exchange periodic Liveness messages with its neighbors on the path. The default interval is 1 second; the default failure threshold is 3 missed messages. If liveness is lost, the PE MUST attempt an alternate path or notify the originator of path failure.¶
The messages defined in this section support the ICL relay procedures of Section 5. They MUST be carried as a new ICCP Application TLV type (Section 10.1) over the ICCP connection between adjacent PEs on the relay path, using the registry allocation requested in Section 13. Defining the messages over a transport other than ICCP is outside the scope of this document; a future specification that does so MUST preserve the field semantics, the loop prevention rules of Section 7, and the security requirements of Section 12.¶
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Msg Type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator-PE-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Hop Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All messages begin with the common header of Section 6.1. The message-specific content is as follows.¶
Failover-Request (Type 1) carries one MC-LAG Group ID TLV (Figure 5) identifying the group that requires recovery.¶
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type (1) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MC-LAG Group ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV Type is 1 (MC-LAG Group ID). The Length is the length in octets of the TLV value (4). The MC-LAG Group ID is a 16-bit identifier of the affected group, unique within the redundancy domain. The Reserved field MUST be set to zero on transmission and ignored on receipt.¶
Failover-Response (Type 2) carries an 8-bit Status field followed by the MC-LAG Group ID TLV copied from the corresponding request. The Status values are defined in Table 1.¶
| Value | Name | Meaning |
|---|---|---|
| 0 | Success | A downlink member was brought into service for the group. |
| 1 | No-Resource | No PE on the relay path could satisfy the request. |
| 2 | Loop-Detected | The request was discarded for loop prevention (Section 7). |
| 3 | Hop-Limit-Exceeded | The request reached the configured maximum hop count. |
Liveness (Type 3) contains only the common header. Revert-Request (Type 4) and Revert-Response (Type 5) each carry the MC-LAG Group ID TLV and manage relay path teardown and restoration.¶
A PE MUST suppress duplicate requests: it maintains, per relay path, the highest Sequence Number seen for each Originator-PE-ID, and MUST silently discard a Failover-Request or Revert-Request whose (Originator-PE-ID, Sequence Number) pair has already been processed. Sequence Number comparison MUST use the serial number arithmetic of [RFC1982] to handle wrap-around.¶
Two mechanisms bound message propagation in topologies that contain cycles:¶
The Originator-PE-ID field uniquely identifies the PE that began the failover sequence. A PE receiving a Failover-Request carrying its own identifier MUST discard the message and return a Failover-Response with status Loop-Detected.¶
The Hop Count field is incremented at each hop. A PE MUST discard any message whose Hop Count exceeds a locally configured maximum (default: 8) and return a Failover-Response with status Hop-Limit-Exceeded.¶
When both procedures are deployed together, the following sequence occurs upon a downlink failure on PE1:¶
Event PE1 Action
----- ----------
m1 link-down detected Remove m1 from G1.
Threshold crossed: add ICL
to G1 (Section 4.2).
G1 = {m2, ICL}; MAC table
unchanged.
m2 also fails Remove m2 from G1.
(correlated failure) G1 = {ICL}; traffic flows
entirely via ICL to PE2.
PE2 also lost m3, m4 PE1's traffic arrives at PE2
(multi-PE failure) via ICL, but PE2 cannot
deliver it.
PE1 originates Failover-
Request (Section 5.2).
PE2 relays to PE3 via
secondary ICL (Section 5.3).
PE3 has m5; returns success.
Data path: PE1 -> ICL ->
PE2 -> secondary ICL ->
PE3 -> m5 -> CE.
Recovery: m1 link-up PE1 adds m1 to G1, removes
ICL. Sends Revert-Request
to tear down relay path.
Each PE maintains the following per-MC-LAG-group state for the relay function:¶
+--------------+
| Operational |<--------------------------+
+--------------+ |
| |
all downlinks lost reversion complete
| |
v |
+--------------+ +--------------+
| Requesting | | Reverting |
+--------------+ +--------------+
| ^
response received |
(success) downlink recovered
| |
+---------+---------+ +------------+
| (local) |(relayed)| |
v v v |
[done] +----------+ +---------+ |
| Relaying |-| Serving |----+
+----------+ +---------+
The procedures in this document do not modify the ICCP state machine defined in [RFC7275]. ICCP continues to manage the primary peer relationship. The relay messages are carried in the new ICCP Application TLV type allocated in Section 13.1; the version negotiation procedures of [RFC7275] Section 4.4.1 apply.¶
In deployments using EVPN multi-homing [RFC7432] [RFC9786] rather than ICCP, the procedures in this document can serve as a forwarding-plane complement. EVPN mass-withdraw provides control-plane convergence; the procedures here provide pre-provisioned data-plane recovery that does not depend on control-plane reconvergence timing.¶
During failure conditions the ICL carries redirected traffic in addition to its normal load. Operators MUST provision ICL capacity for the worst-case scenario. The recommended capacity is at least equal to the aggregate downlink capacity of the largest MC-LAG group.¶
Modifying the LAG member set causes the hash function to remap some flows. This may produce transient packet reordering bounded by the depth of in-flight packets. Applications requiring strict ordering should employ higher-layer reordering tolerance.¶
Implementations MUST support configurable dampening of member-set changes and relay state transitions to prevent rapid oscillation caused by link flapping.¶
The forwarding state preservation procedure (Section 4) is a local forwarding-plane operation with no signaling-based attack surface. The peer notification via ICCP MUST be protected using the authentication mechanisms of [RFC7275].¶
The ICL relay procedure (Section 5) introduces relay messages that alter the forwarding topology. All relay messages MUST be authenticated. Implementations SHOULD support HMAC-SHA-256 keyed digests with pre-shared keys, consistent with [RFC7275]. All secondary ICLs MUST traverse network segments under common administrative control.¶
Implementations MUST support rate limiting of relay messages. The hop count ceiling provides an additional bound on message amplification.¶
During failure conditions the ICL carries increased traffic. Operators SHOULD apply monitoring to detect unusual patterns that may indicate an attack.¶
IANA is requested to allocate one Application Type value for "MC-LAG ICL Relay" from the "ICC RG Parameter Type" registry established by [RFC7275]. The reference is this document.¶
IANA is requested to create a new registry, "MC-LAG ICL Relay Message Types", with an 8-bit value range (0-255). The assignment policy is "IETF Review" [RFC8126]. The initial contents are below. Value 0 is Reserved.¶
| Value | Name | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 1 | Failover-Request | This document |
| 2 | Failover-Response | This document |
| 3 | Liveness | This document |
| 4 | Revert-Request | This document |
| 5 | Revert-Response | This document |
| 6-255 | Unassigned |
IANA is requested to create a new registry, "MC-LAG ICL Relay Failover-Response Status Codes", with an 8-bit value range (0-255). The assignment policy is "IETF Review" [RFC8126]. The initial contents are the values defined in Table 1 (0 = Success, 1 = No-Resource, 2 = Loop-Detected, 3 = Hop-Limit-Exceeded); values 4-255 are Unassigned.¶
+---------------------+----------+----------+-----------+ | | MAC | EVPN | Fwd-Plane | | Property | Table | Mass- | Recovery | | | Flush | Withdraw | (Herein) | +---------------------+----------+----------+-----------+ | MAC Table Impact | Full | Partial | None | | | flush | update | | +---------------------+----------+----------+-----------+ | Flooding During | Yes | Brief | No | | Failover | | | | +---------------------+----------+----------+-----------+ | Convergence | Seconds | Sub- | Forwarding| | Timescale | | second | plane | +---------------------+----------+----------+-----------+ | Multi-PE Recovery | No | Yes | Yes | | | | (BGP) | (ICL) | +---------------------+----------+----------+-----------+ | Infrastructure | None | EVPN | MC-LAG | | Dependency | | | ICL | +---------------------+----------+----------+-----------+
Time Event G1 Member Set MAC Table
---- ----- ------------- ---------
T0 Normal operation {m1, m2} X -> G1
T1 m1 link-down {m2} X -> G1
T2 ICL added to G1 {m2, ICL} X -> G1
(unchanged)
T3 Traffic via ICL to PE2 PE2 forwards No flooding
via m3/m4
...
T10 m1 link-up {m1, m2, ICL} X -> G1
T11 ICL removed (hold timer) {m1, m2} X -> G1
(unchanged)