OPSAWG Z. Li Internet-Draft Z. Du Intended status: Standards Track China Mobile Expires: 5 January 2027 J. Wang W. Cheng G. Zhang Centec X. Sun Inesa C. Zhao SAIA 4 July 2026 Coordinated CCM Interval Modification Procedures draft-li-opsawg-oam-interval-mod-00 Abstract In IEEE 802.1ag Connectivity Fault Management (CFM), the Continuity Check Message (CCM) interval is a static parameter that must match on both peer Maintenance End Points (MEPs). Changing the interval at runtime on one MEP without simultaneously updating the peer causes a Loss of Continuity (LOC) defect and may trigger protection switching. Because the CFM PDU formats and OpCode space are governed by IEEE 802.1, this document does not modify the protocol; instead, it specifies a coordinated management-plane procedure that transitions both MEPs to a new CCM interval without raising spurious defects or triggering protection switching, together with failure handling and rollback behavior. The procedure can be operated through existing configuration models such as the connection-oriented OAM YANG model. 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." Li, et al. Expires 5 January 2027 [Page 1] Internet-Draft OAM CCM Interval Mod July 2026 This Internet-Draft will expire on 5 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Relationship to Existing Standards . . . . . . . . . . . . . 3 4. Coordinated Interval Modification Procedure . . . . . . . . . 4 4.1. Phase 1: Defect Suppression Window . . . . . . . . . . . 4 4.2. Phase 2: Interval Application . . . . . . . . . . . . . . 4 4.3. Phase 3: Verification and Resumption . . . . . . . . . . 4 4.4. Failure Handling . . . . . . . . . . . . . . . . . . . . 5 5. YANG Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Manageability Considerations . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 10. Informative References . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Ethernet Connectivity Fault Management (CFM) [IEEE-802.1ag] [ITU-Y.1731] uses Continuity Check Messages (CCMs) for periodic connectivity verification between Maintenance End Points (MEPs). A receiving MEP declares Loss of Continuity (LOC) if no valid CCM arrives within 3.5 times the configured interval. [IEEE-802.1ag] defines eight interval values, ranging from 3.3 ms to 10 minutes, encoded as the 3-bit Period field in the CCM PDU. Li, et al. Expires 5 January 2027 [Page 2] Internet-Draft OAM CCM Interval Mod July 2026 Both peer MEPs in a Maintenance Association must use the same CCM interval. [IEEE-802.1ag] treats this interval as a static provisioning parameter set before session establishment. No in-band signaling exists to modify the interval during the session lifetime. When an operator needs to change the interval -- for example, increasing the rate during troubleshooting and reducing it afterward -- each MEP must be reconfigured separately. The time gap between the two reconfigurations creates a window of mismatched intervals that triggers LOC defects and may cause protection switching. The IETF's BFD protocol [RFC5880] includes built-in timer negotiation (Section 6.8.2 of [RFC5880]): each BFD Control packet carries the sender's desired intervals, and peers adjust continuously. Ethernet CCM lacks equivalent in-band interval signaling. This document specifies a coordinated management-plane procedure for CCM interval modification. 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 CFM terminology from [IEEE-802.1ag] and [ITU-Y.1731]. In this document, "CCM interval" and "CCM Period" both refer to the value encoded in the 3-bit Period field of the CCM PDU. Interval Learning State: A transient MEP state in which the MEP applies the interval value from the next received CCM carrying PC=1. 3. Relationship to Existing Standards [IEEE-802.1ag] and [ITU-Y.1731] define the CCM format, interval encoding, and LOC detection. This document extends CFM with a signaling procedure for runtime interval changes; it does not modify the existing CCM processing rules. [RFC5880] defines BFD with built- in timer negotiation. The procedure in this document serves the same operational purpose for CCM but is adapted to CCM's constraints. [RFC7369] specifies GMPLS extensions for CCM interval provisioning at session setup. This document addresses the case of interval changes after session establishment. [RFC8531] defines a YANG data model for connection-oriented OAM including CCM. The extension in this document is compatible with that model. Li, et al. Expires 5 January 2027 [Page 3] Internet-Draft OAM CCM Interval Mod July 2026 4. Coordinated Interval Modification Procedure This document defines a management-plane procedure that changes the CCM interval of an active Maintenance Association without inducing spurious LOC defects. The procedure does not modify the CCM PDU, define new CFM OpCodes or TLVs, or alter the CCM processing rules of [IEEE-802.1ag]; all protocol elements on the wire remain unchanged. The CFM PDU and OpCode space are governed by IEEE 802.1, and protocol extensions to CFM are outside the scope of the IETF. The procedure is executed by a coordinating management system (a controller or an orchestration function) that has configuration access to both MEPs, for example through the YANG model of [RFC8531]. 4.1. Phase 1: Defect Suppression Window The management system instructs both MEPs to enter a transition window in which LOC defect consequences are suppressed: alarm generation and protection-switching actions triggered by LOC for the affected Maintenance Association are temporarily inhibited. The window duration MUST be bounded by a configured value; a default of 3 times the larger of the old and new intervals plus the expected configuration propagation delay is RECOMMENDED. 4.2. Phase 2: Interval Application The management system reconfigures the CCM interval on both MEPs to the new value, in either order. During the window, interval mismatch between the two MEPs may cause CCM defect conditions (such as LOC at the MEP still running the shorter interval); these are suppressed per Phase 1 and clear once both MEPs operate at the new interval. 4.3. Phase 3: Verification and Resumption After confirming that both MEPs report the new interval and that CCM reception is healthy (no active LOC), the management system ends the transition window, restoring normal defect handling. If verification fails before the window expires, the management system MUST either roll both MEPs back to the previous interval or extend the window, and MUST raise an operator notification. Li, et al. Expires 5 January 2027 [Page 4] Internet-Draft OAM CCM Interval Mod July 2026 4.4. Failure Handling If connectivity to one MEP is lost mid-procedure, the management system MUST roll back the reachable MEP to the previous interval before the window expires. Because defect consequences are suppressed only for a bounded window, a genuine connectivity failure occurring during the window is reported at most one window-duration late; operators SHOULD size the window accordingly. 5. YANG Considerations The procedure can be executed with existing configuration models. A future revision of this document may define an augmentation to [RFC8531] providing: (1) a transition-window state with bounded duration and automatic expiry, and (2) an atomic interval-change action that encapsulates the three phases, so that a single management operation per MEP suffices. 6. Manageability Considerations Implementations SHOULD expose, per Maintenance Association: whether an interval modification is in progress, current and target interval values, transition-window status and remaining duration, and counters for successful, rolled-back, and failed modification attempts. 7. Security Considerations The procedure in this document operates entirely through the management plane. An attacker with management access could suppress defect consequences or change CCM intervals, disrupting fault detection; management interfaces used for this procedure MUST be authenticated and authorized, for example using the NETCONF access control model [RFC8341]. Defect-suppression windows are a temporary reduction in fault visibility; implementations MUST bound their duration and SHOULD log window entry, exit, and expiry as auditable events. Interval modification attempts SHOULD be rate-limited and logged. 8. IANA Considerations This document has no IANA actions. The CFM OpCode and TLV spaces are administered by IEEE 802.1 and are not affected by this document. 9. Normative References Li, et al. Expires 5 January 2027 [Page 5] Internet-Draft OAM CCM Interval Mod July 2026 [IEEE-802.1ag] IEEE, "IEEE Standard for Local and Metropolitan Area Networks -- Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", IEEE 802.1ag-2007, 2007. [ITU-Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet-based networks", ITU-T Y.1731, 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8531] Kumar, D., Wu, Q., and M. Wang, "Generic YANG Data Model for Connection-Oriented OAM Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019, . 10. Informative References [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC7369] Takacs, A., Gero, B., and H. Long, "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", RFC 7369, DOI 10.17487/RFC7369, October 2014, . Acknowledgements The BFD timer negotiation in RFC 5880 served as the design precedent for runtime interval signaling in continuity check protocols. Authors' Addresses Li, et al. Expires 5 January 2027 [Page 6] Internet-Draft OAM CCM Interval Mod July 2026 Zhiqiang Li China Mobile Beijing 100053 China Email: lizhiqiangyjy@chinamobile.com Zongpeng Du China Mobile Beijing 100053 China Email: duzongpeng@chinamobile.com Junjie Wang Centec Shanghai 201203 China Email: wangjj@centec.com Wei Cheng Centec Shanghai 201203 China Email: chengw@centec.com Guoying Zhang Centec Shanghai 201203 China Email: zhanggy@centec.com Xun Sun Inesa Shanghai 200030 China Email: sunxun@inesa.com Li, et al. Expires 5 January 2027 [Page 7] Internet-Draft OAM CCM Interval Mod July 2026 Chunhao Zhao SAIA Shanghai 200125 China Email: chunhao.zhao@sh-aia.com Li, et al. Expires 5 January 2027 [Page 8]