RFC 6905

Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)

📅 published March 2013, from ietf

RFC 6905 🎀

Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)

Okay bestie, let's start with the title block 🦋 It's an IETF document, and the authors are T. Senevirathne (Cisco), D. Bond (IBM), S. Aldrin and Y. Li (Huawei), and R. Watve (Cisco) ✨

  • Category: Informational, so it's published for information and is not a standards track spec 💅
  • ISSN: 2070-1721
  • Date: March 2013
  • Obsoletes / Updates: the header doesn't list any RFCs it obsoletes or updates 🌸

Abstract

Okay so, Operations, Administration, and Maintenance (OAM) is the umbrella term for the functions and toolsets people use to troubleshoot and monitor networks 🔍 This document lays out the OAM requirements for Transparent Interconnection of Lots of Links (TRILL) 💜

Status of This Memo

This document is not an Internet Standards Track specification, so it's published for informational purposes 🧚

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🤓

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6905 ✨

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💖

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Scope ......................................................3
   2. Conventions Used in This Document ...............................3
   3. Terminology .....................................................3
   4. OAM Requirements ................................................4
      4.1. Data Plane .................................................4
      4.2. Connectivity Verification ..................................5
           4.2.1. Unicast .............................................5
           4.2.2. Distribution Trees ..................................5
      4.3. Continuity Check ...........................................5
      4.4. Path Tracing ...............................................6
      4.5. General Requirements .......................................6
      4.6. Performance Monitoring .....................................7
           4.6.1. Packet Loss .........................................7
           4.6.2. Packet Delay ........................................7
      4.7. ECMP Utilization ...........................................8
      4.8. Security and Operational Considerations ....................8
      4.9. Fault Indications ..........................................8
      4.10. Defect Indications ........................................9
      4.11. Live Traffic Monitoring ...................................9
   5. Security Considerations .........................................9
   6. References ......................................................9
      6.1. Normative References .......................................9
      6.2. Informative References ....................................10
   7. Acknowledgments ................................................11
   8. Contributors ...................................................11

1. Introduction ✨

OAM generally covers the many production-side aspects of a network 🛠️ In this document we use the term OAM as defined in [RFC6291] 💅

Network operations only work if you can proactively monitor for faults, performance, and so on, and if you can troubleshoot defects and failures quickly and efficiently 👀 A well-defined OAM toolset is a must-have if TRILL is going to get wider adoption as the next-generation data-forwarding technology in bigger networks, like data centers 🏢🔥

This document defines the requirements for TRILL OAM. It assumes readers already know the OAM concepts and terminology from other OAM standards, such as [8021ag], [RFC5860], and [RFC4377], and it doesn't try to redefine the terms and concepts specified elsewhere 🦋

1.1. Scope

The scope here is OAM between Routing Bridges (RBridges) of a TRILL campus, over links selected by TRILL routing 🌸

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Even though this document isn't a protocol specification, using this language makes the instructions clearer for protocol designers building solutions that meet the requirements in this document 🎀

These capitalised words are the official requirement language, so when you see them, they carry real weight. 💀

3. Terminology

Section: This term refers to a segment of a path between any two given RBridges. Say RB1 is connected to RBx via RB2, RB3, and RB4. The segment between RB2 to RB4 is referred to as a section of the path RB1 to RBx. More details of this definition can be found in [RFC5960] 🧚

Flow: This term indicates a set of packets that share the same path and per-hop behavior (such as priority). A flow is typically identified by a portion of the inner payload that affects the hop-by-hop forwarding decisions. This may contain Layer 2 through Layer 4 information 💜

All Selectable Least-Cost Paths: This term refers to a subset of all potentially available least-cost paths to a specified destination RBridge that are available (and usable) for forwarding of frames. In practice, due to limitations in implementations, not all available least-cost paths may be selectable for forwarding, and that's important to note 🙈

Connectivity: This term indicates reachability between an arbitrary RBridge RB1 and any other RBridge RB2. The specific path can be either explicit (i.e., associated with a specific flow) or unspecified. Unspecified means that messages used for connectivity verification take whatever path the RBs happen to select. Please refer to [OAMOVER] for details 🌈

Continuity Verification: This term refers to proactive verification of liveliness between two RBridges at periodic intervals, plus the generation of explicit notification when connectivity failures occur. Please refer to [OAMOVER] for details 💖

