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