RFC 7319

RFC 7319: IANA Considerations for Connectivity Fault Management (CFM) Code Points 🎀

Title block (the vitals) 📋

• Author: D. Eastlake 3rd, Huawei 👩‍💻
• Date: July 2014 🗓️
• Category: Best Current Practice 🏆
• BCP: 191
• ISSN: 2070-1721
• Obsoletes/Updates: The title block doesn't list anything this one obsoletes or updates ✨

---

Abstract 🌸

okay so IEEE 802.1 wrote up Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities. CFM messages have an OpCode field and can carry TLV-structured info. IEEE 802.1 gave the IETF some blocks of CFM OpCodes and TLV Types to use. This doc is the rulebook for how values from those blocks get assigned, and it's giving organized 💅

Status of This Memo 🦋

This memo is an Internet Best Current Practice, so it's the official recommended way of doing things. 🧚

It's a product of the Internet Engineering Task Force (IETF), it reflects what the IETF community agreed on, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More BCP info is in Section 2 of RFC 5741 📚

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7319 🔗

Copyright Notice ⚖️

Copyright (c) 2014 IETF Trust and the document authors. All rights reserved 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, because they spell out what you can and can't do with this doc 🙈

Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 💖

Table of Contents 📑

• 1. Introduction ✨
  • 1.1. Terminology
• 2. IANA Considerations 🌷
• 3. Security Considerations 🔐
• 4. References 📚
  • 4.1. Normative References
  • 4.2. Informative References
• Appendix A. IEEE 802.1 WG Liaison 💌

---

1. Introduction ✨

The IEEE 802.1 Working Group specified Connectivity Fault Management (CFM) [802.1Q] OAM [RFC6291] facilities. CFM messages have an OpCode field and can carry TLV-structured information 🦋

IEEE 802.1 gave the IETF the block of 32 CFM OpCodes from 64 through 95, plus the block of 32 CFM TLV Types from 64 through 95. Check Appendix A for the paperwork. This document covers how values from those two blocks get handed out 💅

Before that, IEEE 802.1 had already given blocks from 32 through 63 to ITU-T [Y.1731]. Same energy, different group chat 🫶

1.1. Terminology 💜

Capitalized IANA terms like "Standards Action" get read the way [RFC5226] explains 📖

2. IANA Considerations 🎀

IANA set up the "Connectivity Fault Management (CFM) OAM IETF Parameters" registry, and it has two subregistries 👑

Here's the first one, for OpCodes:

Registry Name: CFM OAM IETF OpCodes

Registration Procedures: Standards Action

Reference: [802.1Q] [RFC7319]

Note: This parameter originates with the IEEE 802.1 Working Group
that has allocated the block of values from 64 to 95 to the IETF.

Value    Assignment
=====    ==========
64-95    Unassigned

And the second one, for TLV Types:

Registry Name: CFM OAM IETF TLV Types

Registration Procedures: Standards Action

Reference: [802.1Q] [RFC7319]

Note: This parameter originates with the IEEE 802.1 Working Group
that has allocated the block of values from 64 to 95 to the IETF.

Value    Assignment
=====    ==========
64-95    Unassigned

3. Security Considerations 🔐

Okay, this is the one place where I have to be real. This doc is about assigning values from the CFM OpCode and TLV Type blocks that IEEE 802.1 gave to the IETF. It isn't directly about security, so there's nothing security-specific to flag here 🙈

4. References 📚

4.1. Normative References 💎

[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

4.2. Informative References 🌟

[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.

[Y.1731] ITU-T, "OAM Functions and Mechanisms for Ethernet-based Networks", Recommendation G.8013/Y.1731, November 2013.

Appendix A. IEEE 802.1 WG Liaison 💌

The IEEE 802.1 WG sent this liaison, and the header is copied exactly here:

To:         Jari Arkko, IETF chair
cc:         Stephen J. Trowbridge, ITU-T SG15 chair,
            Donald Eastlake, Erik Nordmark, IETF TRILL WG,
            Eric Gray, IETF/IEEE liaison

From:       Tony Jeffree, IEEE 802.1 WG Chair

Date:       Thursday, 06 March 2014

Reference:  24 September 2013 Liaison from TRILL WG

The gist: after reading the TRILL WG liaison, IEEE 802.1 voted to approve handing over code points from the Connectivity Fault Management protocol of IEEE Std 802.1Q(TM)-2011 for IETF use. IEEE expects these code points to be allocated through IANA only on the basis of IETF standards actions. The allocation covers:

+ 32 CFM OpCode Field values. Reference IEEE Std 802.1Q-2011

  Clause 21.4.3, Table 21-4. The OpCode Field values 64-95
                                                          10
  are allocated to the IETF.


+ 32 TLV Type Field values. Reference IEEE Std 802.1Q-2011

  Clause 21.5.1.1, Table 21-6. The Type Field values 64-95
                                                          10
  are allocated to the IETF.

IEEE Std 802.1Q will be revised someday to document this allocation. Until then, the allocation gets recorded through the IEEE 802.1 maintenance process 🫶

Regards,

Tony Jeffree
IEEE 802.1 Working Group Chair

Author's Address 🏠

Donald Eastlake 3rd
Huawei
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com