idnits 2.17.1 draft-txh-opsawg-lime-gap-analysis-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (September 26, 2014) is 3492 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'G.8010' is mentioned on line 191, but not defined == Missing Reference: 'MEF-17' is mentioned on line 248, but not defined == Missing Reference: 'RFC4560' is mentioned on line 263, but not defined == Missing Reference: 'RFC6241' is mentioned on line 350, but not defined == Unused Reference: 'IEEE802.1Q' is defined on line 383, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.8052' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.8110.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.8152' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Q' ** Downref: Normative reference to an Informational draft: draft-edprop-opsawg-multi-layer-oam-ps (ref. 'LIME-PS') ** Downref: Normative reference to an Informational draft: draft-king-opsawg-lime-multi-layer-oam-use-case (ref. 'LIME-UC') -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-30' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-31' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-35' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-36' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-38' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-39' ** Downref: Normative reference to an Informational RFC: RFC 6371 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Y. Tochio 3 Internet-Draft Fujitsu 4 Intended status: Standards Track H. van Helvoort 5 Expires: March 30, 2015 Hai Gaoming BV 6 L. Xia 7 Huawei 8 September 26, 2014 10 Gap Analysis for Layer and Technology Independent OAM Management in the 11 Multi-Layer Environment 12 draft-txh-opsawg-lime-gap-analysis-00 14 Abstract 16 This draft analyses the existing management plane OAM related works 17 in different SDOs, against the key objectives of Layer Independent 18 OAM Management (LIME), to find the gap between them. The results can 19 be used as the guidance for further work. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 30, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Existing OAM Related Works . . . . . . . . . . . . . . . . . 4 59 3.1. Management Information Models . . . . . . . . . . . . . . 5 60 3.2. IEEE CFM MIB . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. MEF SOAM FM and PM MIB . . . . . . . . . . . . . . . . . 6 62 3.4. IETF Technology-specific MIB Series . . . . . . . . . . . 7 63 3.5. MEF CFM and SOAM YANG Data Model . . . . . . . . . . . . 7 64 3.6. YANG Model for OAM Management and Technology-specific 65 extensions . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.7. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.7.1. Consolidation in the Management Plane . . . . . . . . 8 68 3.7.2. A Generic and Reusable OAM Data Model . . . . . . . . 8 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Operations, Administration, and Maintenance (OAM) mechanisms are 76 critical building blocks in network operations that are used for 77 service assurance, fulfillment, or service diagnosis, 78 troubleshooting, and repair. The current practice is maintenance and 79 troubleshooting are achieved per technology and per layer. The 80 operation process can be very cumbersome. 82 Due to this fact, [LIME-PS] discusses a valuable direction in 83 management plane by consolidating OAM information from each layer 84 using centralized management entity and have a unified and consistent 85 OAM view of multi-layer network. Operators can rely on consolidated 86 OAM management to correlate different layer OAM information (e.g., 87 fault, defects and network failure), and quickly identify the faulty 88 element with its layer information in the network path. The second 89 important objective of LIME is to achieve a layer and technology 90 independent OAM view of network and allow management application 91 present to the user an abstract view of this network and its 92 supporting layers that is strictly topological, free of any 93 technology specific information. This means an abstract and generic 94 OAM management model in management plane should be developed firstly, 95 and then any technology-specific OAM data model can be developed by 96 extending and inheriting from it. Generic OAM management model can 97 provide a consistent configuration, reporting, and presentation for 98 the OAM mechanisms. It also can mitigate the problem related to 99 specific OAM technology dependency. [LIME-UC] lists the key use case 100 for LIME application. 102 This draft analyses the existing management plane OAM related works 103 in several SDOs, against the key objectives of LIME, to find the gap 104 between them. The results can be used as the guidance for further 105 work. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119 [RFC2119]. 113 2.1. Terminology 115 DM Data Model 117 EMS Element Management System [G.8052] 119 IM Information Model 121 NMS Network Management System [G.8052] 123 MP Maintenance Point [802.1Q] 125 MEP Maintenance Entity Group End Point [Y.1731] [RFC6371] 127 MIP Maintenance Entity Group Intermediate Point [Y.1731] [RFC6371] 129 MEG Maintenance Entity Group [Y.1731] [RFC6371] 131 ME Maintenance Entity [Y.1731] [RFC6371] 133 MD Maintenance Domain [802.1Q] 134 MPLS Multiprotocol Label Switching 136 NE Network Element 138 NVO3 Network Virtualization Overlays 140 OAM Operations, Administration, and Maintenance [RFC6291] 142 LIME Layer Independent OAM Management [LIME-PS] 144 SF Service Function Chaining 146 SFF Service Function Forwarder 148 SDO Standard Developing Organization 150 3. Existing OAM Related Works 152 Two objectives of LIME are: 154 o Consolidated OAM Management 156 o Layer and technology independent OAM Management 158 To achieve these two objectives and accelerate Yang data model 159 development, we can use Existing Information model in ITU-T and MEF, 160 OAM MIB Module and CFM model as basis and directly develop Yang Data 161 model. 163 +---------------+ +---------------+ +----------+ 164 | Existing IM | | OAM MIB Module| | CFM Model| 165 | in MEF, ITU-T | | (IETF, IEEE, | | Y.1731 | 166 | (e.g.,MEF 7.1 | | MEF) | | | 167 | ITU-T G.8052) | +-------|-------+ +-----|----+ 168 +--------|------+ | | 169 | | | 170 -------------------|------------------| 171 +-----------------+ 172 | Yang Data Model | 173 |for OAM Management 174 +------+----------+ 175 | Augument/Inherit 176 +---------+-------------+ 177 |Specific technology OAM| 178 | Data Model | 179 +-----------------------+ 181 Yang Data Model Development 183 Following are the detailed surveys for the existing management plane 184 OAM works. 186 3.1. Management Information Models 188 ITU-T's Recommendation [G.8052] and [G.8152] provide the management 189 protocol-neutral information models for managing network elements in 190 the Ethernet transport network and MPLS-TP transport network as 191 defined in Recommendations [G.8010] and [G.8110.1] respectively. 192 They contain the object classes for the Ethernet and MPLS-TP NE 193 management. It includes the Termination Points (TP), Maintenance 194 Entity Group (MEG) End Point (MEP), MEG Intermediate Point (MIP), 195 Traffic Conditioning & Shaping (TCS), Loss Measurement (LM), Delay 196 Measurement (DM), and the general Performance Monitoring (PM) Current 197 Data (CD) and History Data (HD). [G.8052] has been published. 198 [G.8152] is still in progress. 200 [MEF-7.1] specifies the EMS-NMS interface profile identifying the 201 managed objects (i.e. logical UML objects) needed to support Metro 202 Ethernet services. This specification provides the profile of 203 management entities based on ITU-T [Q.840.1], and also provides a 204 mapping to the TMF's MTNM 3.5 Ethernet model. Specifically this 205 document adds management support for Service OAM. The Ethernet 206 Service OAM object definitions include common OAM objects (e.g., 207 EthMe, EthMeg, EthMep, EthMip, EthMp, EthMd, EthMepPeerInfo), Fault 208 Management Objects (e.g., Continuity Check, Loopback, Link Trace, 209 Signal Functions), Performance Monitoring Objects (e.g., Abstract 210 Performance Monitoring Objects, Loss Measurement, Delay Measurement, 211 Function Sets). 213 The above OAM information models provide the baseline for the further 214 definitions of OAM MIB modules and OAM YANG model. But they are 215 still technology-specific definitions, not abstract and generic 216 enough. 218 3.2. IEEE CFM MIB 220 The IEEE8021-CFM-MIB MIB Module and IEEE8021-CFM-V2-MIB MIB module 221 are CFM MIB modules for managing IEEE CFM in [802.1Q]. The former 222 document defines all the MIB objects that used to read, create, 223 modify, and delete OAM related information (i.e., CFM Stack Table, MD 224 Table, MA Table, MEP Table, LinkTrace Reply Table, MEP DB Table, 225 Notifications Table, etc). The latter document defines CFM V2 module 226 for managing IEEE CFM. It contains objects that replace those 227 deprecated in the IEEE8021-CFM-MIB module (i.e., CFM Stack Table, CFM 228 Vlan Table, CFM Default MD Level Table, etc). 230 These CFM MIB modules defined for Ethernet network are the input for 231 analyzing what the generic OAM data model should be and have. 233 3.3. MEF SOAM FM and PM MIB 235 [MEF-31] defines the MIB modules for MEF Service OAM Fault Management 236 (FM). This document includes two MIBs necessary to support the MEF 237 SOAM FM functionality: the MEF-SOAM-TC-MIB that includes the Textual 238 Conventions (TC) for the SOAM MIB family and the MEF-SOAM-FM-MIB that 239 includes extensions to Connectivity Fault Management (CFM) as 240 developed in IEEE [802.1Q], including MIBs found in [IEEE 802.1Q] and 241 [IEEE 802.1ap], and enhanced by ITU-T [Y.1731] to support the SOAM FM 242 functions as presented in the [MEF-30] specification. It includes 243 the SOAM FM MIB objects such as mefSoamNet, mefSoamMeg, mefSoamMep, 244 mefSoamCc, mefSoamAis, mefSoamLb, etc. 246 [MEF-36] specifies the Performance Monitoring (PM) MIB necessary to 247 manage SOAM implementations that satisfy the Service OAM requirements 248 and framework specified by [MEF-17], the Service OAM Performance 249 Monitoring requirements as specified by [MEF-35], and the Service OAM 250 management objects as specified by [MEF-7.1] which are applicable to 251 Performance Monitoring functions. Two non-MEF documents serve as the 252 baseline documents for this work: ITU-T [Y.1731] and IEEE [802.1Q]. 253 The SOAM PM MIB is divided into a number of different object 254 groupings: the PM MIB MEP Objects, PM MIB Loss Measurement Objects, 255 PM MIB Delay Measurement Objects, and SOAM PM Notifications. 257 These documents' MIB definitions are also in the Ethernet layer and 258 are the input for the LIME works. 260 3.4. IETF Technology-specific MIB Series 262 IETF specifies a series MIB module for various technologies, which 263 includes: [RFC7331] for BFD MIB, [RFC4560] for PING MIB, [MPLS-TP OAM 264 ID MIB] for MPLS-TP MIB, etc. 266 All these documents are technology-specific and limited to layer 267 1/2/3. The OAM MIB definition above layer 3 (i.e., SFC service 268 layer) is still missing in IETF. Further study is needed to abstract 269 a unified and general OAM data model for any network layers from them 270 and other SDOs' OAM works. 272 3.5. MEF CFM and SOAM YANG Data Model 274 SOAM CFM YANG module [MEF-38] is an important work that defines the 275 managed objects necessary to support SOAM CFM functionality by using 276 the IETF YANG Module Language [RFC6020]. This YANG module contains 277 the management data definitions for the management of Ethernet 278 Services OAM for Connectivity Fault Management. 280 [MEF-39] provides the YANG module that supports the Ethernet Service 281 OAM (SOAM) Performance Monitoring functions. This YANG module 282 contains the management data definitions for the management of 283 Ethernet Services OAM for Performance Monitoring and extends the 284 Connectivity Fault Management (CFM) YANG modules. 286 These MEF OAM YANG works are important reference for the LIME works. 288 3.6. YANG Model for OAM Management and Technology-specific extensions 290 [I-D.tissa-netmod-oam] is an IETF work that creates a YANG unified 291 data model for OAM that is based on IEEE CFM model. This model may 292 be used also for IP OAM functionality. This effort is focused on the 293 management plane of OAM and should be complemented by an accompanying 294 data-plane and/or control-plane work. It may require also some 295 extensions to support wider variety of functions and technologies. 297 [I-D.tissa-nvo3-yang-oam] extends the Generic YANG model defined in 298 [I-D.tissa-netmod-oam] for OAM with NVO3 technology specifics and 299 presents Yang Module for NVO3 OAM. 301 3.7. Discussion 303 Until now, all the OAM data models and operations in the management 304 plane are technology dependent and limited to one specific layer. 306 3.7.1. Consolidation in the Management Plane 308 Consolidation means here the management functions are capable of 309 receiving and reacting to related information from every transport 310 segment at every layer in the network. The reacting to related 311 information from every layer can include: 313 o Synthesize the OAM information from every layer; 315 o Exchange and correlation between the OAM information from every 316 layer; 318 o Orchestrating and coordinating the OAM operations among every 319 layer based on the above information for an end to end service. 321 However, there is little consolidation of OAM in management plane nor 322 well-documented inter-layer OAM operations within current MIB 323 definition works by IEEE, MEF or IETF, and YANG model definition work 324 by MEF. This also results in an end to end and service-level OAM 325 view of network is hardly generated in the management plane. 327 In addition to consolidation, a layer and technology independent OAM 328 view of network is also important for multi-layer OAM. The challenge 329 to get this view is to abstract in a way that retains in the 330 management plane as much useful information as possible while 331 filtering the data that is not needed to be leaked to layers in the 332 data plane. An important part of this effort is a clear 333 understanding of what information is actually needed. Current 334 existing OAM works in various SDOs do not consider this issue now. 336 3.7.2. A Generic and Reusable OAM Data Model 338 Another aspect is about the OAM data model specification. The 339 existing traditional implementations of data models in management 340 plane, such as MIB, YANG, are all technology-specific. They specify 341 the MIB module or YANG model for specific technology respectively. 342 There are many overlapping contents and repeated works during specify 343 data model for any technologies. The same condition happens each 344 time when a new technology needs to specify its own data model in 345 management plane. 347 So, a generic and reusable OAM data model is essential and valuable 348 for this kind of work. And to the extent that management operations 349 are being redesigned in terms of YANG modules [RFC6020] over NETCONF 350 [RFC6241], the opportunity appears to use the concept of layer and 351 technology independent abstraction to extract the reusable parts, 352 simplifying the work on the remainder. 354 4. Security Considerations 356 TBD. 358 5. Normative References 360 [G.8052] "Protocol-neutral management information model for the 361 Ethernet transport capable network element", Draft 362 Recommendation ITU-T G.8052/Y.1346, August 2013. 364 [G.8110.1] 365 "Architecture of MPLS Transport Profile (MPLS-TP) layer 366 network", ITU-T G.8110.1/Y.1370.1, December 2011. 368 [G.8152] "Protocol-neutral management information model for the 369 MPLS-TP network element", Draft Recommendation ITU-T 370 G.8152/Y.1375, September 2015. 372 [I-D.tissa-netmod-oam] 373 Senevirathne, T., Finn, N., Kumar, D., Salam, S., and C. 374 Pignataro, "YANG Data Model for Generic Operations, 375 Administration, and Maintenance (OAM)", draft-tissa- 376 netmod-oam-01 (work in progress), June 2014. 378 [I-D.tissa-nvo3-yang-oam] 379 Senevirathne, T., "YANG Data Model for NVO3 Operations, 380 Administration, and Maintenance(OAM)", ID draft-tissa- 381 nvo3-yang-oam-00, June 2014. 383 [IEEE802.1Q] 384 "Media Access Control (MAC) Bridges and Virtual Bridged 385 Local Area Networks", IEEE Std 802.1Q-2011, August 2011. 387 [LIME-PS] Taylor, T., "Problem Statement for Layer and Technology 388 Independent OAM in a Multi-Layer Environment", ID draft- 389 edprop-opsawg-multi-layer-oam-ps, September 2014. 391 [LIME-UC] King, D., "Use Cases and Requirements for Layer 392 Independent OAM Management in multi-layer environments", 393 ID draft-king-opsawg-lime-multi-layer-oam-use-case, 394 September 2014. 396 [MEF-30] "Service OAM Fault Management Implementation Agreement", 397 MEF 30, January 2011. 399 [MEF-31] "Service OAM Fault Management Definition of Managed 400 Objects", MEF 31, January 2011. 402 [MEF-35] "Service OAM Performance Monitoring Implementation 403 Agreement", MEF 35, January 2012. 405 [MEF-36] "Service OAM SNMP MIB for Performance Monitoring", MEF 36, 406 January 2012. 408 [MEF-38] "Service OAM Fault Management YANG Modules", MEF 38, April 409 2012. 411 [MEF-39] "Service OAM Performance Monitoring YANG Module", MEF 39, 412 April 2012. 414 [MEF-7.1] "EMS-NMS Information Model -Phase 2", Metro Ethernet Forum 415 MEF 7.1, 2009. 417 [Q.840.1] "Requirements and Analysis for NMS-EMS Management 418 Interface of Ethernet over Transport and Metro Ethernet 419 Network", Draft Recommendation ITU-T Q.840.1, 2007. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", March 1997. 424 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 425 Network Configuration Protocol (NETCONF)", RFC 6020, 426 October 2010. 428 [RFC6291] Andersson, L., "Guidelines for the use of the "OAM" 429 Acronym in the IETF", RFC 6291, June 2011. 431 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 432 Maintenance Framework for MPLS-Based Transport Networks", 433 RFC 6371, September 2011. 435 [RFC7331] Nadeau, T., Ali, Z., and N. Akiya, "Bidirectional 436 Forwarding Detection (BFD) Management Information Base", 437 RFC 7331, August 2014. 439 [Y.1731] "OAM functions and mechanisms for Ethernet based 440 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 442 Authors' Addresses 444 Yuji Tochio 445 Fujitsu 447 Email: tochio@jp.fujitsu.com 449 Huub van Helvoort 450 Hai Gaoming BV 452 Email: huubatwork@gmail.com 454 Liang (Frank) Xia 455 Huawei 456 101 Software Avenue, Yuhua District 457 Nanjing, Jiangsu 210012 458 China 460 Email: Frank.xialiang@huawei.com