idnits 2.17.1 draft-andersson-mpls-tp-oam-def-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 15, 2009) is 5577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T I-610' is mentioned on line 151, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Redback Networks 4 Intended status: Informational M. Betts 5 Expires: July 19, 2009 Nortel 6 R. Bonica 7 Juniper Networks 8 H. van Helvoort 9 Huawei Technologies 10 D. Romascanu 11 Avaya 12 January 15, 2009 14 "The OAM Acronym Soup" 15 draft-andersson-mpls-tp-oam-def-01.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 19, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 At first glance the acronym "OAM" seems to be well known and well 55 understood. Looking at it a bit more closely reveals a set of 56 recurring problems that are revisited time and again. This document 57 has one primary and a secondary goal. The primary goal is to find an 58 understanding of OAM that is feasible for the MPLS Transport Profile 59 (MPLS-TP)effort. The secondary goal is to make this understanding 60 applicable in a wider scope 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. OAM and O, A and M . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. OAM as a functional unit . . . . . . . . . . . . . . . . . 6 67 2.2. The acronym broken up . . . . . . . . . . . . . . . . . . 6 68 2.2.1. O in OAM . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2.2. A in OAM . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.2.3. M in OAM . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Use of the OAM acronym MPLS-TP effort . . . . . . . . . . . . 8 72 4. Acronyms for the MPLS-TP effort . . . . . . . . . . . . . . . 10 73 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 74 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 8.2. Informative references . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The state of this work is very much "work in progress" and the 84 discussion is ongoing. The reason to publish the draft at this stage 85 is that some of the relevant MPLS-TP drafts are getting close to 86 working group last call and some of the directives in this document 87 is needed for consistency within that group af draft. 89 The acronym OAM is frequently used in the data- and telecommunication 90 industry. One would assume that something that is so widely used is 91 very clearly defined. However a closer look reveals some points that 92 needs to be clarified. 94 The examples used below comes mainly from the first set of MPLS-TP 95 IDs. In the IDs there were a number of examples of how the acronym 96 could be a number of ways to expand and understand the acronym e.g.: 98 o OAM = Operations, Administration, Maintenance 100 o OAM = Operations, Administration, Management 102 o OAM = Operations and Maintenance 104 o OAM = Operations and Management 106 o O&M = Operations and Maintenance 108 o O&M = Operations and Management 110 The examples above were taken from drafts that later has been 111 corrected and aligned with what is proposed in this document. 113 Sometimes there is a fourth letter added to the acronym: 115 o OAM and P = Operations, Administration, Maintenance and 116 Provisioning 118 If such an important piece of our technology is so poorly defined, or 119 if there are dialects of the technology with different understandings 120 of such a key concept, this will eventually cause problems. 122 Trying to understand the use of an acronym that is as "content-rich" 123 as OAM reveals two levels of complexity. First, each letter in the 124 acronym represent a integrated piece of functionality; secondly the 125 acronym as such represent something that is more than just the sum of 126 the pieces 128 There is also the issue of how each piece of the acronym is defined. 130 In this document we will analyse how each piece of the acronym is 131 defined and provide possible interpretations of the acronym. Finally 132 we will suggest the use of the OAM acronym for the MPLS-TP effort 133 based on the greement reached based on the JWT report 134 [I-D.bryant-mpls-tp-jwt-report]. 136 Our immediate target is to document the use of the OAM acronym such 137 that it is useful for MPLS-TP. However, we hope to shed some light 138 on the issue in a broader scope. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. OAM and O, A and M 146 2.1. OAM as a functional unit 148 Operations, Administration, and Maintenance (OAM): A group of network 149 management functions that provide network fault indication, 150 performance information, and data and diagnosis functions. Examples 151 are ATM OAM [ITU-T I-610] and IEEE Std. 802.3 Clause 57 OAM 153 Alternatively (Huub :) ) 155 Operations, Administration, and Maintenance (OAM): A group of network 156 management functions that provide network fault indication, fault 157 localisation performance information, and data and diagnosis 158 functions. 160 ITU-T M.3010 recommendation defines: 162 operations systems function: A function block that processes 163 information related to the telecommunications management for the 164 purpose of monitoring/coordinating and/or controlling 165 telecommunication functions including management functions (i.e. the 166 TMN itself). 168 The Metro Ethernet Forum refers to OAM as to: OAM refers to the tools 169 and utilities to install, monitor and troubleshoot a network, helping 170 carriers run their networks more efficiently. 172 Note: the paragraphs above are so far just placeholders. 174 2.2. The acronym broken up 176 2.2.1. O in OAM 178 The O in the OAM acronym invariably stands for "Operations". 180 However there is some ambivalences in the definition and scope of 181 "Operation" 183 Note: Examples to be provided. 185 2.2.2. A in OAM 187 The A in the OAM acronym mostly stands for "Adminstration", though in 188 a few cases it seems like "Accounting" have crept in. For the 189 purpose of this document we will assume that "Adminstration" is the 190 correct expansion of "A". 192 Note: Examples to be provided. 194 Admistration is used to support maintenance functions, e.g. by 195 collecting failure and performance information, continuous or on- 196 demand. 198 2.2.3. M in OAM 200 In the list above the M in the OAM acronym stands for "Maintenance" 201 or "Management". 203 Since Maintenance and Management are defined as two different 204 actvities it does not seem to be a good idea to use them 205 interchangeably. 207 Note: Examples to be provided. 209 The recommendation M.20 from ITU-T defines mainteance: 211 Maintenance involves the whole of operations required for setting up 212 and maintaining, within prescribed limits, any element entering into 213 the setting-up of a connection (see Recommendation M.60). In order 214 to properly plan and program the maintenance operations required to 215 establish and maintain a network. 217 It should have as a major aim to minimize both the occurrence and the 218 impact of failures and to ensure that in cause of a failure the 219 correct actions are taken. The ITU-T document also clearly defines a 220 maintenace philosphy. 222 3. Use of the OAM acronym MPLS-TP effort 224 In Section 4 we list the acronyms as they will be used in the MPLS-TP 225 effort, this section gives somwe background. 227 If we need as an abbreviation for "Management" we will use "Mgt". We 228 do not define Management in this draft, but note that an important 229 part of the Management funtionality relates to tools to report the 230 state of the network. 232 We propose that the OAM acronym is reserved to be used for 233 "Operations, Administration and Maintenance", i.e. excluding 234 provisioning. 236 OAM tools and protocols and the "Management space" are complementary 237 in natur. Management focuses on FCAPS functionality and on manager 238 (or NOC) to device (or network) interaction. 240 From an architecture point of view OAM protocols and tools tend to be 241 "horizontal" i.e. network element to network element while the 242 management protocols tend to be "vertical" 244 Where each part of the acronym and provisioning is defined as 245 follows: 247 o Operations - Operation activities is undertaken to keep the 248 network (and the services that the network provides) up and 249 running. It includes monitoring the network and find problems. 250 Ideally these problems should be found before users are affected." 252 o Administration - Administration activities involves keeping track 253 of resources in the network and how they are used. It includes 254 all the book keeping that is necessary to keep track of networking 255 resources and the network under control. 257 o Maintenance - Maintenance activities are focused on facilitating 258 repairs and upgrades - for example, when equipment must be 259 replaced, when a router needs a patch for an operating system 260 image, when a new switch is added to a network. Maintenance also 261 involves corrective and preventive measures to make the managed 262 network run more efficient, e.g. adjusting device configuration 263 and parameters. 265 o Even though we don't include "Provisioning" in the OAM acronym we 266 note that: 268 Provisioning - Provisioning activities involves configuring 269 resources in the network to support the offered services. This 270 might include setting up the network so that a new customer can 271 receive an Internet access service. 273 o We also note that sometimes it is necessary to talk about the 274 combination of functions and tools suplied by OAM and Management, 275 we prefer that this is spelled out as "OAM and Management". In 276 cases where an acronym is needed O&M should be used. 278 4. Acronyms for the MPLS-TP effort 280 OAM - Operations, Adminstration and Maintenance 282 O&M - Operations, Adminstration, Maintenance and Management 284 "Mgt" - Management 286 5. IANA considerations 288 There are no requests for IANA allocation of code points in this 289 document. 291 6. Security considerations 293 This document only changes the name of one field in the MPLS Shim 294 Header and thus does not introduce any new security considerations. 296 7. Acknowledgments 298 - 300 8. References 302 8.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 8.2. Informative references 309 [I-D.bryant-mpls-tp-jwt-report] 310 Bryant, S. and L. Andersson, "JWT Report on MPLS 311 Architectural Considerations for a Transport Profile", 312 draft-bryant-mpls-tp-jwt-report-00 (work in progress), 313 July 2008. 315 Authors' Addresses 317 Loa Andersson 318 Redback Networks 320 Email: loa@pi.nu 322 Malcolm Betts 323 Nortel 325 Email: betts01@nortel.com 327 Ron Bonica 328 Juniper Networks 330 Email: rbonica@juniper.net 332 Huub van Helvoort 333 Huawei Technologies 335 Email: hhelvoort@chello.nl 337 Dan Romascanu 338 Avaya 340 Email: dromasca@avaya.com