Fault: This term refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Please refer to [TERMTP] for definition 😭

Defect: This term refers to an interruption in normal operation, such that over a period of time no packets are delivered successfully. Please refer to [TERMTP] for definition ⭐

Failure: This term refers to the termination of the required function over a longer period of time. Persistence of a defect for a period of time is interpreted as a failure. Please refer to [TERMTP] for definition 🔥

Simulated Flow: This term refers to a sequence of OAM-generated packets designed to follow a specific path. The fields of the packets in the simulated flow may or may not be identical to the fields of data packets of an actual flow being simulated. However, the purpose of the simulated flow is to have OAM packets of the simulated flow follow a specific path 🦋

4. OAM Requirements 👑

4.1. Data Plane

OAM frames, used for connectivity verification, continuity checks, performance measurements, and so on, will by default take whatever path TRILL chooses based on the current topology and per-hop equal-cost path choices. In some cases, the OAM frames may be required to use specific paths. So it MUST be possible to arrange that OAM frames follow the path taken by a specific flow 🛤️

RBridges MUST have the ability to identify frames that require OAM processing 🔍

TRILL OAM frames MUST remain within a TRILL campus and MUST NOT be egressed from a TRILL network as native frames 🚫

OAM MUST have the ability to include all Ethernet traffic types carried by TRILL 🌸

4.2. Connectivity Verification

4.2.1. Unicast

From an arbitrary RBridge RB1, OAM MUST have the ability to verify connectivity to any other RBridge RB2 ✨

From an arbitrary RBridge RB1, OAM MUST have the ability to verify connectivity to any other RBridge RB2 for a specific flow, via the path associated with the specified flow 💅

4.2.2. Distribution Trees

OAM MUST have the ability to verify connectivity from an arbitrary RBridge RB1 to either a specific set of RBridges or all member RBridges, for a specified distribution tree. This functionality is referred to as verification of the unpruned distribution tree 🌳

OAM MUST have the ability to verify connectivity from an arbitrary RBridge RB1 to either a specific set of RBridges or all member RBridges, for a specified distribution tree and for a specified flow. This functionality is referred to as verification of the pruned tree 🌿

4.3. Continuity Check

OAM MUST provide functions that allow any arbitrary RBridge RB1 to perform a Continuity Check to any other RBridge 💓

OAM MUST provide functions that allow any arbitrary RBridge RB1 to perform a Continuity Check to any other RBridge using a path associated with a specified flow 💜

OAM SHOULD provide functions that allow any arbitrary RBridge to perform a Continuity Check to any other RBridge over any section of any selectable least-cost path 🌈

OAM SHOULD provide the ability to perform a Continuity Check on sections of any selectable path within the network 🧚

OAM SHOULD provide the ability to perform a multicast Continuity Check for specified distribution tree(s), as well as specified combinations of distribution trees and flows. The former is referred to as an unpruned multi-destination tree Continuity Check, and the latter is referred to as a pruned tree Continuity Check 🦋

4.4. Path Tracing

OAM MUST provide the ability to trace a path between any two RBridges corresponding to a specified unicast flow 🗺️

OAM SHOULD provide the ability to trace all selectable least-cost paths between any two RBridges 🛣️

OAM SHOULD provide functionality to trace all branches of a specified distribution tree (unpruned tree) 🌳

OAM SHOULD provide functionality to trace all branches of a specified distribution tree for a specified flow (pruned tree) 🌿

4.5. General Requirements 💅

Okay bestie, OAM MUST provide the ability to start and keep up multiple concurrent sessions for multiple OAM functions between any arbitrary RBridge RB1 and any other RBridge 🦋. Multiple OAM operations are basically always running at the same time. For example, proactive continuity checks might be happening between RB1 and RB2 while an operator decides to test connectivity between those same two RBs. Multiple OAM functions and instances of those functions MUST be able to run concurrently without interfering with each other 🫶.

OAM MUST provide a single OAM framework for all TRILL OAM functions within the scope of this document ✨.

OAM, as practical and as possible, SHOULD reuse functional, operational, and semantic elements of existing OAM standards 🌸.

OAM MUST maintain related error and operational counters. Those counters MUST be accessible via network management applications (e.g., SNMP) 📊.

