Coordinated CCM Interval Modification Procedures
draft-li-opsawg-oam-interval-mod-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [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,
              <https://www.rfc-editor.org/info/rfc8531>.

10.  Informative References

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC7369]  Takacs, A., Gero, B., and H. Long, "GMPLS RSVP-TE
              Extensions for Ethernet OAM Configuration", RFC 7369,
              DOI 10.17487/RFC7369, October 2014,
              <https://www.rfc-editor.org/info/rfc7369>.

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]