RTGWG J. Yang Internet-Draft T. Han Intended status: Standards Track W. Cheng Expires: 3 May 2027 Y. Tian China Mobile J. Wang G. Zhang Centec 30 October 2026 Forwarding-Plane Failure Recovery Procedures for Multi-Chassis Link Aggregation Groups draft-yang-rtgwg-mclag-failure-recovery-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Yang, et al. Expires 3 May 2027 [Page 1] Internet-Draft MC-LAG Failure Recovery October 2026 This Internet-Draft will expire on 3 May 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Reference Topology . . . . . . . . . . . . . . . . . . . . . 5 4. Forwarding State Preservation . . . . . . . . . . . . . . . . 5 4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Failover . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Reversion . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Traffic Handling . . . . . . . . . . . . . . . . . . . . 6 4.5. ICL Membership State . . . . . . . . . . . . . . . . . . 7 5. ICL Relay for Multi-PE Recovery . . . . . . . . . . . . . . . 7 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Failover Request Origination . . . . . . . . . . . . . . 8 5.3. Failover Request Processing . . . . . . . . . . . . . . . 8 5.4. Relay Path Liveness . . . . . . . . . . . . . . . . . . . 8 5.5. Reversion . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Message Types and Fields . . . . . . . . . . . . . . . . 10 7. Loop Prevention . . . . . . . . . . . . . . . . . . . . . . . 11 8. Combined Operation . . . . . . . . . . . . . . . . . . . . . 11 9. Per-Group PE States for ICL Relay . . . . . . . . . . . . . . 12 10. Relationship to Other Protocols . . . . . . . . . . . . . . . 13 10.1. ICCP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. EVPN Multi-Homing . . . . . . . . . . . . . . . . . . . 13 11. Operational Considerations . . . . . . . . . . . . . . . . . 13 11.1. ICL Capacity Planning . . . . . . . . . . . . . . . . . 14 11.2. Hash Redistribution . . . . . . . . . . . . . . . . . . 14 11.3. Flap Dampening . . . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 Yang, et al. Expires 3 May 2027 [Page 2] Internet-Draft MC-LAG Failure Recovery October 2026 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13.1. ICCP Application Type . . . . . . . . . . . . . . . . . 15 13.2. MC-LAG ICL Relay Message Types Registry . . . . . . . . 15 13.3. MC-LAG ICL Relay Status Codes Registry . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Comparison with Existing Approaches . . . . . . . . 16 Appendix B. Detailed Failover Timeline . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction 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. Yang, et al. Expires 3 May 2027 [Page 3] Internet-Draft MC-LAG Failure Recovery October 2026 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. 1.1. Requirements Language 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. Terminology This document uses the terminology of [RFC7275] and [IEEE802.1AX]. The following terms are defined. Downlink Member: A port that belongs to an MC-LAG group and connects to a downstream CE device. ICL: Inter-Chassis Link (peer link). A link or LAG that connects two PEs in an MC-LAG redundancy group (RG). Primary ICL: The ICL between the two PEs that form the normal MC-LAG peer pair for a given RG. Secondary ICL: An ICL between two PEs that are not direct MC-LAG peers for a given RG. A secondary ICL provides a relay path toward additional PEs. LAG Group ID: The forwarding-plane identifier of a LAG group. MAC table entries reference this identifier, and the forwarding engine selects an egress member by a hash function. Member Set: The current set of physical ports that belong to a given LAG group. Relay Path: An ordered set of PEs and ICLs along which a failover request may be forwarded, configured administratively on each participating PE. Downstream Isolation: A condition in which a PE has lost all operational downlink members for a given MC-LAG group. Yang, et al. Expires 3 May 2027 [Page 4] Internet-Draft MC-LAG Failure Recovery October 2026 3. Reference Topology 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: -> G1 Figure 1: Reference Topology 4. Forwarding State Preservation This procedure preserves the forwarding state during a downlink member failure by adjusting the LAG group's member set. 4.1. Preconditions 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. 4.2. Failover 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. Yang, et al. Expires 3 May 2027 [Page 5] Internet-Draft MC-LAG Failure Recovery October 2026 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: -> G1 (UNCHANGED) Hash over {m2, ICL}: some flows via m2, some via ICL Flows via ICL -> PE2 -> forwarded via m3/m4 Figure 2: Forwarding State Preservation 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. 4.3. Reversion 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. 4.4. Traffic Handling 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. Yang, et al. Expires 3 May 2027 [Page 6] Internet-Draft MC-LAG Failure Recovery October 2026 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. 4.5. ICL Membership State The ICL port maintains a per-MC-LAG-group state. Standby: Default. The ICL is not part of the group's member set. Joining: Transient. The ICL is being added to the member set. Active-Member: The ICL is part of the member set and carries redirected traffic. Leaving: Transient. A downlink has recovered and the ICL is being removed from the member set. +---------+ | Standby |<---------------------+ +---------+ | | | threshold crossed table update done | | v +----------+ +---------+ | Leaving | | Joining | +----------+ +---------+ ^ | | table update done downlink recovered | | v | +---------------+----------------+ | Active-Member | +---------------+ Figure 3: ICL Membership State Machine 5. ICL Relay for Multi-PE Recovery This section specifies procedures for relaying failover requests across multiple PEs when the immediate peer cannot satisfy the request. Yang, et al. Expires 3 May 2027 [Page 7] Internet-Draft MC-LAG Failure Recovery October 2026 5.1. Applicability 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. 5.2. Failover Request Origination 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. 5.3. Failover Request Processing 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. 5.4. Relay Path Liveness 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. Yang, et al. Expires 3 May 2027 [Page 8] Internet-Draft MC-LAG Failure Recovery October 2026 5.5. Reversion When the originating PE's downlinks recover, it sends a Revert- Request along the relay path. Each PE restores its ICL segment to standby forwarding state and confirms with a Revert-Response. Reversion SHOULD be delayed by a configurable hold timer (default: 3 seconds). 6. Message Formats 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. 6.1. Common Header 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Common Message Header Version (8 bits): Protocol version. This document defines version 1. Msg Type (8 bits): Failover-Request (1), Failover-Response (2), Liveness (3), Revert-Request (4), Revert-Response (5). Total Length (16 bits): Length of the entire message in octets. Originator-PE-ID (32 bits): Domain-unique identifier of the PE that originated the failover sequence. Used for loop detection. Sequence Number (16 bits): Monotonically increasing per originator, for ordering and duplicate suppression. Yang, et al. Expires 3 May 2027 [Page 9] Internet-Draft MC-LAG Failure Recovery October 2026 Hop Count (8 bits): Incremented at each relay hop. Messages exceeding the configured maximum are discarded. Reserved (8 bits): MUST be zero on transmission; ignored on receipt. Authentication Data (variable): Optional keyed digest for message integrity, aligned with [RFC7275] Section 10. 6.2. Message Types and Fields 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: MC-LAG Group ID TLV 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. Yang, et al. Expires 3 May 2027 [Page 10] Internet-Draft MC-LAG Failure Recovery October 2026 +=======+====================+===============================+ | 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. | +-------+--------------------+-------------------------------+ Table 1: Failover-Response Status Values 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. 7. Loop Prevention 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. 8. Combined Operation When both procedures are deployed together, the following sequence occurs upon a downlink failure on PE1: Yang, et al. Expires 3 May 2027 [Page 11] Internet-Draft MC-LAG Failure Recovery October 2026 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. Figure 6: Combined Operation Sequence 9. Per-Group PE States for ICL Relay Each PE maintains the following per-MC-LAG-group state for the relay function: Operational: The PE has at least one working downlink member and forwards traffic locally. Requesting: The PE has lost all downlink members and has originated a Failover-Request. Relaying: The PE has received a Failover-Request that it cannot satisfy locally and has forwarded it along the relay path. Serving: The PE has satisfied a relayed request by providing one of its downlink members. Reverting: The original failure has been resolved and the relay path Yang, et al. Expires 3 May 2027 [Page 12] Internet-Draft MC-LAG Failure Recovery October 2026 is being torn down. +--------------+ | Operational |<--------------------------+ +--------------+ | | | all downlinks lost reversion complete | | v | +--------------+ +--------------+ | Requesting | | Reverting | +--------------+ +--------------+ | ^ response received | (success) downlink recovered | | +---------+---------+ +------------+ | (local) |(relayed)| | v v v | [done] +----------+ +---------+ | | Relaying |-| Serving |----+ +----------+ +---------+ Figure 7: Per-Group PE State Machine 10. Relationship to Other Protocols 10.1. ICCP 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. 10.2. EVPN Multi-Homing 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. 11. Operational Considerations Yang, et al. Expires 3 May 2027 [Page 13] Internet-Draft MC-LAG Failure Recovery October 2026 11.1. ICL Capacity Planning 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. 11.2. Hash Redistribution 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. 11.3. Flap Dampening Implementations MUST support configurable dampening of member-set changes and relay state transitions to prevent rapid oscillation caused by link flapping. 12. Security Considerations 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. 13. IANA Considerations Yang, et al. Expires 3 May 2027 [Page 14] Internet-Draft MC-LAG Failure Recovery October 2026 13.1. ICCP Application Type 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. 13.2. MC-LAG ICL Relay Message Types Registry 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 | | +-------+-------------------+---------------+ Table 2: Initial MC-LAG ICL Relay Message Types 13.3. MC-LAG ICL Relay Status Codes Registry 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. 14. References 14.1. Normative References Yang, et al. Expires 3 May 2027 [Page 15] Internet-Draft MC-LAG Failure Recovery October 2026 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, DOI 10.17487/RFC7275, June 2014, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [IEEE802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", IEEE 802.1AX-2020, 2020, . [RFC7432] Sajassi, A., 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, . [RFC9786] Brissette, P., Thoria, S., and A. Sajassi, "EVPN Port- Active Redundancy Mode", RFC 9786, DOI 10.17487/RFC9786, 2025, . Appendix A. Comparison with Existing Approaches Yang, et al. Expires 3 May 2027 [Page 16] Internet-Draft MC-LAG Failure Recovery October 2026 +---------------------+----------+----------+-----------+ | | 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 | +---------------------+----------+----------+-----------+ Figure 8: Failover Approach Comparison Appendix B. Detailed Failover Timeline 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) Figure 9: Failover and Reversion Timeline Authors' Addresses Jin Yang China Mobile Beijing 100053 China Email: yangjinwl@chinamobile.com Yang, et al. Expires 3 May 2027 [Page 17] Internet-Draft MC-LAG Failure Recovery October 2026 Tingting Han China Mobile Beijing 100053 China Email: hantingting@chinamobile.com Weiqiang Cheng China Mobile Beijing 100053 China Email: chengweiqiang@chinamobile.com Yuchi Tian China Mobile Beijing 100053 China Email: tianyuchi@chinamobile.com Junjie Wang Centec Suzhou 215000 China Email: wangjj@centec.com Guoying Zhang Centec Suzhou 215000 China Email: zhanggy@centec.com Yang, et al. Expires 3 May 2027 [Page 18]