OAM functions related to continuity and connectivity checks MUST be able to be invoked either proactively or on demand 🧚.

OAM MAY be required to provide the ability to specify a desired response mode for a specific OAM message. The desired response mode can be in-band, out-of-band, or none 🎀.

The OAM Framework MUST be extensible to include new functionality. For example, the solution needs to include a version number so older and newer implementations can be told apart, plus TLV structures for flexibility to include new information elements 🌈.

OAM MAY provide methods to verify control-plane and forwarding-plane alignments 💜.

OAM SHOULD leverage existing OAM technologies, where practical 👑.

4.6. Performance Monitoring 📈

4.6.1. Packet Loss 🫠

Here the term "packet loss" is used as defined in Section 2.4 of [RFC2680], so we're all on the same page 📖.

OAM SHOULD provide the ability to measure packet loss statistics for a flow from any arbitrary RBridge RB1 to any other RBridge 🍓.

OAM SHOULD provide the ability to measure packet loss statistics over a section for a flow between any arbitrary RBridge RB1 and any other RBridge 🔍.

OAM SHOULD provide the ability to measure packet loss statistics between any two RBridges over all least-cost paths 🛣️.

An RBridge SHOULD be able to perform the above packet loss measurement functions either proactively or on demand ⭐.

4.6.2. Packet Delay ⏱️

There are two types of packet delays, one-way delay and two-way delay (Round-Trip Delay) 💫.

One-way delay is defined in [RFC2679] as the time elapsed from the start of transmission of the first bit of a packet by an RBridge until the reception of the last bit of the packet by the destination RBridge 📦.

Two-way delay is also referred to as Round-Trip Delay and is defined similarly to [RFC2681]. So basically it's the time elapsed from the start of transmission of the first bit of a packet from RB1, then receipt of the packet at RB2, then RB2 sending a response packet back to RB1, and finally RB1 receiving the last bit of that response packet 🔁.

OAM SHOULD provide functions to measure two-way delay between two RBridges 🏓.

OAM MAY provide functions to measure one-way delay between two RBridges for a specified flow 🦋.

OAM MAY provide functions to measure one-way delay between two RBridges for a specified flow over a specific section 🌷.

4.7. ECMP Utilization 🔀

OAM MAY provide functionality to monitor the effectiveness of per-hop Equal-Cost Multipath (ECMP) hashing. For example, individual RBridges could maintain counters that show how packets are being distributed across equal-cost next hops for a specified destination RBridge or RBridges as a result of ECMP hashing 🧮.

4.8. Security and Operational Considerations 🔐

Okay this section is SERIOUS bestie. Read it twice.

Methods MUST be provided to protect against exploitation of the OAM framework for security and denial-of-service attacks 🚨.

Methods MUST be provided to prevent OAM messages from causing congestion in the networks. Periodically generated messages with high frequencies may lead to congestion, so methods such as shaping or rate limiting SHOULD be utilized 🚦.

Certain OAM functions may be used to gather operational information, such as the topology of the network. Methods MUST be provided to prevent unauthorized users from accessing OAM functions to gather critical and sensitive information about the network 🕵️.

OAM packets MUST be limited to within the TRILL campus, and the implementation MUST provide methods to prevent leaking of OAM packets out of the TRILL campus. Additionally, methods MUST be provided to prevent accepting OAM packets from outside the TRILL campus 🚧.

4.9. Fault Indications ⚠️

OAM MUST provide a Fault Indication framework to notify the packet's ingress RBridge or other interested parties (such as syslog servers) about faults 📣.

OAM MUST provide functions to selectively enable or disable different types of Fault Indications 🎛️.

4.10. Defect Indications 🩺

OAM SHOULD provide a framework for Defect Detection and Indication 🔎.

The OAM Defect Detection and Indication Framework SHOULD provide methods to selectively enable or disable Defect Detection per defect type 🔘.

The OAM Defect Detection and Indication Framework SHOULD provide methods to configure Defect Detection thresholds per different types of defects 📏.

The OAM Defect Detection and Indication Framework SHOULD provide methods to log defect indications to a locally defined archive (such as a log buffer) or Simple Network Management Protocol (SNMP) traps 📝.

