idnits 2.17.00 (12 Aug 2021) /tmp/idnits41835/draft-edprop-opsawg-multi-layer-oam-ps-02.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 date (September 26, 2014) is 2787 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations and Management Area Working Group Q. Wu 3 Internet-Draft M. Wexler 4 Intended status: Informational Huawei 5 Expires: March 30, 2015 D. Romascanu 6 AVAYA 7 T. Taylor, Ed. 8 PT Taylor Consulting 9 September 26, 2014 11 Problem Statement for Layer and Technology Independent OAM in a Multi- 12 Layer Environment 13 draft-edprop-opsawg-multi-layer-oam-ps-02.txt 15 Abstract 17 Operations, Administration, and Maintenance (OAM) mechanisms are 18 critical building blocks in network operations. They used for 19 service fulfillment assurance, and for service diagnosis, 20 troubleshooting, and repair. The current practice is that many 21 technologies rely on their own OAM protocols and procedures that are 22 exclusive to a given layer. 24 At present, there is little consolidation of OAM in the management 25 plane or well-documented inter-layer OAM operation. Vendors and 26 operators dedicate significant resources and effort through the whole 27 OAM life-cycle each time a new technology is introduced. This is 28 exacerbated when dealing with integration of OAM into overlay 29 networks, which require better OAM visibility since there is no 30 method to exchange OAM information between overlay and underlay. 32 This document analyzes the problem space for multi-layer OAM in the 33 management plane with a focus on layer and technology independent OAM 34 management considerations. It concludes that an attempt to define an 35 architecture for consolidated management should be undertaken, and if 36 this attempt satisfies key objectives, a gap analysis and a program 37 of standardization should follow. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on March 30, 2015. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. A Vision of Layer and Technology Independent Management . 4 75 1.2. Looking Forward . . . . . . . . . . . . . . . . . . . . . 5 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. A Preliminary Set Of Objectives . . . . . . . . . . . . . . . 7 78 4. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 8 79 4.1. Argument For Consolidated Management . . . . . . . . . . 8 80 4.2. Argument For Layer and Technology Independent Management 9 81 4.3. Detailed Issues . . . . . . . . . . . . . . . . . . . . . 10 82 4.3.1. Strong Technology Dependency For MIB Modules . . . . 10 83 4.3.2. Issues of Abstraction . . . . . . . . . . . . . . . . 10 84 4.3.3. OAM Interworking Issues . . . . . . . . . . . . . . . 10 85 4.3.4. Multiple (ECMP) Paths OAM Issue . . . . . . . . . . . 11 86 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 11 87 6. Considerations For the Work On Architecture . . . . . . . . . 12 88 6.1. What the Architecture Must Define . . . . . . . . . . . . 12 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 11.2. Informative References . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction 100 Operations, Administration, and Maintenance (OAM, [RFC6291]) 101 mechanisms are critical tools, used for service assurance, 102 fulfillment, or service diagnosis, troubleshooting, and repair, as 103 well as supporting functions such as accounting and security 104 management. The key foundations of OAM and its functional roles in 105 monitoring and diagnosing the behavior of networks have been studied 106 at OSI layers 1, 2 and 3 for many years. 108 When operating networks with more than one technology in an overlay 109 network, maintenance and troubleshooting are achieved per technology 110 and per layer. As a result, operational processes can be very 111 cumbersome. Stitching together the OAM of adjacent transport 112 segments (as defined in Section 2 in one administrative domain is 113 often not defined and left to proprietary solutions. 115 Current practice, which consists in enabling specific OAM techniques 116 for each layer, has shown its limits. Concretely, we see today a 117 large number of layer 1/2/3 OAM protocols being well developed and 118 some of them being successfully deployed, but how these OAM protocols 119 in each layer can be applied to overlay networks that are using 120 different encapsulation protocols so as to provide better OAM 121 visibility is still a challenging issue. When no mechanism is 122 defined to exchange performance and liveliness information between 123 the underlay and overlay(s) by a coordination system, it is hard, for 124 instance, to determine whether a fault originates in higher or lower 125 layer. 127 Section 1.1 of [RFC7276] makes the point that each layer in a multi- 128 layer architecture has its own OAM protocols. From this follows the 129 basic principle that OAM in the data plane cannot cross layer 130 boundaries. A similar constraint holds for boundaries between 131 different transport technologies in the same layer, barring the 132 stitching mentioned above. 134 One concludes that to simplify OAM and make it more responsive in a 135 multi-layer network requires further consolidation in the management 136 plane. The work on management consolidation would benefit from at 137 least some new standardization. A detailed examination of the 138 potential scope of the work is left for a gap analysis following 139 successful definition of an architecture. 141 This document further argues that in addition to the ability to 142 retrieve technology specific information from managed entities when 143 following up on problems, consolidated management requires a 144 technology independent view of the network and supporting layers. 146 How this view is obtained is a key architectural issue outside the 147 scope of the present document. 149 1.1. A Vision of Layer and Technology Independent Management 151 What follows is based on the assumption of a network supported by a 152 strict hierarchy of underlying layers in the data plane. There may 153 be multiple layers at a given level of the OSI layer 1-2-3 hierarchy, 154 but that is irrelevant to the vision. 156 A management application presents to an user a view of this network 157 and its supporting layers that is strictly topological, free of any 158 technology specific information. The user notes a defect along a 159 path serving a particular customer. Looking at the next lower path, 160 the user also sees a defect. Looking the next lower path again, 161 there is also a defect. No lower defect is noted. 163 At this point it is appropriate to indicate what the user can see 164 along a given path. The path is divided into one or more segments, 165 each spanned by a specific transport technology. However, as already 166 stated, the user does not see any technology specific information. 167 Instead, as well as distinguishing the segments, the user can 168 identify the managed elements at the beginning and end of each 169 segment. 171 To clarify the situation, the user issues an abstract Continuity 172 Check command, directed toward the initial managed element of the 173 segment in which a fault appears to lie (i.e., in the lowest layer 174 where a defect was observed). By means to be determined by 175 architectural choice, this command is converted into a technology- 176 specific request which is executed across the selected segment. 177 Possible outcomes include: 179 1. The fault could come clear as a result of the test. The 180 immediate problem is solved (and may have affected multiple upper 181 paths besides the one of initial interest) and the point at which 182 it occurred could be flagged for follow-up maintenance. 184 2. Local craft action to clear the fault is available in timely 185 fashion. 187 3. Timely local craft action is not possible, and capacity is 188 reallocated on other paths to ensure that service levels are 189 maintained. Note that capacity reallocation can be done based on 190 the topological view of the network, still on a layer and 191 technology independent basis. 193 In case (2), technology specific management capabilities are likely 194 to be required by the craftperson following up on the problem. 196 1.2. Looking Forward 198 The remainder of this document develops the ideas just stated at a 199 greater level of detail. Section 2 provides terminology that is 200 important to the understanding of the rest of the document. 201 Section 3 establishes preliminary objectives that are key to 202 determining whether a complete program of standardization of 203 consolidated management should be undertaken. Section 4 provides the 204 problem analysis. It is divided into three parts: an argument for 205 consolidated management (Section 4.1), an argument for layer and 206 technology independent management (Section 4.2), and an examination 207 of some more detailed issues. Section 5 provides the problem 208 statement, and Section 6 provides some considerations that should be 209 taken into account in the proposed work on architecture. 211 2. Terminology 213 [RFC6291], cited above, provides the official IETF description of 214 Operations, Administration, and Maintenance (OAM) terminology. For a 215 more extensive description of OAM and related terms, see the opening 216 sections, but particularly Sections 2.2.1 through 2.2.3, of 217 [RFC7276]. 219 Section 2.2.4 of [RFC7276] introduces the terms data plane, control 220 plane, and management plane. 222 This document introduces its own interpretation of the following 223 terms, which are in wide use but in that general usage present 224 ambiguities: 226 Management: 228 A definition of management can be inferred from [RFC6123], which 229 in turn refers to [RFC5706]. Unfortunately the latter chose to 230 divide operations from management, at least from a documentation 231 point of view. The present document chooses to define management 232 as a function that is concerned with all three of operations, 233 administration, and maintenance. 235 Layer: 237 The word "layer" has two potential meanings. In the first 238 instance, it is a topological concept, representing a position in 239 a hierarchy of layers. In the second instance, it refers to OSI 240 layers 1, 2 and 3. Within this document, "layer independent OAM 241 management" as defined below emphasizes the latter meaning when 242 talking about independence, but is intended to extend to all 243 layers of the hierarchy supporting a given network or overlay (the 244 topological view of "layer"). 246 This document makes use of the following additional terms: 248 Layer independent OAM management: 250 In a multi-layer network, layer independent OAM management refers 251 to OAM in the management plane that can be deployed independently 252 of media, data protocols, and routing protocols. It denotes the 253 ability to gather OAM information at the different layers, 254 correlate it with layer-specific identifiers and expose it to the 255 management application through a unified interface. 257 Managed entity: 259 An architectural concept, an instance of what the management 260 function manages. By definition, a managed entity is capable of 261 communicating with the management function in the management 262 plane. 264 Local Management Entity (LMgmtE): 266 An instance of a management function that is restricted in scope 267 to communication with the managed entities associated with a 268 specific transport segment in a specific layer. This term 269 includes legacy management entities in an existing network, and 270 may include entities of a similar scope if they are defined in a 271 consolidated management architecture. 273 Consolidated Management Entity (CMgmtE): 275 An instance of the management function that is capable of 276 communicating with all of the LMgmtEs and/or managed entities in a 277 scoped part of the network in order to achieve end-to-end and 278 service-level views of network performance and status and initiate 279 actions when required. The phrase "LMgmtEs and/or managed 280 entities" allows for the possibility that the target architecture 281 allows for direct communication between the CMgmtE and the managed 282 entities or alternatively chooses to assume a distributed 283 management architecture. In any case, as discussed in Section 6, 284 the CMgmtE will have to communicate with legacy LMgmtEs during the 285 transition from the existing to the target architecture. 287 Management subsystem: 289 The implementation of the management function in a given network. 291 Managed device: 293 A network element associated with at least one technology layer 294 and one managed entity. 296 Transport segment: 298 Refers to the portion of a path at a given layer bounded by two 299 points between which a specific transport technology is used and 300 beyond which either a different technology is used or the path is 301 terminated. 303 Three-dimensional topology: 305 Refers to a three-dimensional view of the topology of the network 306 and supporting layers. The view of paths along a layer comprises 307 two dimensions. The third dimension is provided by the ordered 308 hierarchy of layers from bottom to top at any point along a path. 309 The three-dimensional topology includes per-path capacity and flow 310 information, permitting layer and technology independent 311 reallocation of capacity as required. 313 3. A Preliminary Set Of Objectives 315 Before going further, it is possible to state a preliminary set of 316 objectives for this work. If it does not appear that these can be 317 satisfied, there is no point in undertaking further effort. 319 As a first objective, the outcome of the work must reduce the time 320 required to respond to and mitigate service-affecting events. The 321 ideal result is that the system be able to do so before the customer 322 notices a service degradation. It is possible that satisfaction of 323 this objective alone is sufficient to carry on. 325 A second objective relates to the business case for the work and is 326 more difficult for the IETF to judge but crucial for operators 327 attempting to justify changes in their network infrastructure. It 328 should be possible to expect a reduction in life cycle capex and opex 329 as a result of making those changes, even taking account of the 330 potential costs of abandoning or upgrading existing equipment. This 331 objective may influence work on architecture for consolidated 332 management toward minimizing those latter costs (capex). On the 333 positive side, likely savings in craftsperson time implied by the 334 first objective are helpful to the business case (opex). 336 At a more detailed level, the outcome of the work must allow 337 management to have end-to-end and service-level views of network 338 performance, down to the granularity of service instance. Pre- 339 supposing the arguments made in Section 4.2, it must also allow 340 management to have a layer and technology independent view of the 341 network, at least in the form of the three-dimensional topology, as 342 defined in Section 2. 344 4. Analysis of the Problem 346 4.1. Argument For Consolidated Management 348 Multi-layer OAM actually presents two separate but inter-related 349 issues. The first is technology dependency, at the same or different 350 layers. The second is correlation of events between layers. 352 OAM mechanisms have a strong technology dependency because each 353 technology (or layer) has its best suited OAM tools. Some of them 354 provide rich functionality with one protocol, while the others 355 provide each function with a different protocol. Today a variety of 356 OAM tools have been developed by different Standards Development 357 Organizations (SDOs) for Optical Transport Network (OTN), Synchronous 358 Digital Hierarchy (SDH), Ethernet, MPLS, and IP networks. 360 However, orchestrating and coordinating OAM in multi-layer networks 361 to provide better network visibility and efficient OAM operations is 362 still a challenging issue since no mechanisms are defined, for 363 example, to exchange performance and liveliness information between 364 different layers. This means that the required coordination has to 365 happen in the management function through communication with the 366 managed entities. 368 The development of overlay networks, where one network is the client 369 of another, adds to the magnitude of the problem. To take a specific 370 example, in the Service Function Chaining (SFC) 371 [I.D-ietf-sfc-problem-statement] environment, every Service Function 372 (SF) may operate at a different layer and may use a different 373 encapsulation scheme. When taking into account overlay technologies, 374 the number of encapsulation options increases even more. 376 At this point, it is useful to recall the preliminary objectives 377 stated in Section 3. To achieve end-to-end and service-level views 378 of network performance requires that the management function be 379 capable of receiving and reacting to related information from every 380 transport segment at every layer in the network. This is a working 381 definition of consolidated management. 383 A key issue with "management consolidation" is that it may include a 384 requirement for management to interact with every technology used in 385 the network on a per-technology basis either initially or when it has 386 to follow up on detected problems by collecting detailed information. 387 It is an architectural challenge beyond the scope of this document to 388 determine whether consolidated management then becomes an aggregation 389 of local managers of legacy type tied together by a coordination 390 function, or whether simplifications are possible. 392 4.2. Argument For Layer and Technology Independent Management 394 The argument for consolidated management to have a layer and 395 technology independent view of the network and supporting layers is 396 two-pronged. The first argument is fairly straightforward and 397 initially independent of architectural considerations. Some 398 management functions are concerned solely with the topology of the 399 network and supporting layers as represented by the three-dimensional 400 topology defined in Section 2. These include network optimization, 401 efficient enforcement of Traffic Engineering (TE) techniques 402 including assurance of path diversity in one layer and over the 403 complete hierarchy of layers, and fine-grained tweaking. Even in 404 this case management action may require interaction with the managed 405 elements at a technology-specific level, barring an alternative 406 architectural solution. 408 The second argument for a layer and technology independent view 409 involves considerably more substance than the first one. The three- 410 dimensional topology would be a starting point for this view, but in 411 addition it would include an abstracted view of service-affecting or 412 potentially service-affecting events, identified by layer and 413 reporting managed device. This allows management to correlate events 414 in different layers and identify the devices from which it must seek 415 further information or to which it must direct other requests, 416 without being burdened with excess information. The intention is to 417 ease root cause analysis and improve the ability to maintain end-to- 418 end and service-level visibility. 420 Where this second version of a technology independent view is created 421 is an architectural issue, beyond the scope of the present document. 422 One possibility is that the work is all done in the "consolidated 423 management" function, in which case the latter just becomes an 424 aggregation of legacy technology-specific managers tied together by a 425 coordination function, as mentioned above. A contrasting possibility 426 is that the managed devices also support the abstraction, with a view 427 to minimizing the amount of technology specific information and 428 management actions the management function has to support. 430 4.3. Detailed Issues 432 4.3.1. Strong Technology Dependency For MIB Modules 434 OAM protocols rely heavily on the specific network technology they 435 are associated with. For example, ICMPv6 [RFC4443] and LSP Ping 436 [RFC4379] provide the same OAM functionality, path discovery, for 437 IPv6 and MPLS Label Switched Path (LSP) technologies respectively. 439 SNMP MIB modules to manage these protocols were developed on a per 440 OAM protocol basis. As a result, there was little reuse of MIB 441 modules for other existing OAM protocols. To the extent that 442 management operations are being redesigned in terms of YANG modules 443 [RFC6020] over NETCONF [RFC6241], the opportunity exists to use the 444 concept of layer and technology independent abstraction to extract 445 the reusable parts, simplifying the work on the remainder. 447 4.3.2. Issues of Abstraction 449 In a multi-layer network, OAM functions are enabled at different 450 layers and OAM information needs to be gathered from various layers 451 independently. Without multi-layer OAM in place, it is hard for 452 management applications to understand what information (e.g., 453 Context, OAM functionalities) at different layers stands for and have 454 a unified view of OAM information at different layers. A mechanism 455 is required to provide this information to management. 457 The challenge is to abstract in a way that retains in the management 458 plane as much useful information as possible while filtering the data 459 that is not needed. An important part of this effort is a clear 460 understanding of what information is actually needed. There is a 461 close relationship between this issue and the issue already 462 identified in the previous section. 464 4.3.3. OAM Interworking Issues 466 When multiple layer OAMs are used in the different parts of the 467 network, two layer OAMs interworking at the boundaries need to be 468 considered: 470 o How one layer OAM in given part of the network interworks with 471 another layer OAM in another part of the network operated by the 472 same administrative entity through a consolidated management 473 interface? e.g., E-LMI used in UNI interworks with Ethernet link 474 OAM used on an IEEE 802.3 link in the same domain? 476 o How one layer OAM interworks with another layer OAM in the same 477 part of the network through a conssolidated management interface? 478 e.g., Ethernet OAM interworks with MPLS OAM in the same part of 479 the network? In this case, Ethernet OAM and MPLS OAM are both 480 supported by the same two managed devices in communication. 482 In these cases, mapping and notifications of defect states between 483 different layer OAMs is required at the boundary nodes of the two 484 parts of the network [RFC6310] [RFC7023] 485 [I-D.ietf-l2vpn-vpws-iw-oam]. Management must provide the 486 interworking function to establish dynamic mapping and translation, 487 supervise defects, and suppress alarms. [Issue for debate. The 488 original text from draft-ww-oamwg provides for a separate 489 interworking function. To me, that violates the concept of 490 consolidated management. Maybe this is a case of local versus 491 consolidated management as discussed in Section 6 -- PTT as 492 individual contributor] 494 4.3.4. Multiple (ECMP) Paths OAM Issue 496 Network devices typically use fields in the MAC or IP header or MPLS 497 header and perform hash computations (e.g., 5-tuple hash consisting 498 of IP protocol, source address, destination address, source port, and 499 destination port) on these packet header fields to classify packets 500 into flows and select the forwarding path for the flow among multiple 501 equal cost paths, ECMP becomes more important when network overlay, 502 service chain technology are introduced, e.g., in case of multi- 503 instances of the same service function is invoked for a given chain 504 to provide redundancy, how 5-tuple hash is used based on contents in 505 the outer headers and inner encapsulated packet. 507 Multiple path OAM requires that Connectivity Check and Continuity 508 Check must follow the same path as the data traffic (e.g., TCP 509 traffic and UDP traffic). Overlay encapsulation allows OAM data to 510 piggyback packets, in the way record route is used in IPv4 options. 511 However, there is no standard way to exercise end to end continuity 512 and connectivity verification that covers all of ECMP paths in the IP 513 networks. Such a standard is desirable. 515 5. Problem Statement 517 OAM functions are used heavily during service and network life-cycle. 518 Today, OAM management requires expertise due to technology dependency 519 despite the similarity in functions (adding to CAPEX and OPEX). 520 Troubleshooting is cumbersome due to protocol variety and lack of 521 multi- layer OAM. This requires expertise and long troubleshooting 522 cycles (OPEX). Last but not least, today's various management 523 interfaces make it difficult to accept and introduce new protocols 524 and technologies 525 There is value in attempting to define an architecture for 526 consolidated management that may reasonably be argued to meet the 527 objectives stated in Section 3. If this attempt succeeds, it can be 528 followed up with a gap analysis, which in turn will define a further 529 program of standardization. 531 At the detailed level, Section 4.3.1 and Section 4.3.2 deal with the 532 matter of abstraction and its relationship to the specification of 533 YANG modules. This is work beyond the initial definition of 534 architecture and awaits justification and prioritization by the gap 535 analysis. A similar consideration relates to the solution to the 536 ECMP problem. 538 The remaining issue is the OAM interworking issue identified in 539 Section 4.3.3. This is architectural in nature, and should be 540 addressed by the proposed work on architecture. 542 6. Considerations For the Work On Architecture 544 Definition of an architecture for consolidated management is beyond 545 the scope of the present document. This section instead provides 546 considerations that should be taken into account when defining such 547 an architecture. 549 6.1. What the Architecture Must Define 551 This section is a discussion in the nature of a very general use case 552 rather than a discussion of functions and entities. However, as a 553 preliminary remark, the architecture must be thought through for all 554 five of the FCAPS areas (fault, configuration, accounting, 555 performance, and security management). RFC 5706 Section 3, while 556 nominally directed to protocol design, reviews operational issues 557 associated with each of these areas. 559 To begin with, previous analysis (Section 4.2) has indicated that the 560 CMgmtE Section 2 needs to work with a view of network topology that 561 is layer and technology independent in order to achieve the 562 objectives stated in Section 3. Two questions immediately come to 563 mind: where is this view prepared, taking account of the limited 564 processing power of network devices in particular, and what model is 565 used to present the topology to the CMgmtE? Of course, these 566 questions are evaded if the architecture makes the CMgmtE responsible 567 for creating the abstracted topology from data gathered from the 568 LMgmtEs and/or managed entities Section 2 within its scope. 570 Note that from the end-to-end point of view multiple network 571 topologies will typically exist in the network at one time, possibly 572 down to the granularity of a service instance. The relationship of 573 the scope of a CMgmtE to the set of available topologies is subject 574 to the condition that it has end-to-end and service-level views of 575 all paths between the endpoints within its scope, and is otherwise 576 undefined. 578 The CMgmtE must be aware of all of the LMgmtEs and/or managed 579 entities within its scope. The architecture must define how the 580 CMgmtE identifies the correct sequence of these entities along a path 581 in a given layer, and similarly, must identify the correct ordering 582 of layers from bottom to top. In effect, the CMgmtE requires a 583 three-dimensional topological view of the data plane maintenance 584 infrastructure. Entity identification may be implicit in this work. 585 Note that management actions may alter this topology (e.g., for 586 routine maintenance or installation of new equipment). 588 The next issue is how the CMgmtE and the other entities discover each 589 other. Bound up in this is the issue of trust. This bootstrapping 590 problem is a hard one, constantly recurring in IETF work but never 591 yet solved. The architecture work will have to come to its own 592 conclusions on this topic. 594 Where correlation of events from different layers and transport 595 segments is done is not an issue. By definition it can be done only 596 by the CMgmtE. The architecture must decide whether the necessary 597 data gathering is done as required or continuously. 599 As a final point, the architecture must specify how an existing 600 network evolves from legacy operation to the target architecture. 601 The existing network will have LMgmtEs in place. The question is 602 whether the CMgmtE simply replaces them or communicates with them. 603 If it simply replaces them, the architecture must define (in an 604 operational considerations section) how testing of the new management 605 configuration takes place before cutover. Considerations of data 606 continuity during cutover should also be addressed. 608 The above is not an exhaustive list of considerations, but should 609 give a good start to the architectural work. 611 7. Security Considerations 613 The architectural work must include work on the security architecture 614 of the whole system. Beyond that, potential future work on 615 individual interfaces must include the appropriate security 616 mechanisms within the architectural framework. The present document 617 cannot be more specific by its nature. 619 8. IANA Considerations 621 This document does not require any action from IANA. 623 9. Contributors 625 In the understanding of the Editor, the following individuals (listed 626 in alphabetical order by last name) contributed text to or strongly 627 influenced the development of versions of draft-ww-opsawg-multi- 628 layer-oam, from which this document was derived: 630 o Sam Aldrin mailto:aldrin.ietf@gmail.com, Huawei USA; 632 o Mohamed Boucadair mailto:mohamed.boucadair@orange.com, France 633 Telecom; 635 o Huub van Helvoort mailto:huubatwork@gmail.com, Hai Gaoming BV; 637 o Tom Herbert mailto:therbert@google.com, Google; 639 o Pradeep Jain mailto:pradeep@nuagenetworks.net, Nuage Networks; 641 o Daniel King mailto:daniel@olddog.co.uk, Olddog Consulting; 643 o Greg Mirsky mailto:gregory.mirsky@ericsson.com, Ericsson; 645 o Ravi Shekhar mailto:rshekhar@juniper.net, Juniper. 647 10. Acknowledgements 649 The authors would like to thank Jan Lindblad, Tissa Senevirathne, 650 Yuji Tochio, Ignas Bagdonas, Eric Osborne, Rob Shakir, Georgis 651 Karagiannis, Melinda Shore and Jouni Korhonen for their reviews and 652 suggestions. 654 11. References 656 11.1. Normative References 658 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 659 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 660 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 662 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 663 Weingarten, "An Overview of Operations, Administration, 664 and Maintenance (OAM) Tools", RFC 7276, June 2014. 666 11.2. Informative References 668 [I-D.ietf-l2vpn-vpws-iw-oam] 669 Aissaoui, M., Busschbach, P., Allan, D., Morrow, M., and 670 T. Nadeau, "OAM Procedures for VPWS Interworking", draft- 671 ietf-l2vpn-vpws-iw-oam-04 (work in progress), March 2014. 673 [I.D-ietf-sfc-problem-statement] 674 Quinn, P., Guichard, J., and S. Surendra, "Network Service 675 Chaining Problem Statement (Work in progress)", ID draft- 676 ietf-sfc-problem-statement, August 2014. 678 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 679 Label Switched (MPLS) Data Plane Failures", RFC 4379, 680 February 2006. 682 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 683 Message Protocol (ICMPv6) for the Internet Protocol 684 Version 6 (IPv6) Specification", RFC 4443, March 2006. 686 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 687 Management of New Protocols and Protocol Extensions", RFC 688 5706, November 2009. 690 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 691 Network Configuration Protocol (NETCONF)", RFC 6020, 692 October 2010. 694 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 695 Computation Element (PCE) Working Group Drafts", RFC 6123, 696 February 2011. 698 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 699 Bierman, "Network Configuration Protocol (NETCONF)", RFC 700 6241, June 2011. 702 [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., 703 Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, 704 Administration, and Maintenance (OAM) Message Mapping", 705 RFC 6310, July 2011. 707 [RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P., 708 and R. Qiu, "MPLS and Ethernet Operations, Administration, 709 and Maintenance (OAM) Interworking", RFC 7023, October 710 2013. 712 Authors' Addresses 714 Qin Wu 715 Huawei 716 101 Software Avenue, Yuhua District 717 Nanjing, Jiangsu 210012 718 China 720 Email: bill.wu@huawei.com 722 Mishael Wexler 723 Huawei 724 Riesstr. 25 725 Munich 80992 726 Germany 728 Email: mishael.wexler@huawei.com 730 Dan Romascanu 731 AVAYA 732 Park Atidim, Bldg. #3 733 Tel Aviv 61581 734 Israel 736 Email: dromasca@avaya.com 738 T. Taylor (editor) 739 PT Taylor Consulting 740 Ottawa 741 Canada 743 Email: tom.taylor.stds@gmail.com