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