idnits 2.17.1 draft-txh-lime-gap-analysis-04.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 (July 17, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-bfd-yang-06 == Outdated reference: A later version (-05) exists of draft-ietf-trill-yang-oam-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LIME Working Group Y. Tochio 3 Internet-Draft Fujitsu 4 Intended status: Informational H. van Helvoort 5 Expires: January 18, 2018 Hai Gaoming BV 6 L. Xia 7 Huawei 8 July 17, 2017 10 Gap Analysis for Layer and Technology Independent OAM Management in the 11 Multi-Layer Environment 12 draft-txh-lime-gap-analysis-04 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. This gap analysis is not 20 targeted at L0-L2 transport OAM in ITU-T, either technology specific 21 or generic across those technologies. Rather, it is intended to 22 leverage knowledge from that domain for the benefit of developing 23 generic layer independent OAM management for L3-L7 (and L2.5 MPLS 24 OAM). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 7, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Existing OAM Related Works . . . . . . . . . . . . . . . . . 4 64 3.1. Survey of ITU-T Work from L0-L2 . . . . . . . . . . . . . 5 65 3.1.1. Generic L0-L2 . . . . . . . . . . . . . . . . . . . . 5 66 3.1.2. Technology Specific L0-L2 . . . . . . . . . . . . . . 5 67 3.2. Management Information Models . . . . . . . . . . . . . . 5 68 3.3. IEEE CFM MIB . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. MEF SOAM FM and PM MIB . . . . . . . . . . . . . . . . . 6 70 3.5. IETF Technology-specific MIB Series . . . . . . . . . . . 7 71 3.6. IEEE CFM YANG . . . . . . . . . . . . . . . . . . . . . . 7 72 3.7. MEF CFM and SOAM YANG Data Model . . . . . . . . . . . . 7 73 3.8. YANG Model for OAM Management and Technology-specific 74 extensions . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.9. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Operations, Administration, and Maintenance (OAM) mechanisms are 85 critical building blocks in network operations that are used for 86 service assurance, fulfillment, or service diagnosis, 87 troubleshooting, and repair. The current practice is maintenance and 88 troubleshooting are achieved per technology and per layer. The 89 operation process can be very cumbersome. At present, within the 90 L0-L2 technology domains, considerable effort has been expended in 91 ITU-T to establish a coherent approach to OAM, including generic 92 layer independent principles. 94 Due to this fact, [I-D.edprop-opsawg-multi-layer-oam-ps] discusses a 95 valuable direction in management plane by establishing a coherent 96 approach to OAM information from L2.5-L7 using a centralized 97 management entity and have a unified and consistent OAM view of 98 multi-layer networks. Operators can rely on consolidated OAM 99 management to correlate different layer OAM information (e.g., fault, 100 defects and network failure), and quickly identify the faulty element 101 with its layer information in the network path. Note that current 102 LIME work focuses on layer-independent and technology-independent 103 configuration, reporting and presentation for OAM mechanisms in the 104 context of IP, MPLS, BFD, pseudowires, and Transparent 105 Interconnection of Lots of Links (TRILL) technology developed by 106 IETF. The second important objective of LIME is to achieve a layer 107 and technology independent OAM view of a network and allow management 108 applications present to the user an abstract view of this network and 109 its supporting layers that is strictly topological, free of any 110 technology specific information. This means an abstract and generic 111 OAM management model in the management plane should be utilized (with 112 extensions as appropriate to L2.5-L7), from which OAM specific views 113 can be established, and technology-specific OAM data models can be 114 developed by mapping from the information model view. A generic OAM 115 management model can provide a consistent configuration, reporting, 116 and presentation for the OAM mechanisms. It also can mitigate the 117 problem related to specific OAM technology dependency. 119 This draft analyses the existing management plane OAM related work in 120 several SDOs, against the key objectives of LIME, to find the gap 121 between them. The results can be used as the guidance for further 122 work. 124 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC2119 [RFC2119]. 130 2.1. Terminology 132 DM Data Model 134 EMS Element Management System 135 IM Information Model 137 NMS Network Management System 139 MP Maintenance Point [802.1Q] 141 MEG Maintenance Entity Group [G.8013] [RFC6371] 143 MEP MEG End Point [G.8013] [RFC6371] 145 MIP MEG Intermediate Point [G.8013] [RFC6371] 147 ME Maintenance Entity [G.8013] [RFC6371] 149 MD Maintenance Domain [802.1Q] 151 MPLS Multiprotocol Label Switching 153 NE Network Element 155 OAM Operations, Administration, and Maintenance [RFC6291] 157 LIME Layer Independent OAM Management 159 SFC Service Function Chaining 161 SFF Service Function Forwarder 163 SDO Standard Developing Organization 165 3. Existing OAM Related Works 167 3.1. Survey of ITU-T Work from L0-L2 169 3.1.1. Generic L0-L2 171 [G.800] and [G.805] specify the unified and generic functional 172 architecture of transport networks. [G.806] specifies the generic 173 processing of transport equipment functions, including handling of 174 OAM, defect correlation, and alarm suppression, etc. [G.7710] 175 specifies the generic management requirements for configuration, 176 fault, and performance (i.e. the C, F, P of FCAPS). [G.7711] is on- 177 going work in ITU-T to specify the generic management information 178 model for L0-L2 transport networks. 180 3.1.2. Technology Specific L0-L2 182 [G.803], [G.872], [G.8010] and [G.8110.1] specify the functional 183 architecture respectively for SDH, OTN, Ethernet, MPLS-TP transport 184 networks. [G.783], [G.798], [G.8021] and [G.8121] specify 185 respectively the processing of transport equipment functions for 186 SDH, OTN, Ethernet, MPLS-TP, including handling of OAM, and defect 187 correlation, and alarm suppression, etc. 188 [G.784], [G.874], [G.8051] and [G.8151] specify respectively the 189 management requirements for configuration, fault, and performance 190 (i.e. the C, F, P of FCAPS). [G.774], [G.874.1], [G.8052] and 191 [G.8152] specify respectively the management information model for 192 SDH, OTN, Ethernet, MPLS-TP transport networks. 194 3.2. Management Information Models 196 ITU-T's Recommendation [G.8052] and [G.8152] provide the management 197 protocol-neutral information models for managing network elements in 198 the Ethernet transport network and MPLS-TP transport network as 199 defined in Recommendations [G.8010] and [G.8110.1] respectively. The 200 management information models are derived from the "functional 201 models", which describe the data plane behavior and processing. 202 Management information models manage the "atomic functions" defined 203 in the data plane in transport networks. They contain the object 204 classes for the Ethernet and MPLS-TP NE management. This includes 205 the Termination Point (TP), Maintenance Entity Group (MEG) End Point 206 (MEP), MEG Intermediate Point (MIP), Traffic Conditioning & Shaping 207 (TCS), Loss Measurement (LM), Delay Measurement (DM), and the general 208 Performance Monitoring (PM), Current Data (CD) and History Data (HD). 209 [G.8052] has been published. [G.8152] is still in progress. There 210 is already some degree of consolidation among the /L0 (OTN) 211 [G.874.1], (SDH) [G.774]/, /L1 (OTN) [G.874.1], (SDH) [G.774]/ and 212 /L2 (Ethernet) [G.8052], (MPLS-TP) [G.8152]/ information models 213 specified by these ITU-T recommendations. In fact, they have a 214 common basis for information model and are not technology-specific 215 models any more. 217 [MEF-7.1] specifies the EMS-NMS interface profile identifying the 218 managed objects (i.e. logical UML objects) needed to support Metro 219 Ethernet services. This specification provides the profile of 220 management entities based on ITU-T [Q.840.1], and also provides a 221 mapping to the TMF's MTNM 3.5 Ethernet model. Specifically this 222 document adds management support for Service OAM. The Ethernet 223 Service OAM object definitions include common OAM objects (e.g., 224 EthMe, EthMeg, EthMep, etc.), Fault Management Objects (e.g., 225 Continuity Check, Loopback, etc.), Performance Monitoring Objects 226 (e.g., Loss Measurement, Delay Measurement, etc.). 228 3.3. IEEE CFM MIB 230 The IEEE8021-CFM-MIB MIB Module and IEEE8021-CFM-V2-MIB MIB module 231 are CFM MIB modules for managing IEEE CFM in [802.1Q]. The former 232 document defines all the MIB objects that used to read, create, 233 modify, and delete OAM related information (i.e., CFM Stack Table, MD 234 Table, MA Table, MEP Table, LinkTrace Reply Table, MEP DB Table, 235 Notifications Table, etc). The latter document defines CFM V2 module 236 for managing IEEE CFM. It contains objects that replace those 237 deprecated in the IEEE8021-CFM-MIB module (i.e., CFM Stack Table, CFM 238 Vlan Table, CFM Default MD Level Table, etc). 240 3.4. MEF SOAM FM and PM MIB 242 [MEF-31] defines the MIB modules for MEF Service OAM Fault Management 243 (FM). This document includes two MIBs necessary to support the MEF 244 SOAM FM functionality: the MEF-SOAM-TC-MIB that includes the Textual 245 Conventions (TC) for the SOAM MIB family and the MEF-SOAM-FM-MIB that 246 includes extensions to Connectivity Fault Management (CFM) as 247 developed in [IEEE 802.1Q], including MIBs found in [IEEE 802.1Q] and 248 [IEEE 802.1ap], and enhanced by ITU-T [Y.1731] to support the SOAM FM 249 functions as presented in the [MEF-30] specification. It includes 250 the SOAM FM MIB objects such as mefSoamNet, mefSoamMeg, mefSoamMep, 251 mefSoamCc, mefSoamAis, mefSoamLb, etc. 253 [MEF-36] specifies the Performance Monitoring (PM) MIB necessary to 254 manage SOAM implementations that satisfy the Service OAM requirements 255 and framework specified by [MEF-17], the Service OAM Performance 256 Monitoring requirements as specified by [MEF-35], and the Service OAM 257 management objects as specified by [MEF-7.1] which are applicable to 258 Performance Monitoring functions. Two non-MEF documents serve as the 259 baseline documents for this work: ITU-T [G.8013] and IEEE [802.1Q]. 260 The SOAM PM MIB is divided into a number of different object 261 groupings: the PM MIB MEP Objects, PM MIB Loss Measurement Objects, 262 PM MIB Delay Measurement Objects, and SOAM PM Notifications. 264 3.5. IETF Technology-specific MIB Series 266 IETF specifies a series MIB module for various technologies, which 267 includes: [RFC7331] for BFD MIB, [RFC4560] for PING MIB, [MPLS-TP OAM 268 ID MIB] for MPLS-TP MIB, etc. 270 All these documents are technology-specific and limited to L1, L2, 271 L3. The OAM MIB definition above L3 (i.e., SFC service layer) is 272 still missing in IETF. 274 3.6. IEEE CFM YANG 276 [P802.1Qcx] specifies Unified Modeling Language (UML)-based 277 information model and a YANG data model that allows configuration 278 and status reporting for bridges and bridge components for 279 Connectivity Fault Management (CFM) as specified in [802.1Q]. 281 3.7. MEF CFM and SOAM YANG Data Model 283 SOAM CFM YANG module [MEF-38] is an important work that defines the 284 managed objects necessary to support SOAM CFM functionality by using 285 the IETF YANG Module Language [RFC6020]. This YANG module contains 286 the management data definitions for the management of Ethernet 287 Services OAM for Connectivity Fault Management. 289 [MEF-39] provides the YANG module that supports the Ethernet Service 290 OAM (SOAM) Performance Monitoring functions. This YANG module 291 contains the management data definitions for the management of 292 Ethernet Services OAM for Performance Monitoring and extends the 293 Connectivity Fault Management (CFM) YANG modules. 295 [MEF-38] and [MEF-39] will be updated as [MEF-38.1] and [MEF-39.1]. 297 3.7. YANG Model for OAM Management and Technology-specific extensions 299 [I-D.ietf-lime-yang-oam-model] is an IETF work that creates a YANG 300 unified data models for connection oriented OAM protocols. It defines 301 a YANG [RFC6020] data model for Layer independent OAM Management 302 implementations that can be applied to various network technologies. 304 [I-D.ietf-trill-yang-oam] extends the Generic YANG model defined in 305 [I-D.ietf-lime-yang-oam-model] for OAM with TRILL technology. 307 [I-D.ietf-bfd-yang] defines YANG data model for BFD without 308 augmenting the Generic YANG model for connection-less OAM defined in 309 [I-D. ietf-lime-yang-connectionless]. 311 3.9. Discussion 313 Until now, all the OAM models and operations in the management plane 314 for L3-L7 are technology dependent and limited to one specific layer. 315 One point which should be noticed is that the information models 316 specified for transport networks (L0/L1/L2, [G.874.1], [G.8052], 317 [G.8152] ) by the ITU-T have received some degree of consolidation, 318 and are not technology dependent. [I-D. lam-lime-summary-l0-l2- 319 layer-independent] provides the summary on this point. 321 Also, [I-D.ietf-bfd-yang] indicates the concern how it can augment to 322 the Generic YANG model defined [I-D. ietf-lime-yang-connectionless]. 324 It is noted that the YANG Data model for OAM Performance Management 325 has not been developed and and some drafts for them are expired. 327 4. Security Considerations 329 TBD. 331 5. IANA Considerations 333 This drafts includes no request to IANA. 335 6. Acknowledgements 337 The authors would like to thank for Eve Varma, Maarten Vissers for 338 their valuable comments and thoughtful inputs to this draft regarding 339 ITU-T OAM works in L0-L2. 341 7. Normative References 343 [G.774] "Synchronous digital hierarchy (SDH) - Management 344 information model for the network element view", ITU-T 345 G.774, February 2001. 347 [G.783] "Characteristics of synchronous digital hierarchy (SDH) 348 equipment functional blocks", ITU-T G.783, March 2006. 350 [G.784] "Management aspects of synchronous digital hierarchy (SDH) 351 transport network elements", ITU-T G.784, March 2008. 353 [G.798] "Characteristics of optical transport network hierarchy 354 equipment functional blocks", ITU-T G.798, December 2012. 356 [G.800] "Unified functional architecture of transport networks", 357 ITU-T G.800, February 2012. 359 [G.8010] "Architecture of Ethernet layer networks", ITU-T G.8010, 360 February 2004. 362 [G.8013] "OAM functions and mechanisms for Ethernet based 363 networks", ITU-T G.8013/Y.1731, August 2015. 365 [G.8021] "Characteristics of Ethernet transport network equipment 366 functional blocks", ITU-T G.8021, January 2015. 368 [G.803] "Architecture of transport networks based on the 369 synchronous digital hierarchy (SDH)", ITU-T G.803, March 370 2000. 372 [G.805] "Generic functional architecture of transport networks", 373 ITU-T G.805, March 2000. 375 [G.8051] "Management aspects of the Ethernet Transport (ET) capable 376 network element", ITU-T G.8051, August 2015. 378 [G.8052] "Protocol-neutral management information model for the 379 Ethernet transport capable network element", ITU-T 380 G.8052/Y.1346, November 2015. 382 [G.806] "Characteristics of transport equipment - Description 383 methodology and generic functionality", ITU-T G.806, 384 February 2012. 386 [G.8110.1] 387 "Architecture of MPLS Transport Profile (MPLS-TP) layer 388 network", ITU-T G.8110.1/Y.1370.1, December 2011. 390 [G.8121] "Characteristics of MPLS-TP equipment functional blocks", 391 ITU-T G.8121, April 2016. 393 [G.8151] "Management aspects of the MPLS-TP network element", ITU-T 394 G.8151, January 2015. 396 [G.8152] "Protocol-neutral management information model for the 397 MPLS-TP network element", ITU-T G.8152/Y.1375, 398 December 2016. 400 [G.7710] "Common equipment management function requirements", 401 ITU-T G.7710, February 2012. 403 [G.7711] "Generic protocol-neutral information model for transport 404 resources", ITU-T G.7711, August 2015. 406 [G.872] "Architecture of optical transport networks", ITU-T G.872, 407 October 2012. 409 [G.874] "Management aspects of optical transport network 410 elements", ITU-T G.874, August 2013. 412 [G.874.1] "Optical transport network: Protocol-neutral management 413 information model for the network element view", ITU-T 414 G.874.1, October 2012. 416 [I-D.edprop-opsawg-multi-layer-oam-ps] 417 Taylor, T., "Problem Statement for Layer and Technology 418 Independent OAM in a Multi-Layer Environment", ID draft- 419 edprop-opsawg-multi-layer-oam-ps(Expired), September 2014. 421 [I-D.ietf-lime-yang-oam-model] 422 Kumar, D., Wu, Q., and Wang, M. "Generic YANG Data Model 423 for Connection Oriented Operations, Administration, and 424 Maintenance (OAM)", draft-ietf-lime-yang-connection- 425 oriented-oam-model-07, July 2016. 427 [I-D.ietf-bfd-yang] 428 Zheng, L., " Yang Data Model for Bidirectional Forwarding 429 Detection(BFD) ", ID draft-ietf-bfd-yang-06, June 2017. 431 [I-D.ietf-trill-yang-oam] 432 Kumar, D., "YANG Data Model for TRILL Operations, 433 Administration, and Maintenance (OAM)", draft-ietf-trill- 434 yang-oam-04, July 2016. 436 [I-D. lam-lime-summary-l0-l2-layer-independent] 437 K. Lam., "Existing Support for Network Operations in 438 Multilayer Transport Network based upon unified approach 439 to OAM (Layer 0 - Layer 2)", ID draft-lam-lime-summary-l0 440 l2-layer-independent-05(Expired), October 2016. 442 [I-D. ietf-lime-yang-connectionless] 443 Kumar, D., "Generic YANG Data Model for Connection Less, 444 Operations, Administration, and Maintenance (OAM) 445 protocols", draft-ietf-lime-yang-connectionless-oam-07, 446 June 2017 448 [802.1Q] "Media Access Control (MAC) Bridges and Virtual Bridged 449 Local Area Networks", IEEE Std 802.1Q-2014, November 2014. 451 [P802.1Qcx] 452 "Standard for Local and metropolitan area networks 453 --Bridges and Bridged Networks Amendment: YANG Data 454 Model for Connectivity Fault Management", (in progress). 456 [MEF-17] "Service OAM Requirements & Framework - Phase 1", MEF 17, 457 April 2007. 459 [MEF-30] "Service OAM Fault Management Implementation Agreement", 460 MEF 30, January 2011. 462 [MEF-31] "Service OAM Fault Management Definition of Managed 463 Objects", MEF 31, January 2011. 465 [MEF-35] "Service OAM Performance Monitoring Implementation 466 Agreement", MEF 35, January 2012. 468 [MEF-36] "Service OAM SNMP MIB for Performance Monitoring", MEF 36, 469 January 2012. 471 [MEF-38] "Service OAM Fault Management YANG Modules", MEF 38, April 472 2012. 474 [MEF-39] "Service OAM Performance Monitoring YANG Module", MEF 39, 475 April 2012. 477 [MEF-7.1] "EMS-NMS Information Model - Phase 2", MEF Fourm 478 MEF 7.1, 2009. 480 [Q.840.1] "Requirements and Analysis for NMS-EMS Management 481 Interface of Ethernet over Transport and Metro Ethernet 482 Network", Draft Recommendation ITU-T Q.840.1, 2007. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", March 1997. 487 [RFC4560] Quittek, J., "Definitions of Managed Objects for Remote 488 Ping, Traceroute, and Lookup Operations", June 2006. 490 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 491 Network Configuration Protocol (NETCONF)", RFC 6020, 492 October 2010. 494 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 495 D., and S. Mansfield, "Guidelines for the use of the "OAM" 496 Acronym in the IETF", RFC 6291, June 2011. 498 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 499 Maintenance Framework for MPLS-Based Transport Networks", 500 RFC 6371, September 2011. 502 [RFC7331] Nadeau, T., Ali, Z., and N. Akiya, "Bidirectional 503 Forwarding Detection (BFD) Management Information Base", 504 RFC 7331, August 2014. 506 Authors' Addresses 508 Yuji Tochio 509 Fujitsu 511 Email: tochio@jp.fujitsu.com 513 Huub van Helvoort 514 Hai Gaoming BV 515 The Netherlands 517 Email: huubatwork@gmail.com 519 Liang (Frank) Xia 520 Huawei 521 101 Software Avenue, Yuhua District 522 Nanjing, Jiangsu 210012 523 China 525 Email: Frank.xialiang@huawei.com