idnits 2.17.1 draft-ietf-lime-yang-connection-oriented-oam-model-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-netmod-revised-datastores]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 362 has weird spacing: '...-string md-...' == Line 571 has weird spacing: '...-string md-...' == Line 579 has weird spacing: '...-string ma-...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 6, 2018) is 2271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-07 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kumar 3 Internet-Draft Cisco 4 Intended status: Standards Track Q. Wu 5 Expires: August 10, 2018 M. Wang 6 Huawei 7 February 6, 2018 9 Generic YANG Data Model for Connection Oriented Operations, 10 Administration, and Maintenance(OAM) protocols 11 draft-ietf-lime-yang-connection-oriented-oam-model-05 13 Abstract 15 This document presents a base YANG Data model for connection oriented 16 OAM protocols. It provides a technology-independent abstraction of 17 key OAM constructs for such protocols. The model presented here can 18 be extended to include technology specific details. This guarantees 19 uniformity in the management of OAM protocols and provides support 20 for nested OAM workflows (i.e., performing OAM functions at different 21 levels through a unified interface). 23 The YANG model in this document conforms to the Network Management 24 Datastore Architecture defined in 25 [I-D.ietf-netmod-revised-datastores]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 10, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 4 63 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Architecture of Generic YANG Model for OAM . . . . . . . . . 6 67 4. Overview of the OAM Model . . . . . . . . . . . . . . . . . . 7 68 4.1. Maintenance Domain (MD) configuration . . . . . . . . . . 8 69 4.2. Maintenance Association (MA) configuration . . . . . . . 9 70 4.3. Maintenance Endpoint (MEP) configuration . . . . . . . . 9 71 4.4. RPC definitions . . . . . . . . . . . . . . . . . . . . . 10 72 4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 13 73 4.6. Monitor statistics . . . . . . . . . . . . . . . . . . . 13 74 4.7. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 13 75 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 76 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 40 77 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 40 78 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 40 79 6.3. Maintenance Association . . . . . . . . . . . . . . . . . 41 80 7. Connection-oriented OAM YANG model applicability . . . . . . 41 81 7.1. Generic YANG Model extension for TRILL OAM . . . . . . . 41 82 7.1.1. MD Configuration Extension . . . . . . . . . . . . . 42 83 7.1.2. MA Configuration Extension . . . . . . . . . . . . . 42 84 7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 43 85 7.1.4. RPC extension . . . . . . . . . . . . . . . . . . . . 43 86 7.2. Generic YANG Model extension for MPLS-TP OAM . . . . . . 44 87 7.2.1. MD Configuration Extension . . . . . . . . . . . . . 44 88 7.2.2. MA Configuration Extension . . . . . . . . . . . . . 46 89 7.2.3. MEP Configuration Extension . . . . . . . . . . . . . 46 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 95 11.2. Informative References . . . . . . . . . . . . . . . . . 49 96 Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 51 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 99 1. Introduction 101 Operations, Administration, and Maintenance (OAM) are important 102 networking functions that allow operators to: 104 1. Monitor networks connections (Connectivity Verification, 105 Continuity Check). 107 2. Troubleshoot failures (Fault verification and localization). 109 3. Monitor Performance 111 An overview of OAM tools is presented in [RFC7276]. Over the years, 112 many technologies have developed similar tools for fault and 113 performance management. 115 The different sets of OAM tools may support both connection-oriented 116 technologies or connectionless technologies. In connection-oriented 117 technologies, a connection is established prior to the transmission 118 of data. After the connection is established, no additional control 119 information such as signaling or operations and maintenance 120 information is required to transmit the actual user data. In 121 connectionless technologies, data is typically sent between 122 communicating end points without prior arrangement, but control 123 information is required to identify the destination (e.g., [G.800] 124 and [RFC7276]). The YANG Data model for OAM protocols using 125 connectionless communications is specified in 126 [I-D.ietf-lime-yang-connectionless-oam]. 128 [IEEE802.1ag] Connectivity Fault Management is a well-established OAM 129 standard that is widely adopted for Ethernet networks. ITU-T 130 [G.8013], MEF Service OAM, MPLS-TP [RFC6371], TRILL [RFC7455] all 131 define OAM mechanisms based on the manageability frame work of CFM 132 [IEEE802.1ag]. 134 Given the wide adoption of the underlying OAM concepts defined in CFM 135 [IEEE802.1ag], it is a reasonable choice to develop the unified 136 management framework for connection oriented OAM based on those 137 concepts. In this document, we take the CFM [IEEE802.1ag] model and 138 extend it to a technology independent framework and define the 139 corresponding YANG model accordingly. The YANG model presented in 140 this document is the base model for connection oriented OAM protocols 141 and supports generic continuity check, connectivity verification and 142 path discovery (traceroute). The generic YANG model for connection 143 oriented OAM is designed to be extensible to other connection 144 oriented technologies. Technology dependent nodes and remote process 145 call (RPC) commands are defined in technology specific YANG models, 146 which use and extend the base model defined here. As an example, 147 VXLAN uses source UDP port number for flow entropy, while TRILL uses 148 either MAC addresses, the VLAN tag or fine grain label, and/or IP 149 addresses for flow entropy in the hashing for multipath selection. 150 To capture this variation, corresponding YANG models would define the 151 applicable structures as augmentation to the generic base model 152 presented here. This accomplishes three goals: First it keeps each 153 YANG model smaller and more manageable. Second, it allows 154 independent development of corresponding YANG models. Third, 155 implementations can limit support to only the applicable set of YANG 156 models. (e.g. TRILL RBridge may only need to implement Generic model 157 and the TRILL YANG model). 159 All implementations that follow the YANG framework presented in this 160 document MUST implement the generic connection oriented YANG model 161 presented here. 163 The YANG data model presented in this document is generated at the 164 management layer. Encapsulations and state machines may differ 165 according to each OAM protocol. A user who wishes to issues a 166 Continuity Check command or a Loopback or initiate a performance 167 monitoring session can do so in the same manner regardless of the 168 underlying protocol or technology or specific vendor implementation. 170 As an example, consider a scenario where connectivity from device A 171 loopback to device B fails. Between device A and B there are IEEE 172 802.1 bridges a, b and c. Let's assume a,b and c are using CFM 173 [IEEE802.1ag]. A user upon detecting the loopback failure, may 174 decide to drill down to the lower level at different segments of the 175 path and issue the corresponding fault verification (LBM) and fault 176 isolation (LTM) tools, using the same API. This ability to drill 177 down to a lower layer of the protocol stack at a specific segment 178 within a path for fault localization and troubleshooting is referred 179 to as "nested OAM workflow". It is a useful concept that leads to 180 efficient network troubleshooting and maintenance workflows. The 181 connection oriented OAM YANG model presented in this document 182 facilitates that without needing changes to the underlying protocols. 184 The YANG model in this document conforms to the Network Management 185 Datastore Architecture defined in 186 [I-D.ietf-netmod-revised-datastores]. 188 2. Conventions used in this document 190 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in 193 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 2.1. Abbreviations 198 CCM - Continuity Check Message [IEEE802.1ag]. 200 ECMP - Equal Cost Multipath. 202 LBM - Loopback Message [IEEE802.1ag]. 204 MP - Maintenance Point [IEEE802.1ag]. 206 MEP - Maintenance End Point [RFC7174] (Maintenance association End 207 Point [IEEE802.1ag], MEG End Points [RFC6371]). 209 MIP - Maintenance Intermediate Point [RFC7174] (Maintenance domain 210 Intermediate Point [IEEE802.1ag], MEG Intermediate Point 211 [RFC6371]). 213 MA - Maintenance Association [IEEE802.1ag] [RFC7174]. 215 MD - Maintenance Domain [IEEE802.1ag] 217 MEG - Maintenance Entity Group [RFC6371] 219 MTV - Multi-destination Tree Verification Message. 221 OAM - Operations, Administration, and Maintenance [RFC6291]. 223 TRILL - Transparent Interconnection of Lots of Links [RFC6325]. 225 CFM - Connectivity Fault Management [RFC7174] [IEEE802.1ag]. 227 RPC - Remote Process Call. 229 CC - Continuity Check [RFC7276]. 231 CV - Connectivity Verification [RFC7276]. 233 2.2. Terminology 235 Continuity Checks - Continuity Checks are used to verify that a 236 destination is reachable and therefore also referred to as 237 reachability verification. 239 Connectivity Verification - Connectivity Verification are used to 240 verify that a destination is connected. It are also referred to 241 as path verification and used to verify not only that the two MPs 242 are connected, but also that they are connected through the 243 expected path, allowing detection of unexpected topology changes. 245 Proactive OAM - The proactive OAM refers to OAM actions which are 246 carried out continuously to permit proactive reporting of fault. 247 Proactive OAM method requires persistent configuration. 249 On-demand OAM - The on-demand OAM refers to OAM actions which are 250 initiated via manual intervention for a limited time to carry out 251 diagnostics. On-demand OAM method requires only transient 252 configuration. 254 2.3. Tree Diagrams 256 Tree diagrams used in this document follow the notation defined in 257 [I-D.ietf-netmod-yang-tree-diagrams]. 259 3. Architecture of Generic YANG Model for OAM 261 In this document we define a generic YANG model for connection 262 oriented OAM protocols. The YANG model defined here is generic in a 263 sense that other technologies can extend it for technology specific 264 needs. The Generic YANG model acts as the root for other OAM YANG 265 models. This allows users to traverse between different OAM 266 protocols with ease through a uniform API set. This also enables a 267 nested OAM workflow. Figure 1 depicts the relationship of different 268 OAM YANG models to the Generic YANG Model for connection oriented 269 OAM. The Generic YANG model for OAM provides a framework where 270 technology- specific YANG models can inherit constructs from the base 271 YANG models without needing to redefine them within the sub- 272 technology. 274 Figure 1 depicts relationship of different YANG modules. 276 +----------+ 277 |Connection| 278 | Oriented | 279 | gen | 280 |OAM YANG | 281 +-+-+-+-+-++ 282 | 283 | 284 | 285 +------------------------------------------+ 286 | | | 287 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 288 | TRILL | | MPLS-TP | . . .| foo | 289 |OAM YANG | |OAM YANG | |OAM YANG | 290 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 291 | | | 292 | | +-+-+-+-+-+ 293 | | . . .| foo | 294 | | |sub tech | 295 | | +-+-+-+-+-+ 296 | | | 297 | | | 298 +-------------------------------------------------------+ 299 | Uniform API | 300 +-------------------------------------------------------+ 302 Relationship of OAM YANG model to generic (base) YANG model 304 4. Overview of the OAM Model 306 In this document we adopt the concepts of the CFM [IEEE802.1ag] model 307 and structure it such that it can be adapted to different connection 308 oriented OAM protocols. 310 At the top of the Model is the Maintenance Domain. Each Maintenance 311 Domain is associated with a Maintenance Name and a Domain Level. 313 Under each Maintenance Domain there is one or more Maintenance 314 Association (MA). In TRILL this can be per Fine-Grained Label. 316 Under each MA, there can be two or more MEPs (Maintenance End 317 Points). MEPs are addressed by their respective technology specific 318 address identifiers. The YANG model presented here provides 319 flexibility to accommodate different addressing schemes. 321 In the vertical direction orthogonal to the Maintenance Domain, 322 presented are the commands. Those, in YANG terms, are the RPC 323 commands. These RPC commands provide uniform APIs for continuity 324 check, connectivity verification, path discovery(traceroute) and 325 their equivalents as well as other OAM commands. 327 The OAM entities in the generic YANG model defined here will be 328 either explicitly or implicitly configured using any of the OAM 329 tools. The OAM tools used here are limited to OAM toolset specified 330 in section 5.1 of [RFC7276]. In order to facilitate zero-touch 331 experience, this document defines a default mode of OAM. The default 332 mode of OAM is referred to as the Base Mode and specifies default 333 values for each of model parameters, such as Maintenance Domain 334 Level, Name of the Maintenance Association, Addresses of MEPs and so 335 on. The default values of these depend on the technology. Base Mode 336 for TRILL is defined in [RFC7455]. Base mode for other technologies 337 and future extensions developed in IETF will be defined in their 338 corresponding documents. 340 It is important to note that, no specific enhancements are needed in 341 the YANG model to support Base Mode. Implementations that comply 342 with this document, by default implement the data nodes of the 343 applicable technology. Data nodes of the Base Mode are read-only 344 nodes. 346 4.1. Maintenance Domain (MD) configuration 348 The container "domains" is the top level container within the gen-oam 349 module. Within the container "domains", separate list is maintained 350 per MD. The MD list uses the key "md-name-string" for indexing. The 351 "md-name-string" is a leaf and derived from type string. Additional 352 name formats as defined in [IEEE802.1ag] or other standards can be 353 included by association of the "md-name-format" with an identity-ref. 354 The "md-name-format" indicates the format of the augmented "md-name". 355 The "md-name" is presented as choice/case construct. Thus, it is 356 easily augmentable by derivative work. 358 module: ietf-connection-oriented-oam 359 +--rw domains 360 +--rw domain* [technology md-name-string] 361 +--rw technology identityref 362 +--rw md-name-string md-name-string 363 +--rw md-name-format? identityref 364 +--rw (md-name)? 365 | +--:(md-name-null) 366 | +--rw md-name-null? empty 367 +--rw md-level? md-level 369 Snippet of data hierarchy related to OAM domains 371 4.2. Maintenance Association (MA) configuration 373 Within a given Maintenance Domain there can be one or more 374 Maintenance Associations (MA(s)). MAs are represented as a list and 375 indexed by the "ma-name-string". Similar to "md-name" defined 376 previously, additional name formats can be added by augmenting the 377 name-format identity-ref and adding applicable case statements to 378 "ma-name". 380 module: ietf-connection-oriented-oam 381 +--rw domains 382 +--rw domain* [technology md-name-string] 383 . 384 . 385 +--rw mas 386 +--rw ma* [ma-name-string] 387 +--rw ma-name-string ma-name-string 388 +--rw ma-name-format? identityref 389 +--rw (ma-name)? 390 | +--:(ma-name-null) 391 | +--rw ma-name-null? empty 393 Snippet of data hierarchy related to Maintenance Associations (MA) 395 4.3. Maintenance Endpoint (MEP) configuration 397 Within a given Maintenance Association (MA), there can be one or more 398 Maintenance End Points (MEP). MEPs are represented as a list within 399 the data hierarchy and indexed by the key "mep-name". 401 module: ietf-connection-oriented-oam 402 +--rw domains 403 +--rw domain* [technology md-name-string] 404 +--rw technology identityref 405 . 406 . 407 +--rw mas 408 +--rw ma* [ma-name-string] 409 . 410 . 411 +--rw mep* [mep-name] 412 | +--rw mep-name mep-name 413 | +--rw (mep-id)? 414 | | +--:(mep-id-int) 415 | | +--rw mep-id-int? int32 416 | +--rw mep-id-format? identityref 417 | +--rw (mep-address)? 418 | | +--:(mac-address) 419 | | | +--rw mac-address? yang:mac-address 420 | | +--:(ip-address) 421 | | +--rw ip-address? inet:ip-address 422 . . 423 . . 424 . . 426 Snippet of data hierarchy related to Maintenance Endpoint (MEP) 428 4.4. RPC definitions 430 The RPC model facilitates issuing commands to a "server" (in this 431 case to the device that need to execute the OAM command) and obtain a 432 response. RPC model defined here abstracts OAM specific commands in 433 a technology independent manner. 435 There are several RPC commands defined for the purpose of OAM. In 436 this section we present a snippet of the continuity check command for 437 illustration purposes. Please refer to Section 4.5 for the complete 438 data hierarchy and Section 5 for the YANG model. 440 module: ietf-connection-oriented-oam 441 +--rw domains 442 +--rw domain* [technology md-name-string] 443 +--rw technology identityref 444 . 445 . 446 rpcs: 447 +---x continuity-check {continuity-check}? 448 | +---w input 449 | | +---w technology? identityref 450 | | +---w md-name-string -> /domains/domain/md-name-string 451 | | +---w md-level? -> /domains/domain/md-level 452 | | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string 453 | | +---w cos-id? uint8 454 | | +---w ttl? uint8 455 | | +---w sub-type? identityref 456 | | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name 457 | | +---w destination-mep 458 | | | +---w (mep-address)? 459 | | | | +--:(mac-address) 460 | | | | | +---w mac-address? yang:mac-address 461 | | | | +--:(ip-address) 462 | | | | +---w ip-address? inet:ip-address 463 | | | +---w (mep-id)? 464 | | | | +--:(mep-id-int) 465 | | | | +---w mep-id-int? int32 466 | | | +---w mep-id-format? identityref 467 | | +---w count? uint32 468 | | +---w cc-transmit-interval? time-interval 469 | | +---w packet-size? uint32 470 | +--ro output 471 | +--ro (monitor-stats)? 472 | +--:(monitor-null) 473 | +--ro monitor-null? empty 474 +---x continuity-verification {connectivity-verification}? 475 | +---w input 476 | | +---w md-name-string -> /domains/domain/md-name-string 477 | | +---w md-level? -> /domains/domain/md-level 478 | | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string 479 | | +---w cos-id? uint8 480 | | +---w ttl? uint8 481 | | +---w sub-type? identityref 482 | | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name 483 | | +---w destination-mep 484 | | | +---w (mep-address)? 485 | | | | +--:(mac-address) 486 | | | | | +---w mac-address? yang:mac-address 487 | | | | +--:(ip-address) 488 | | | | +---w ip-address? inet:ip-address 489 | | | +---w (mep-id)? 490 | | | | +--:(mep-id-int) 491 | | | | +---w mep-id-int? int32 492 | | | +---w mep-id-format? identityref 493 | | +---w count? uint32 494 | | +---w interval? time-interval 495 | | +---w packet-size? uint32 496 | +--ro output 497 | +--ro (monitor-stats)? 498 | +--:(monitor-null) 499 | +--ro monitor-null? empty 500 +---x traceroute {traceroute}? 501 +---w input 502 | +---w md-name-string -> /domains/domain/md-name-string 503 | +---w md-level? -> /domains/domain/md-level 504 | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string 505 | +---w cos-id? uint8 506 | +---w ttl? uint8 507 | +---w command-sub-type? identityref 508 | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name 509 | +---w destination-mep 510 | | +---w (mep-address)? 511 | | | +--:(mac-address) 512 | | | | +---w mac-address? yang:mac-address 513 | | | +--:(ip-address) 514 | | | +---w ip-address? inet:ip-address 515 | | +---w (mep-id)? 516 | | | +--:(mep-id-int) 517 | | | +---w mep-id-int? int32 518 | | +---w mep-id-format? identityref 519 | +---w count? uint32 520 | +---w interval? time-interval 521 +--ro output 522 +--ro response* [response-index] 523 +--ro response-index uint8 524 +--ro ttl? uint8 525 +--ro destination-mep 526 | +--ro (mep-address)? 527 | | +--:(mac-address) 528 | | | +--ro mac-address? yang:mac-address 529 | | +--:(ip-address) 530 | | +--ro ip-address? inet:ip-address 531 | +--ro (mep-id)? 532 | | +--:(mep-id-int) 533 | | +--ro mep-id-int? int32 534 | +--ro mep-id-format? identityref 535 +--ro mip {mip}? 536 | +--ro interface? if:interface-ref 537 | +--ro (mip-address)? 538 | +--:(mac-address) 539 | | +--ro mac-address? yang:mac-address 540 | +--:(ip-address) 541 | +--ro ip-address? inet:ip-address 542 +--ro (monitor-stats)? 543 +--:(monitor-null) 544 +--ro monitor-null? empty 546 Snippet of data hierarchy related to RPC call continuity-check 548 4.5. Notifications 550 Notification is sent on defect condition and defect clears with 551 Maintenance Domain Name, MA Name, defect-type (The currently active 552 defects), generating-mepid, and defect-message to indicate more 553 details. 555 4.6. Monitor statistics 557 Grouping for monitoring statistics is to be used by YANG modules 558 which Augment YANG to provide statistics due to pro-active OAM like 559 CCM Messages. For example CCM Transmit, CCM Receive, CCM Errors, 560 etc. 562 4.7. OAM data hierarchy 564 The complete data hierarchy related to the connection oriented OAM 565 YANG model is presented below. 567 module: ietf-connection-oriented-oam 568 +--rw domains 569 +--rw domain* [technology md-name-string] 570 +--rw technology identityref 571 +--rw md-name-string md-name-string 572 +--rw md-name-format? identityref 573 +--rw (md-name)? 574 | +--:(md-name-null) 575 | +--rw md-name-null? empty 576 +--rw md-level? md-level 577 +--rw mas 578 +--rw ma* [ma-name-string] 579 +--rw ma-name-string ma-name-string 580 +--rw ma-name-format? identityref 581 +--rw (ma-name)? 582 | +--:(ma-name-null) 583 | +--rw ma-name-null? empty 584 +--rw (connectivity-context)? 585 | +--:(context-null) 586 | +--rw context-null? empty 587 +--rw cos-id? uint8 588 +--rw cc-enable? boolean 589 +--rw mep* [mep-name] 590 | +--rw mep-name mep-name 591 | +--rw (mep-id)? 592 | | +--:(mep-id-int) 593 | | +--rw mep-id-int? int32 594 | +--rw mep-id-format? identityref 595 | +--rw (mep-address)? 596 | | +--:(mac-address) 597 | | | +--rw mac-address? yang:mac-address 598 | | +--:(ip-address) 599 | | +--rw ip-address? inet:ip-address 600 | +--rw cos-id? uint8 601 | +--rw cc-enable? boolean 602 | +--rw session* [session-cookie] 603 | +--rw session-cookie uint32 604 | +--rw destination-mep 605 | | +--rw (mep-id)? 606 | | | +--:(mep-id-int) 607 | | | +--rw mep-id-int? int32 608 | | +--rw mep-id-format? identityref 609 | +--rw destination-mep-address 610 | | +--rw (mep-address)? 611 | | +--:(mac-address) 612 | | | +--rw mac-address? yang:mac-address 613 | | +--:(ip-address) 614 | | +--rw ip-address? inet:ip-address 615 | +--rw cos-id? uint8 616 +--rw mip* [name] {mip}? 617 +--rw name string 618 +--rw interface? if:interface-ref 619 +--rw (mip-address)? 620 +--:(mac-address) 621 | +--rw mac-address? yang:mac-address 622 +--:(ip-address) 623 +--rw ip-address? inet:ip-address 625 rpcs: 626 +---x continuity-check {continuity-check}? 627 | +---w input 628 | | +---w technology? identityref 629 | | +---w md-name-string -> /domains/domain/md-name-string 630 | | +---w md-level? -> /domains/domain/md-level 631 | | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string 632 | | +---w cos-id? uint8 633 | | +---w ttl? uint8 634 | | +---w sub-type? identityref 635 | | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name 636 | | +---w destination-mep 637 | | | +---w (mep-address)? 638 | | | | +--:(mac-address) 639 | | | | | +---w mac-address? yang:mac-address 640 | | | | +--:(ip-address) 641 | | | | +---w ip-address? inet:ip-address 642 | | | +---w (mep-id)? 643 | | | | +--:(mep-id-int) 644 | | | | +---w mep-id-int? int32 645 | | | +---w mep-id-format? identityref 646 | | +---w count? uint32 647 | | +---w cc-transmit-interval? time-interval 648 | | +---w packet-size? uint32 649 | +--ro output 650 | +--ro (monitor-stats)? 651 | +--:(monitor-null) 652 | +--ro monitor-null? empty 653 +---x continuity-verification {connectivity-verification}? 654 | +---w input 655 | | +---w md-name-string -> /domains/domain/md-name-string 656 | | +---w md-level? -> /domains/domain/md-level 657 | | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string 658 | | +---w cos-id? uint8 659 | | +---w ttl? uint8 660 | | +---w sub-type? identityref 661 | | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name 662 | | +---w destination-mep 663 | | | +---w (mep-address)? 664 | | | | +--:(mac-address) 665 | | | | | +---w mac-address? yang:mac-address 666 | | | | +--:(ip-address) 667 | | | | +---w ip-address? inet:ip-address 668 | | | +---w (mep-id)? 669 | | | | +--:(mep-id-int) 670 | | | | +---w mep-id-int? int32 671 | | | +---w mep-id-format? identityref 672 | | +---w count? uint32 673 | | +---w interval? time-interval 674 | | +---w packet-size? uint32 675 | +--ro output 676 | +--ro (monitor-stats)? 677 | +--:(monitor-null) 678 | +--ro monitor-null? empty 679 +---x traceroute {traceroute}? 680 +---w input 681 | +---w md-name-string -> /domains/domain/md-name-string 682 | +---w md-level? -> /domains/domain/md-level 683 | +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string 684 | +---w cos-id? uint8 685 | +---w ttl? uint8 686 | +---w command-sub-type? identityref 687 | +---w source-mep? -> /domains/domain/mas/ma/mep/mep-name 688 | +---w destination-mep 689 | | +---w (mep-address)? 690 | | | +--:(mac-address) 691 | | | | +---w mac-address? yang:mac-address 692 | | | +--:(ip-address) 693 | | | +---w ip-address? inet:ip-address 694 | | +---w (mep-id)? 695 | | | +--:(mep-id-int) 696 | | | +---w mep-id-int? int32 697 | | +---w mep-id-format? identityref 698 | +---w count? uint32 699 | +---w interval? time-interval 700 +--ro output 701 +--ro response* [response-index] 702 +--ro response-index uint8 703 +--ro ttl? uint8 704 +--ro destination-mep 705 | +--ro (mep-address)? 706 | | +--:(mac-address) 707 | | | +--ro mac-address? yang:mac-address 708 | | +--:(ip-address) 709 | | +--ro ip-address? inet:ip-address 710 | +--ro (mep-id)? 711 | | +--:(mep-id-int) 712 | | +--ro mep-id-int? int32 713 | +--ro mep-id-format? identityref 714 +--ro mip {mip}? 715 | +--ro interface? if:interface-ref 716 | +--ro (mip-address)? 717 | +--:(mac-address) 718 | | +--ro mac-address? yang:mac-address 719 | +--:(ip-address) 720 | +--ro ip-address? inet:ip-address 721 +--ro (monitor-stats)? 722 +--:(monitor-null) 723 +--ro monitor-null? empty 725 notifications: 726 +---n defect-condition-notification 727 | +--ro technology? identityref 728 | +--ro md-name-string -> /domains/domain/md-name-string 729 | +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string 730 | +--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name 731 | +--ro defect-type? identityref 732 | +--ro generating-mepid 733 | | +--ro (mep-id)? 734 | | | +--:(mep-id-int) 735 | | | +--ro mep-id-int? int32 736 | | +--ro mep-id-format? identityref 737 | +--ro (defect)? 738 | +--:(defect-null) 739 | | +--ro defect-null? empty 740 | +--:(defect-code) 741 | +--ro defect-code? int32 742 +---n defect-cleared-notification 743 +--ro technology? identityref 744 +--ro md-name-string -> /domains/domain/md-name-string 745 +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string 746 +--ro mep-name? -> /domains/domain/mas/ma/mep/mep-name 747 +--ro defect-type? identityref 748 +--ro generating-mepid 749 | +--ro (mep-id)? 750 | | +--:(mep-id-int) 751 | | +--ro mep-id-int? int32 752 | +--ro mep-id-format? identityref 753 +--ro (defect)? 754 +--:(defect-null) 755 | +--ro defect-null? empty 756 +--:(defect-code) 757 +--ro defect-code? int32 759 data hierarchy of OAM 761 5. OAM YANG Module 763 file "ietf-connection-oriented-oam@2018-02-07.yang" 765 module ietf-connection-oriented-oam { 766 yang-version 1.1; 767 namespace "urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam"; 768 prefix co-oam; 770 import ietf-yang-types { 771 prefix yang; 772 } 773 import ietf-inet-types { 774 prefix inet; 775 } 776 import ietf-interfaces { 777 prefix if; 778 } 780 organization 781 "IETF LIME Working Group"; 782 contact 783 "WG Web: http://tools.ietf.org/wg/lime 784 WG List: mailto:lime@ietf.org 785 Editor: Deepak Kumar dekumar@cisco.com 786 Editor: Qin Wu bill.wu@huawei.com 787 Editor: Zitao Wang wangzitao@huawei.com"; 788 description 789 "This YANG module defines the generic configuration, 790 statistics and rpc for connection oriented OAM 791 to be used within IETF in a protocol independent manner. 792 Functional level abstraction is independent 793 with YANG modeling. It is assumed that each protocol 794 maps corresponding abstracts to its native format. 795 Each protocol may extend the YANG model defined 796 here to include protocol specific extensions"; 798 revision 2018-02-07 { 799 description 800 "Initial revision. - 12 version"; 801 reference "draft-ietf-lime-yang-oam-model"; 802 } 804 feature connectivity-verification { 805 description 806 "This feature indicates that the server supports 807 executing connectivity verification OAM command and 808 returning a response. Servers that do not advertise 809 this feature will not support executing 810 connectivity verification command or rpc model for 811 connectivity verification command."; 812 } 814 feature continuity-check { 815 description 816 "This feature indicates that the server supports 817 executing continuity check OAM command and 818 returning a response. Servers that do not advertise 819 this feature will not support executing 820 continuity check command or rpc model for 821 continuity check command."; 822 } 824 feature traceroute { 825 description 826 "This feature indicates that the server supports 827 executing traceroute OAM command and 828 returning a response. Servers that do not advertise 829 this feature will not support executing 830 traceroute command or rpc model for 831 traceroute command."; 832 } 834 feature mip { 835 description 836 "This feature indicates that the Maintenance 837 Intermediate Point(MIP) needs to be explicit configured"; 838 } 840 identity technology-types { 841 description 842 "This is the base identy of technology types which are 843 TRILL, MPLS-TP, etc"; 844 } 846 identity command-sub-type { 847 description 848 "Defines different rpc command subtypes, 849 e.g rfc6905 trill OAM, this is optional for most cases"; 850 } 852 identity on-demand { 853 base command-sub-type; 854 description 855 "On demand activation - indicates that the tool is activated 856 manually to detect a specific anomaly. 857 On-demand OAM method requires only transient configuration."; 858 } 860 identity proactive { 861 base command-sub-type; 862 description 863 "Proactive activation - indicates that the tool is activated on a 864 continual basis, where messages are sent periodically, and errors 865 are detected when a certain number of expected messages are not 866 received. Proactive OAM method requires persistent 867 configuration."; 868 } 870 identity name-format { 871 description 872 "This defines the name format, IEEE 8021ag CFM defines varying 873 styles of names. It is expected name format as an identity ref 874 to be extended with new types."; 875 } 877 identity name-format-null { 878 base name-format; 879 description 880 "Defines name format as null"; 881 } 883 identity identifier-format { 884 description 885 "Identifier-format identity can be augmented to define other 886 format identifiers used in MEP-ID etc"; 887 } 889 identity identifier-format-integer { 890 base identifier-format; 891 description 892 "Defines identifier-format to be integer"; 893 } 895 identity defect-types { 896 description 897 "Defines different defect types, e.g. 898 Remote Defect Indication (rdi), loss of continuity"; 899 } 901 identity rdi { 902 base defect-types; 903 description 904 "The Remote Defect Indication (rdi) indicates the 905 aggregate health of the remote Maintenance End Points (MEPs)."; 906 } 908 identity remote-mep-defect { 909 base defect-types; 910 description 911 "Indicates that one or more of the remote 912 Maintenance End Points(MEPs)is reporting a failure "; 913 } 915 identity loss-of-continuity { 916 base defect-types; 917 description 918 "If no proactive Continuity Check (CC) 919 OAM packets from the source Maintenance End Point 920 (MEP) (and in the case of Connectivity 921 Verification , this includes the 922 requirement to have the expected unique, 923 technology dependent source MEP 924 identifier) are received within the interval."; 925 } 926 identity cv-defect { 927 base defect-types; 928 description 929 "This function should support monitoring between 930 the Maintenance End Points (MEPs) and, 931 in addition, between a MEP and Maintenance Intermediate 932 Point (MIP). [RFC6371] highlights, when performing 933 Connectivity Verification, the need for the Continuity 934 Check and Connectivity Verification (CC-V) messages 935 to include unique identification of the MEG that is being 936 monitored and the MEP that originated the message."; 937 } 939 identity invalid-oam-defect { 940 base defect-types; 941 description 942 "Indicates that one or more invalid OAM messages has been 943 received and that 3.5 times that OAM message transmission 944 interval has not yet expired."; 945 } 947 identity cross-connect-defect { 948 base defect-types; 949 description 950 "Indicates that one or more cross-connect defect 951 (for example, a service ID does not match the VLAN.) 952 messages has been received and that 3.5 times that OAM message 953 transmission interval has not yet expired."; 954 } 956 typedef mep-name { 957 type string; 958 description 959 "Generic administrative name for a Maintenance End Point 960 (MEP)."; 961 } 963 typedef time-interval { 964 type decimal64 { 965 fraction-digits 2; 966 } 967 units "milliseconds"; 968 description 969 "Time interval between packets in milliseconds. 970 0 means no packets are sent."; 971 } 973 typedef md-name-string { 974 type string; 975 description 976 "Generic administrative name for Maintenance Domain (MD)."; 977 } 979 typedef ma-name-string { 980 type string; 981 description 982 "Generic administrative name for an 983 Maintenance Association (MA)."; 984 } 986 typedef oam-counter32 { 987 type yang:zero-based-counter32; 988 description 989 "Define 32 bit counter for OAM."; 990 } 992 typedef md-level { 993 type uint32 { 994 range "0..255"; 995 } 996 description 997 "Maintenance Domain level. The level may be restricted in 998 certain protocols (e.g., protocol in layer 0 to layer 7)."; 999 } 1001 grouping maintenance-domain-reference { 1002 description 1003 "This grouping uniquely identifies a maintenance domain."; 1004 leaf maintenance-domain { 1005 type leafref { 1006 path "/co-oam:domains/co-oam:domain/co-oam:md-name-string"; 1007 } 1008 description 1009 "A reference to a specific Maintenance Domain."; 1010 } 1011 } 1013 grouping maintenance-association-reference { 1014 description 1015 "This grouping uniquely identifies a 1016 maintenance association. It consists 1017 of a maintence-domain-reference and 1018 a maintenance-association leafref"; 1019 uses maintenance-domain-reference; 1020 leaf maintenance-association { 1021 type leafref { 1022 path "/co-oam:domains/co-oam:domain[co-oam:md-name-string " 1023 +"= current()/../maintenance-domain]/co-oam:mas" 1024 +"/co-oam:ma/co-oam:ma-name-string"; 1025 } 1026 description 1027 "A reference to a specific Maintenance Association."; 1028 } 1029 } 1031 grouping maintenance-association-end-point-reference { 1032 description 1033 "This grouping uniquely identifies 1034 a maintenance association. It consists 1035 of a maintence-association-reference and 1036 a maintenance-association-end-point leafref"; 1037 uses maintenance-association-reference; 1038 leaf maintenance-association-end-point { 1039 type leafref { 1040 path "/co-oam:domains/co-oam:domain[co-oam:md-name-string " 1041 +"= current()/../maintenance-domain]/co-oam:mas" 1042 +"/co-oam:ma[co-oam:ma-name-string = " 1043 +"current()/../maintenance-association]" 1044 +"/co-oam:mep/co-oam:mep-name"; 1045 } 1046 description 1047 "A reference to a specific Maintenance 1048 association End Point."; 1049 } 1050 } 1052 grouping time-to-live { 1053 leaf ttl { 1054 type uint8; 1055 description 1056 "Time to Live."; 1057 } 1058 description 1059 "Time to Live grouping."; 1060 } 1062 grouping defect-message { 1063 choice defect { 1064 case defect-null { 1065 description 1066 "This is a placeholder when no defect status is needed"; 1067 leaf defect-null { 1068 type empty; 1069 description 1070 "There is no defect to be defined, it will be defined in 1071 technology specific model."; 1072 } 1073 } 1074 case defect-code { 1075 description 1076 "This is a placeholder to display defect code."; 1077 leaf defect-code { 1078 type int32; 1079 description 1080 "Defect code is integer value specific to a technology."; 1081 } 1082 } 1083 description 1084 "Defect Message choices."; 1085 } 1086 description 1087 "Defect Message."; 1088 } 1090 grouping mep-address { 1091 choice mep-address { 1092 case mac-address { 1093 leaf mac-address { 1094 type yang:mac-address; 1095 description 1096 "MAC Address."; 1097 } 1098 description 1099 "MAC Address based Maintenance End Point (MEP) Addressing."; 1100 } 1101 case ip-address { 1102 leaf ip-address { 1103 type inet:ip-address; 1104 description 1105 "IP Address."; 1106 } 1107 description 1108 "IP Address based Maintenance End Point(MEP) Addressing."; 1109 } 1110 description 1111 "Maintenance End Point (MEP) Addressing."; 1112 } 1113 description 1114 "Grouping for Maintenance End Point(MEP) Address"; 1115 } 1117 grouping mip-address { 1118 choice mip-address { 1119 case mac-address { 1120 leaf mac-address { 1121 type yang:mac-address; 1122 description 1123 "MAC Address of Maintenance Intermediate Point"; 1124 } 1125 description 1126 "MAC Address based Maintenance Intermediate 1127 Point (MIP) Addressing."; 1128 } 1129 case ip-address { 1130 leaf ip-address { 1131 type inet:ip-address; 1132 description 1133 "IP Address."; 1134 } 1135 description 1136 "IP Address based Maintenance Intermediate Point(MIP) 1137 Addressing."; 1138 } 1139 description 1140 "Maintenance Intermediate Point (MIP) Addressing."; 1141 } 1142 description 1143 "Maintenance Intermediate Point (MIP) Address."; 1144 } 1146 grouping maintenance-domain-id { 1147 description 1148 "Grouping containing leaves sufficient to identify 1149 a Maintenance Domain."; 1150 leaf technology { 1151 type identityref { 1152 base technology-types; 1153 } 1154 mandatory true; 1155 description 1156 "Defines the technology."; 1157 } 1158 leaf md-name-string { 1159 type md-name-string; 1160 mandatory true; 1161 description 1162 "Defines the generic administrative maintenance domain name."; 1163 } 1164 } 1165 grouping md-name { 1166 leaf md-name-format { 1167 type identityref { 1168 base name-format; 1169 } 1170 description 1171 "Maintenance Domain Name format."; 1172 } 1173 choice md-name { 1174 case md-name-null { 1175 leaf md-name-null { 1176 when "derived-from-or-self(../md-name-format," 1177 +"'name-format-null')" { 1178 description 1179 "Maintenance Domain (MD) name 1180 format is equal to null format."; 1181 } 1182 type empty; 1183 description 1184 "Maintenance Domain (MD) name Null."; 1185 } 1186 } 1187 description 1188 "Maintenance Domain (MD) name."; 1189 } 1190 description 1191 "Maintenance Domain (MD) name."; 1192 } 1194 grouping ma-identifier { 1195 description 1196 "Grouping containing leaves sufficient to identify 1197 an Maintenance Association (MA)."; 1198 leaf ma-name-string { 1199 type ma-name-string; 1200 description 1201 "Maintenance Association (MA) name string."; 1202 } 1203 } 1205 grouping ma-name { 1206 description 1207 "Maintenance Association (MA) name."; 1208 leaf ma-name-format { 1209 type identityref { 1210 base name-format; 1211 } 1212 description 1213 "Maintenance Association (MA) name format."; 1214 } 1215 choice ma-name { 1216 case ma-name-null { 1217 leaf ma-name-null { 1218 when "derived-from-or-self(../ma-name-format, " 1219 +"'name-format-null')" { 1220 description 1221 "Maintenance Association (MA)."; 1222 } 1223 type empty; 1224 description 1225 "Empty"; 1226 } 1227 } 1228 description 1229 "Maintenance Association) name(MA)."; 1230 } 1231 } 1233 grouping mep-id { 1234 choice mep-id { 1235 default "mep-id-int"; 1236 case mep-id-int { 1237 leaf mep-id-int { 1238 type int32; 1239 description 1240 "Maintenance End Point (MEP) ID 1241 in integer format."; 1242 } 1243 } 1244 description 1245 "Maintenance End Point (MEP) ID."; 1246 } 1247 leaf mep-id-format { 1248 type identityref { 1249 base identifier-format; 1250 } 1251 description 1252 "Maintenance End Point (MEP) ID format."; 1253 } 1254 description 1255 "Maintenance End Point (MEP) ID."; 1256 } 1258 grouping mep { 1259 description 1260 "Defines elements within the 1261 Maintenance End Point (MEP)."; 1262 leaf mep-name { 1263 type mep-name; 1264 mandatory true; 1265 description 1266 "Generic administrative name of the 1267 Maintenance End Point (MEP)."; 1268 } 1269 uses mep-id; 1270 uses mep-address; 1271 } 1273 grouping monitor-stats { 1274 description 1275 "grouping for monitoring statistics, this will be augmented 1276 by others who use this component"; 1277 choice monitor-stats { 1278 default "monitor-null"; 1279 case monitor-null { 1280 description 1281 "This is a place holder when 1282 no monitoring statistics is needed"; 1283 leaf monitor-null { 1284 type empty; 1285 description 1286 "There is no monitoring statistics to be defined."; 1287 } 1288 } 1289 description 1290 "Define the monitor stats."; 1291 } 1292 } 1294 grouping connectivity-context { 1295 description 1296 "Grouping defining the connectivity context for an 1297 Maintenance Association (MA), for example, 1298 an LSP for MPLS-TP. This will be 1299 augmented by each protocol who use this component."; 1300 choice connectivity-context { 1301 default "context-null"; 1302 case context-null { 1303 description 1304 "This is a place holder when no context is needed."; 1305 leaf context-null { 1306 type empty; 1307 description 1308 "There is no context to be defined."; 1310 } 1311 } 1312 description 1313 "Connectivity context."; 1314 } 1315 } 1317 grouping cos { 1318 description 1319 "Grouping for Priority used in transmitted packets, 1320 for example, in the CoS field in MPLS-TP."; 1321 leaf cos-id { 1322 type uint8; 1323 description 1324 "Class of Service(CoS) id, this value is used to indicate 1325 Class of Service information ."; 1326 } 1327 } 1329 grouping mip-grouping { 1330 uses mip-address; 1331 description 1332 "Grouping for Maintenance Intermediate Point(MIP) 1333 configuration."; 1334 } 1336 container domains { 1337 description 1338 "Contains configuration related data. Within the container 1339 is list of fault domains. Within each domian has List of 1340 Maintenance Association (MA)."; 1341 list domain { 1342 key "technology md-name-string"; 1343 description 1344 "Define the list of fault Domains within the 1345 ietf-connection-oriented-oam module."; 1346 uses maintenance-domain-id; 1347 uses md-name; 1348 leaf md-level { 1349 type md-level; 1350 description 1351 "Define the MD-Level."; 1352 } 1353 container mas { 1354 description 1355 "This container defines Maintenance Association (MA), 1356 within that have multiple MA and within MA have 1357 Maintenance End Point (MEP)."; 1359 list ma { 1360 key "ma-name-string"; 1361 uses ma-identifier; 1362 uses ma-name; 1363 uses connectivity-context; 1364 uses cos { 1365 description 1366 "Default class of service for this 1367 Maintenance Association (MA), 1368 which may be overridden for particular 1369 Maintenance End Points (MEPs), 1370 sessions or operations."; 1371 } 1372 leaf cc-enable { 1373 type boolean; 1374 description 1375 "Indicate whether the 1376 Continuity Check (CC) is enabled."; 1377 } 1378 list mep { 1379 key "mep-name"; 1380 description 1381 "Contain a list of Maintenance End Points (MEPs)"; 1382 uses mep; 1383 uses cos; 1384 leaf cc-enable { 1385 type boolean; 1386 description 1387 "Indicate whether the Continuity Check (CC)is enabled."; 1388 } 1389 list session { 1390 key "session-cookie"; 1391 description 1392 "Monitoring session to/from a particular 1393 remote Maintenance End Point (MEP). 1394 Depending on the protocol, this could represent 1395 Continuity Check (CC) messages received from 1396 a single remote MEP (if the protocol uses 1397 multicast CCs) or a target to which 1398 unicast echo request CCs are sent and from which 1399 responses are received (if the protocol uses a 1401 unicast request/response mechanism)."; 1402 leaf session-cookie { 1403 type uint32; 1404 description 1405 "Cookie to identify different sessions, when there 1406 are multiple remote Maintenance End Point(MEP) 1407 or multiple sessions tothe same remote MEP."; 1408 } 1409 container destination-mep { 1410 uses mep-id; 1411 description 1412 "Destination Maintenance End Point(MEP)."; 1413 } 1414 container destination-mep-address { 1415 uses mep-address; 1416 description 1417 "Destination Maintenance End Point (MEP) Address."; 1418 } 1419 uses cos; 1420 } 1421 } 1422 list mip { 1423 if-feature "mip"; 1424 key "name"; 1425 leaf name { 1426 type string; 1427 description 1428 "Identifier of Maintenance intermediate point"; 1429 } 1430 leaf interface { 1431 type if:interface-ref; 1432 description 1433 "Interface"; 1434 } 1435 uses mip-grouping; 1436 description 1437 "List for Maintenance Intermediate Point (MIP)."; 1438 } 1439 description 1440 "Maintenance Association list."; 1441 } 1442 } 1443 } 1444 } 1445 notification defect-condition-notification { 1446 description 1447 "Upon the defect condition is met, this 1448 notification is sent"; 1449 leaf technology { 1450 type identityref { 1451 base technology-types; 1452 } 1453 description 1454 "The technology"; 1456 } 1457 leaf md-name-string { 1458 type leafref { 1459 path "/domains/domain/md-name-string"; 1460 } 1461 mandatory true; 1462 description 1463 "Indicate which Maintenance Domain(MD) 1464 does the defect belong to."; 1465 } 1466 leaf ma-name-string { 1467 type leafref { 1468 path "/domains/domain/mas/ma/ma-name-string"; 1469 } 1470 mandatory true; 1471 description 1472 "Indicate which Maintenance Association (MA) 1473 is the defect associated with."; 1474 } 1475 leaf mep-name { 1476 type leafref { 1477 path "/domains/domain/mas/ma/mep/mep-name"; 1478 } 1479 description 1480 "Indicate which Maintenance End Point(MEP) 1481 is seeing the defect."; 1482 } 1483 leaf defect-type { 1484 type identityref { 1485 base defect-types; 1486 } 1487 description 1488 "The currently active defects on the specific 1489 Maintenance End Point (MEP)."; 1490 } 1491 container generating-mepid { 1492 uses mep-id; 1493 description 1494 "Indicate who is generating the defect (if known). If 1495 unknown set it as 0."; 1496 } 1497 uses defect-message { 1498 description 1499 "The defect message to indicate more details."; 1500 } 1501 } 1502 notification defect-cleared-notification { 1503 description 1504 "Upon defect cleared is met, this notification is sent"; 1505 leaf technology { 1506 type identityref { 1507 base technology-types; 1508 } 1509 description 1510 "The technology."; 1511 } 1512 leaf md-name-string { 1513 type leafref { 1514 path "/domains/domain/md-name-string"; 1515 } 1516 mandatory true; 1517 description 1518 "Indicate which Maintenance Domain (MD) 1519 does the defect belong to"; 1520 } 1521 leaf ma-name-string { 1522 type leafref { 1523 path "/domains/domain/mas/ma/ma-name-string"; 1524 } 1525 mandatory true; 1526 description 1527 "Indicate which Maintenance Association (MA) 1528 is the defect associated with."; 1529 } 1530 leaf mep-name { 1531 type leafref { 1532 path "/domains/domain/mas/ma/mep/mep-name"; 1533 } 1534 description 1535 "Indicate which Maintenance End Point (MEP) 1536 is seeing the defect."; 1537 } 1538 leaf defect-type { 1539 type identityref { 1540 base defect-types; 1541 } 1542 description 1543 "The currently active defects on the 1544 specific Maintenance End Point (MEP)."; 1545 } 1546 container generating-mepid { 1547 uses mep-id; 1548 description 1549 "Indicate who is generating the defect (if known). if 1550 unknown set it as 0."; 1551 } 1552 uses defect-message { 1553 description 1554 "Defect message to indicate more details."; 1555 } 1556 } 1557 rpc continuity-check { 1558 if-feature "continuity-check"; 1559 description 1560 "Generates continuity-check as per RFC7276 Table 4."; 1561 input { 1562 leaf technology { 1563 type identityref { 1564 base technology-types; 1565 } 1566 description 1567 "The technology"; 1568 } 1569 leaf md-name-string { 1570 type leafref { 1571 path "/domains/domain/md-name-string"; 1572 } 1573 mandatory true; 1574 description 1575 "Indicate which Maintenance Domain (MD) 1576 does the defect belong to."; 1577 } 1578 leaf md-level { 1579 type leafref { 1580 path "/domains/domain/md-level"; 1581 } 1582 description 1583 "The maintenance domain level."; 1584 } 1585 leaf ma-name-string { 1586 type leafref { 1587 path "/domains/domain/mas/ma/ma-name-string"; 1588 } 1589 mandatory true; 1590 description 1591 "Indicate which MA is the defect associated with"; 1592 } 1593 uses cos; 1594 uses time-to-live; 1595 leaf sub-type { 1596 type identityref { 1597 base command-sub-type; 1598 } 1599 description 1600 "Defines different command types."; 1601 } 1602 leaf source-mep { 1603 type leafref { 1604 path "/domains/domain/mas/ma/mep/mep-name"; 1605 } 1606 description 1607 "Source Maintenance End Point (MEP)."; 1608 } 1609 container destination-mep { 1610 uses mep-address; 1611 uses mep-id { 1612 description 1613 "Only applicable if the destination is 1614 a Maintenance End Point (MEP)."; 1615 } 1616 description 1617 "Destination Maintenance End Point (MEP)."; 1618 } 1619 leaf count { 1620 type uint32; 1621 default "3"; 1622 description 1623 "Number of continuity-check message to be sent."; 1624 } 1625 leaf cc-transmit-interval { 1626 type time-interval; 1627 description 1628 "Time interval between echo requests."; 1629 } 1630 leaf packet-size { 1631 type uint32 { 1632 range "64..10000"; 1633 } 1634 description 1635 "Size of continuity-check packets, in octets."; 1636 } 1637 } 1638 output { 1639 uses monitor-stats { 1640 description 1641 "Stats of continuity check."; 1642 } 1643 } 1644 } 1645 rpc continuity-verification { 1646 if-feature "connectivity-verification"; 1647 description 1648 "Generates continuity-verification as per RFC7276 Table 4."; 1649 input { 1650 leaf md-name-string { 1651 type leafref { 1652 path "/domains/domain/md-name-string"; 1653 } 1654 mandatory true; 1655 description 1656 "Indicate which MD (Maintenance Domain) 1657 does the defect belong to."; 1658 } 1659 leaf md-level { 1660 type leafref { 1661 path "/domains/domain/md-level"; 1662 } 1663 description 1664 "The maintenance domain level."; 1665 } 1666 leaf ma-name-string { 1667 type leafref { 1668 path "/domains/domain/mas/ma/ma-name-string"; 1669 } 1670 mandatory true; 1671 description 1672 "Indicate which Maintenance Association (MA) 1673 is the defect associated with."; 1674 } 1675 uses cos; 1676 uses time-to-live; 1677 leaf sub-type { 1678 type identityref { 1679 base command-sub-type; 1680 } 1681 description 1682 "Defines different command types."; 1683 } 1684 leaf source-mep { 1685 type leafref { 1686 path "/domains/domain/mas/ma/mep/mep-name"; 1687 } 1688 description 1689 "Source Maintenance End Point(MEP)."; 1690 } 1691 container destination-mep { 1692 uses mep-address; 1693 uses mep-id { 1694 description 1695 "Only applicable if the destination 1696 is a Maintenance End Point (MEP)."; 1697 } 1698 description 1699 "Destination Maintenance End Point(MEP)."; 1700 } 1701 leaf count { 1702 type uint32; 1703 default "3"; 1704 description 1705 "Number of continuity-verification message to be sent."; 1706 } 1707 leaf interval { 1708 type time-interval; 1709 description 1710 "Time interval between echo requests."; 1711 } 1712 leaf packet-size { 1713 type uint32 { 1714 range "64..10000"; 1715 } 1716 description 1717 "Size of continuity-verification packets, in octets"; 1718 } 1719 } 1720 output { 1721 uses monitor-stats { 1722 description 1723 "Stats of continuity check."; 1724 } 1725 } 1726 } 1727 rpc traceroute { 1728 if-feature "traceroute"; 1729 description 1730 "Generates Traceroute or Path Trace and return response. 1731 Referencing RFC7276 for common Toolset name, for 1732 MPLS-TP OAM it's Route Tracing, and for TRILL OAM It's 1733 Path Tracing tool. Starts with TTL of one and increment 1734 by one at each hop. Untill destination reached or TTL 1735 reach max value."; 1736 input { 1737 leaf md-name-string { 1738 type leafref { 1739 path "/domains/domain/md-name-string"; 1740 } 1741 mandatory true; 1742 description 1743 "Indicate which Maintenance Domain (MD) 1744 does the defect belong to."; 1745 } 1746 leaf md-level { 1747 type leafref { 1748 path "/domains/domain/md-level"; 1749 } 1750 description 1751 "The maintenance domain level."; 1752 } 1753 leaf ma-name-string { 1754 type leafref { 1755 path "/domains/domain/mas/ma/ma-name-string"; 1756 } 1757 mandatory true; 1758 description 1759 "Indicate which Maintenance Association (MA) 1760 is the defect associated with."; 1761 } 1762 uses cos; 1763 uses time-to-live; 1764 leaf command-sub-type { 1765 type identityref { 1766 base command-sub-type; 1767 } 1768 description 1769 "Defines different command types."; 1770 } 1771 leaf source-mep { 1772 type leafref { 1773 path "/domains/domain/mas/ma/mep/mep-name"; 1774 } 1775 description 1776 "Source Maintenance End Point (MEP)."; 1777 } 1778 container destination-mep { 1779 uses mep-address; 1780 uses mep-id { 1781 description 1782 "Only applicable if the destination is a 1783 Maintenance End Point (MEP)."; 1784 } 1785 description 1786 "Destination Maintenance End Point (MEP)."; 1787 } 1788 leaf count { 1789 type uint32; 1790 default "1"; 1791 description 1792 "Number of traceroute probes to send. In protocols where a 1793 separate message is sent at each TTL, this is the number 1794 of packets to be sent at each TTL."; 1795 } 1796 leaf interval { 1797 type time-interval; 1798 description 1799 "Time interval between echo requests."; 1800 } 1801 } 1802 output { 1803 list response { 1804 key "response-index"; 1805 leaf response-index { 1806 type uint8; 1807 description 1808 "Arbitrary index for the response. In protocols that 1809 guarantee there is only a single response at each TTL, 1810 the TTL can be used as the response index."; 1811 } 1812 uses time-to-live; 1813 container destination-mep { 1814 description 1815 "Maintenance End Point (MEP) from 1816 which the response has been received"; 1817 uses mep-address; 1818 uses mep-id { 1819 description 1820 "Only applicable if the destination is a 1821 Maintenance End Point (MEP)."; 1822 } 1823 } 1824 container mip { 1825 if-feature "mip"; 1826 leaf interface { 1827 type if:interface-ref; 1828 description 1829 "Maintenance Intermediate Point (MIP) interface."; 1830 } 1831 uses mip-address; 1832 description 1833 "Maintenance Intermediate Point (MIP) 1834 responding with traceroute"; 1835 } 1836 uses monitor-stats { 1837 description 1838 "Stats of traceroute."; 1839 } 1840 description 1841 "List of response."; 1842 } 1843 } 1844 } 1845 } 1847 1849 6. Base Mode 1851 The Base Mode ('default mode' described in section 4) defines default 1852 configuration that MUST be present in the devices that comply with 1853 this document. Base Mode allows users to have "zero-touch" 1854 experience. Several parameters require technology specific 1855 definition. 1857 6.1. MEP Address 1859 In the Base Mode of operation, the MEP Address is by default the IP 1860 address of the interface on which the MEP is located. 1862 6.2. MEP ID for Base Mode 1864 In the Base Mode of operation, each device creates a single MEP 1865 associated with a virtual OAM port with no physical layer (NULL PHY). 1866 The MEP-ID associated with this MEP is zero (0). The choice of MEP- 1867 ID zero is explained below. 1869 MEP-ID is 2 octet field by default. It is never used on the wire 1870 except when using CCM. It is important to have method that can 1871 derive MEP-ID of base mode in an automatic manner with no user 1872 intervention. IP address cannot be directly used for this purpose as 1873 the MEP-ID is much smaller field. For Base Mode of operation we 1874 propose to use MEP-ID zero (0) as the default MEP-ID. 1876 CCM packet use MEP-ID on the payload. CCM MUST NOT be used in the 1877 Base Mode. Hence CCM MUST be disabled on the Maintenance Association 1878 of the Base Mode. 1880 If CCM is required, users MUST configure a separate Maintenance 1881 association and assign unique value for the corresponding MEP IDs. 1883 CFM [IEEE802.1ag] defines MEP ID as an unsigned integer in the range 1884 1 to 8191. In this document we propose extend the range to 0 to 1885 65535. Value 0 is reserved for MEP-ID of Base Mode operation and 1886 MUST NOT be used for other purposes. 1888 6.3. Maintenance Association 1890 The ID of the Maintenance Association (MA-ID) [IEEE802.1ag] has a 1891 flexible format and includes two parts: Maintenance Domain Name and 1892 Short MA name. In the Based Mode of operation, the value of the 1893 Maintenance Domain Name must be the character string 1894 "GenericBaseMode" (excluding the quotes "). In Base Mode operation 1895 Short MA Name format is set to 2-octet integer format (value 3 in 1896 Short MA Format field [IEEE802.1ag]) and Short MA name set to 65532 1897 (0xFFFC). 1899 7. Connection-oriented OAM YANG model applicability 1901 "ietf-connection-oriented-oam" model defined in this document 1902 provides technology-independent abstraction of key OAM constructs for 1903 connection oriented protocols. This model can be further extended to 1904 include technology specific details, e.g., adding new data nodes with 1905 technology specific functions and parameters into proper anchor 1906 points of the base model, so as to develop a technology-specific 1907 connection-oriented OAM model. 1909 This section demonstrates the usability of the connection-oriented 1910 YANG OAM data model to various connection-oriented OAM technologies, 1911 e.g., TRILL and MPLS-TP. Note that, in this section, we only present 1912 several snippets of technology-specific model extensions for 1913 illustrative purposes. The complete model extensions should be 1914 worked on in respective protocol working groups. 1916 7.1. Generic YANG Model extension for TRILL OAM 1918 The TRILL YANG module is augmenting connection oriented OAM module 1919 for both configuration and RPC commands. 1921 The TRILL YANG module requires the base TRILL module ([I-D.ietf- 1922 trill-yang]) to be supported as there is a strong relationship 1923 between those modules. 1925 The configuration extensions for connection oriented OAM include MD 1926 configuration extension, Technology type extension, MA configuration 1927 extension, Connectivity-Context Extension, MEP Configuration 1928 Extension, ECMP extension. In the RPC extension, the continuity- 1929 check and path-discovery RPC are extended with TRILL specific. 1931 7.1.1. MD Configuration Extension 1933 MD level configuration parameters are management information which 1934 can be inherited in the TRILL OAM model and set by connection 1935 oriented base model as default values. For example domain name can 1936 be set to area-ID in the TRILL OAM case. In addition, at the 1937 Maintenance Domain level (i.e., at root level), domain data node can 1938 be augmented with technology type. 1940 Note that MD level configuration parameters provides context 1941 information for the management system to correlate faults, defects, 1942 network failures with location information, which helps quickly 1943 identify root causes of network failures. 1945 7.1.1.1. Technology Type Extension 1947 No TRILL technology type has been defined in the connection oriented 1948 base model. Therefore a technology type extension is required in the 1949 TRILL OAM model. The technology type "trill" is defined as an 1950 identity that augments the base "technology-types" defined in the 1951 connection oriented base model: 1953 identity trill{ 1954 base co-oam:technology-types; 1955 description 1956 "trill type"; 1957 } 1959 7.1.2. MA Configuration Extension 1961 MA level configuration parameters are management information which 1962 can be inherited in the TRILL OAM model and set by connection 1963 oriented base model as default values. In addition, at the 1964 Maintenance Association(MA) level (i.e.,at the second level), MA data 1965 node can be augmented with connectivity-context extension. 1967 Note that MA level configuration parameters provides context 1968 information for the management system to correlate faults, defects, 1969 network failures with location information, which helps quickly 1970 identify root causes of network failures. 1972 7.1.2.1. Connectivity-Context Extension 1974 In TRILL OAM, one example of connectivity-context is either a 12 bit 1975 VLAN ID or a 24 bit Fine Grain Label. The connection oriented base 1976 model defines a placeholder for context-id. This allows other 1977 technologies to easily augment that to include technology specific 1978 extensions. The snippet below depicts an example of augmenting 1979 connectivity-context to include either VLAN ID or Fine Grain Label. 1981 augment /co-oam:domains/co-oam:domain 1982 /co-oam:mas/co-oam:ma/co-oam:connectivity-context: 1983 +--:(connectivity-context-vlan) 1984 | +--rw connectivity-context-vlan? vlan 1985 +--:(connectivity-context-fgl) 1986 +--rw connectivity-context-fgl? fgl 1988 7.1.3. MEP Configuration Extension 1990 The MEP configuration definition in the connection oriented base 1991 model already supports configuring the interface of MEP with either 1992 MAC address or IP address. In addition, the MEP address can be 1993 represented using a 2 octet RBridge Nickname in TRILL OAM . Hence, 1994 the TRILL OAM model augments the MEP configuration in base model to 1995 add a nickname case into the MEP address choice node as follows: 1997 augment /co-oam:domains/co-oam:domain 1998 /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:mep-address: 1999 +--:( mep-address-trill) 2000 | +--rw mep-address-trill? tril-rb-nickname 2002 In addition, at the Maintenance Association Endpoint(MEP) level 2003 (i.e.,at the third level), MEP data node can be augmented with ECMP 2004 extension. 2006 7.1.3.1. ECMP Extension 2008 Since TRILL supports ECMP path selection, flow-entropy in TRILL is 2009 defined as a 96 octet field in the LIME model extension for TRILL 2010 OAM. The snippet below illustrates its extension. 2012 augment /co-oam:domains/co-oam:domain 2013 /co-oam:mas/co-oam:ma/co-oam:mep: 2014 +--rw flow-entropy-trill? flow-entropy-trill 2015 augment /co-oam:domains/co-oam:domain 2016 /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session: 2017 +--rw flow-entropy-trill? flow-entropy-trill 2019 7.1.4. RPC extension 2021 In the TRILL OAM YANG model, the continuity-check and path-discovery 2022 RPC commands are extended with TRILL specific requirements. The 2023 snippet below depicts an example of illustrates the TRILL OAM RPC 2024 extension. 2026 augment /co-oam:continuity-check/co-oam:input: 2027 +--ro (out-of-band)? 2028 | +--:(ipv4-address) 2029 | | +--ro ipv4-address? inet:ipv4-address 2030 | +--:(ipv6-address) 2031 | | +--ro ipv6-address? inet:ipv6-address 2032 | +--:(trill-nickname) 2033 | +--ro trill-nickname? tril-rb-nickname 2034 +--ro diagnostic-vlan? boolean 2035 augment /co-oam:continuity-check/co-oam:input: 2036 +--ro flow-entropy-trill? flow-entropy-trill 2037 augment /co-oam:continuity-check/co-oam:output: 2038 +--ro upstream-rbridge? tril-rb-nickname 2039 +--ro next-hop-rbridge* tril-rb-nickname 2040 augment /co-oam:path-discovery/co-oam:input: 2041 +--ro (out-of-band)? 2042 | +--:(ipv4-address) 2043 | | +--ro ipv4-address? inet:ipv4-address 2044 | +--:(ipv6-address) 2045 | | +--ro ipv6-address? inet:ipv6-address 2046 | +--:(trill-nickname) 2047 | +--ro trill-nickname? tril-rb-nickname 2048 +--ro diagnostic-vlan? boolean 2049 augment /co-oam:path-discovery/co-oam:input: 2050 +--ro flow-entropy-trill? flow-entropy-trill 2051 augment /co-oam:path-discovery/co-oam:output/co-oam:response: 2052 +--ro upstream-rbridge? tril-rb-nickname 2053 +--ro next-hop-rbridge* tril-rb-nickname 2055 7.2. Generic YANG Model extension for MPLS-TP OAM 2057 The MPLS-TP OAM YANG module can augment connection oriented OAM 2058 Module with some technology-specific details. And the 2059 [mpls-tp-oam-yang] presents the YANG Data model for MPLS-TP OAM. 2061 The configuration extensions for connection oriented OAM include MD 2062 configuration extension, Technology type extension, Sub Technology 2063 Type Extension, MA configuration extension, MEP Configuration 2064 Extension. 2066 7.2.1. MD Configuration Extension 2068 MD level configuration parameters are management information which 2069 can be inherited in the MPLS-TP OAM model and set by LIME base model 2070 as default values. For example domain name can be set to area-ID or 2071 the provider's Autonomous System Number(ASN) [RFC6370] in the MPLS-TP 2072 OAM case. In addition, at the Maintenance Domain level (i.e.,at root 2073 level), domain data node can be augmented with technology type and 2074 sub-technology type. 2076 Note that MD level configuration parameters provides context 2077 information for the management system to correlate faults, defects, 2078 network failures with location information, which helps quickly 2079 identify root causes of network failures 2081 7.2.1.1. Technology Type Extension 2083 No MPLS-TP technology type has been defined in the connection 2084 oriented base model, hence it is required in the MPLS-TP OAM model. 2085 The technology type "mpls-tp" is defined as an identity that augments 2086 the base "technology-types" defined in the connection oriented base 2087 model: 2089 identity mpls-tp{ 2090 base co-oam:technology-types; 2091 description 2092 "mpls-tp type"; 2093 } 2095 7.2.1.2. Sub Technology Type Extension 2097 In MPLS-TP, since different encapsulation types such as IP/UDP 2098 Encapsulation, PW-ACH encapsulation can be employed, the "technology- 2099 sub-type" data node is defined and added into the MPLS-TP OAM model 2100 to further identify the encapsulation types within the MPLS-TP OAM 2101 model. Based on it, we also define a technology sub-type for IP/UDP 2102 encapsulation and PW-ACH encapsulation. Other Encapsulation types 2103 can be defined in the same way. The snippet below depicts an example 2104 of several encapsulation types. 2106 identity technology-sub-type { 2107 description 2108 "certain implementations can have different 2109 encapsulation types such as ip/udp, pw-ach and so on. 2110 Instead of defining separate models for each 2111 encapsulation, we define a technology sub-type to 2112 further identify different encapsulations. 2113 Technology sub-type is associated at the MA level"; } 2115 identity technology-sub-type-udp { 2116 base technology-sub-type; 2117 description 2118 "technology sub-type is IP/UDP encapsulation"; 2119 } 2121 identity technology-sub-type-ach { 2122 base technology-sub-type; 2123 description 2124 "technology sub-type is PW-ACH encapsulation"; 2125 } 2126 } 2128 augment "/co-oam:domains/co-oam:domain" 2129 +"/co-oam:mas/co-oam:ma { 2130 leaf technology-sub-type { 2131 type identityref { 2132 base technology-sub-type; 2133 } 2134 } 2135 } 2137 7.2.2. MA Configuration Extension 2139 MA level configuration parameters are management information which 2140 can be inherited in the MPLS-TP OAM model and set by Connection 2141 Oriented base model as default values. One example of MA Name could 2142 be MEG LSP ID or MEG Section ID or MEG PW ID[RFC6370]. 2144 Note that MA level configuration parameters provides context 2145 information for the management system to correlate faults, defects, 2146 network failures with location information, which helps quickly 2147 identify root causes of network failures. 2149 7.2.3. MEP Configuration Extension 2151 In MPLS-TP, MEP-ID is either a variable length label value in case of 2152 G-ACH encapsulation or a 2 octet unsigned integer value in case of 2153 IP/UDP encapsulation. One example of MEP-ID is MPLS-TP LSP_MEP_ID 2155 [RFC6370]. In the connection-oriented base model, MEP-ID is defined 2156 as a choice/case node which can supports an int32 value, and the same 2157 definition can be used for MPLS-TP with no further modification. In 2158 addition, at the Maintenance Association Endpoint(MEP) level (i.e.,at 2159 the third level), MEP data node can be augmented with Session 2160 extension and interface extension. 2162 8. Security Considerations 2164 The YANG module specified in this document defines a schema for data 2165 that is designed to be accessed via network management protocols such 2166 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 2167 is the secure transport layer, and the mandatory-to-implement secure 2168 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 2169 is HTTPS, and the mandatory-to-implement secure transport is TLS 2170 [RFC5246]. 2172 The NETCONF access control model [RFC6536] provides the means to 2173 restrict access for particular NETCONF or RESTCONF users to a 2174 preconfigured subset of all available NETCONF or RESTCONF protocol 2175 operations and content. 2177 There are a number of data nodes defined in the YANG module which are 2178 writable/creatable/deletable (i.e., config true, which is the 2179 default). These data nodes may be considered sensitive or vulnerable 2180 in some network environments. Write operations (e.g., ) 2181 to these data nodes without proper protection can have a negative 2182 effect on network operations. These are the subtrees and data nodes 2183 and their sensitivity/vulnerability: 2185 /co-oam:domains/co-oam:domain/ 2187 /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma 2189 /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep 2191 /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/ 2192 co-oam:session 2194 Unauthorized access to any of these lists can adversely affect OAM 2195 management system handling of end-to-end OAM and coordination of OAM 2196 within underlying network layers This may lead to inconsistent 2197 configuration, reporting, and presentation for the OAM mechanisms 2198 used to manage the network. 2200 9. IANA Considerations 2202 This document registers a URI in the IETF XML registry [RFC3688] 2203 [RFC3688]. Following the format in RFC 3688, the following 2204 registration is requested to be made: 2206 URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam 2208 Registrant Contact: The IESG. 2210 XML: N/A, the requested URI is an XML namespace. 2212 This document registers a YANG module in the YANG Module Names 2213 registry [RFC6020]. 2215 name: ietf-connection-oriented-oam 2216 namespace: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam 2217 prefix: co-oam 2218 reference: RFC XXXX 2220 10. Acknowledgments 2222 Giles Heron came up with the idea of developing a YANG model as a way 2223 of creating a unified OAM API set (interface), work in this document 2224 is largely an inspiration of that. Alexander Clemm provided many 2225 valuable tips, comments and remarks that helped to refine the YANG 2226 model presented in this document. 2228 Carlos Pignataro, David Ball,Mahesh Jethanandani,Benoit 2229 Claise,Ladislav Lhotka,GUBALLA JENS,Yuji Tochio,Gregory Mirsky, Huub 2230 van Helvoort, Tom Taylor, Dapeng Liu,Mishael Wexler, Adi Molkho 2231 participated and contributed to this document. 2233 11. References 2235 11.1. Normative References 2237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2238 Requirement Levels", BCP 14, RFC 2119, 2239 DOI 10.17487/RFC2119, March 1997, 2240 . 2242 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2243 DOI 10.17487/RFC3688, January 2004, 2244 . 2246 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2247 (TLS) Protocol Version 1.2", RFC 5246, 2248 DOI 10.17487/RFC5246, August 2008, 2249 . 2251 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2252 the Network Configuration Protocol (NETCONF)", RFC 6020, 2253 DOI 10.17487/RFC6020, October 2010, 2254 . 2256 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2257 and A. Bierman, Ed., "Network Configuration Protocol 2258 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2259 . 2261 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2262 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2263 . 2265 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 2266 Profile (MPLS-TP) Identifiers", RFC 6370, 2267 DOI 10.17487/RFC6370, September 2011, 2268 . 2270 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2271 Protocol (NETCONF) Access Control Model", RFC 6536, 2272 DOI 10.17487/RFC6536, March 2012, 2273 . 2275 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2276 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2277 . 2279 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2280 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2281 May 2017, . 2283 11.2. Informative References 2285 [G.800] "Unified functional architecture of transport networks", 2286 ITU-T Recommendation G.800, 2016. 2288 [G.8013] "OAM functions and mechanisms for Ethernet based 2289 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 2291 [I-D.ietf-lime-yang-connectionless-oam] 2292 Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, 2293 "Generic YANG Data Model for the Management of Operations, 2294 Administration, and Maintenance (OAM) Protocols that use 2295 Connectionless Communications", draft-ietf-lime-yang- 2296 connectionless-oam-18 (work in progress), November 2017. 2298 [I-D.ietf-netmod-revised-datastores] 2299 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2300 and R. Wilton, "Network Management Datastore 2301 Architecture", draft-ietf-netmod-revised-datastores-07 2302 (work in progress), November 2017. 2304 [I-D.ietf-netmod-yang-tree-diagrams] 2305 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 2306 ietf-netmod-yang-tree-diagrams-02 (work in progress), 2307 October 2017. 2309 [IEEE802.1ag] 2310 "Connectivity Fault Management", IEEE Std 802.1ag-2011, 2311 August 2011. 2313 [mpls-tp-oam-yang] 2314 Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, "YANG 2315 Data Model for MPLS-TP Operations, Administration, and 2316 Maintenance", draft-zhang-mpls-tp-yang-oam (work in 2317 progress), 2016. 2319 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 2320 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 2321 Acronym in the IETF", BCP 161, RFC 6291, 2322 DOI 10.17487/RFC6291, June 2011, 2323 . 2325 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 2326 Ghanwani, "Routing Bridges (RBridges): Base Protocol 2327 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 2328 . 2330 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 2331 Administration, and Maintenance Framework for MPLS-Based 2332 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 2333 September 2011, . 2335 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 2336 3rd, "Transparent Interconnection of Lots of Links (TRILL) 2337 Operations, Administration, and Maintenance (OAM) 2338 Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, 2339 . 2341 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2342 Weingarten, "An Overview of Operations, Administration, 2343 and Maintenance (OAM) Tools", RFC 7276, 2344 DOI 10.17487/RFC7276, June 2014, 2345 . 2347 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 2348 3rd, D., Aldrin, S., and Y. Li, "Transparent 2349 Interconnection of Lots of Links (TRILL): Fault 2350 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 2351 . 2353 Appendix A. Contributors' Addresses 2355 Tissa Senevirathne 2356 Consultant 2358 Email: tsenevir@gmail.com 2360 Norman Finn 2361 CISCO Systems 2362 510 McCarthy Blvd 2363 Milpitas, CA 95035 2364 USA 2366 Email: nfinn@cisco.com 2368 Samer Salam 2369 CISCO Systems 2370 595 Burrard St. Suite 2123 2371 Vancouver, BC V7X 1J1 2372 Canada 2374 Email: ssalam@cisco.com 2376 Authors' Addresses 2377 Deepak Kumar 2378 CISCO Systems 2379 510 McCarthy Blvd 2380 Milpitas, CA 95035 2381 USA 2383 Email: dekumar@cisco.com 2385 Qin Wu 2386 Huawei 2387 101 Software Avenue, Yuhua District 2388 Nanjing, Jiangsu 210012 2389 China 2391 Email: bill.wu@huawei.com 2393 Michael Wang 2394 Huawei Technologies,Co.,Ltd 2395 101 Software Avenue, Yuhua District 2396 Nanjing 210012 2397 China 2399 Email: wangzitao@huawei.com