The OAM Defect Detection and Indication Framework SHOULD provide a Remote Defect Indication framework that facilitates notifying the originator/owner of the flow experiencing the defect, which is the ingress RBridge 💌.

Remote Defect Indication MAY be either in-band or out-of-band 🌐.

4.11. Live Traffic Monitoring 📡

OAM implementations MAY provide methods to utilize live traffic for troubleshooting and performance monitoring 🕹️.

5. Security Considerations 🛡️

Security requirements are specified in Section 4.8. For general TRILL security considerations, please refer to [RFC6325] 🔒.

6. References 📚

6.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[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.

6.2. Informative References

[8021ag]   IEEE, "Virtual Bridged Local Area Networks Amendment 5:
           Connectivity Fault Management", IEEE Std 802.1ag-2007,
           2007.

[OAMOVER]  Mizrahi, T., Sprecher, N., Bellagamba, E., Y. Weingarten,
           "An Overview of Operations, Administration, and
           Maintenance (OAM) Mechanisms", Work in Progress, January
           2013.

[RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
           Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
           Packet Loss Metric for IPPM", RFC 2680, September 1999.

[RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
           Delay Metric for IPPM", RFC 2681, September 1999.

[RFC4377]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
           Matsushima, "Operations and Management (OAM) Requirements
           for Multi-Protocol Label Switched (MPLS) Networks", RFC
           4377, February 2006.

[RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
           "Requirements for Operations, Administration, and
           Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
           May 2010.

[RFC5960]  Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
           Transport Profile Data Plane Architecture", RFC 5960,
           August 2010.

[RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
           Ghanwani, "Routing Bridges (RBridges): Base Protocol
           Specification", RFC 6325, July 2011.

[TERMTP]   van Helvoort, H., Ed., Andersson, L., Ed., and N.
           Sprecher, Ed., "A Thesaurus for the Terminology used in
           Multiprotocol Label Switching Transport Profile (MPLS-TP)
           drafts/RFCs and ITU-T' Transport Network Recommendations",
           Work in Progress, February 2013.

7. Acknowledgments 🫶

Special shoutout to IEEE 802.1 chair, Tony Jeffree, for allowing us to solicit comments from the IEEE 802.1 group 🙌. Also recognized are the comments received from the IEEE group, IESG, Stewart Bryant, Ralph Droms, Adrian Farrel, Benoit Claise, Ayal Lior, and others 💖.

8. Contributors 🌟

Thomas Narten
IBM Corporation
3039 Cornwallis Avenue,
PO Box 12195
Research Triangle Park, NC 27709
USA

EMail:narten@us.ibm.com


Donald Eastlake
Huawei Technologies
155 Beaver Street,
Milford, MA 01757
USA

EMail: d3e3e3@gmail.com


Anoop Ghanwani
Dell
350 Holger Way
San Jose, CA 95134
USA

Phone: +1-408-571-3500
EMail: Anoop@alumni.duke.edu


Jon Hudson
Brocade
120 Holger Way
San Jose, CA 95134
USA

EMail: jon.hudson@gmail.com
Naveen Nimmu
Broadcom
9th Floor, Building no 9, Raheja Mind space
Hi-Tec City, Madhapur,
Hyderabad - 500 081
India

Phone: +1-408-218-8893
EMail: naveen@broadcom.com


Radia Perlman
Intel Labs
2700 156th Ave NE, Suite 300,
Bellevue, WA 98007
USA

Phone: +1-425-881-4824
EMail: radia.perlman@intel.com


Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692
Israel

EMail: talmi@marvell.com

Authors' Addresses 📮

Tissa Senevirathne
Cisco Systems
375 East Tasman Drive
San Jose, CA 95134
USA

Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
David Bond
IBM
4400 North 1st Street
San Jose, CA 95134
USA

Phone: +1-603-339-7575
EMail: mokon@mokon.net


Sam Aldrin
Huawei Technologies
2330 Central Express Way
Santa Clara, CA 95951
USA

EMail: aldrin.ietf@gmail.com


Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China

Phone: +86-25-56625375
EMail: liyizhou@huawei.com


Rohit Watve
Cisco Systems
375 East Tasman Drive
San Jose, CA 95134
USA

Phone: +1-408-424-2091
EMail: rwatve@cisco.com
📦 where this page comes from