idnits 2.17.1 draft-ietf-lime-yang-oam-model-09.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 (March 6, 2017) is 2608 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 598, 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: September 7, 2017 M. Wang 6 Huawei 7 March 6, 2017 9 Generic YANG Data Model for Connection Oriented Operations, 10 Administration, and Maintenance(OAM) protocols 11 draft-ietf-lime-yang-oam-model-09 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 September 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 41 71 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 41 72 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 41 73 6.3. Maintenance Association . . . . . . . . . . . . . . . . . 42 74 7. Connection-oriented OAM YANG model applicability . . . . . . 42 75 7.1. Generic YANG Model extension for TRILL OAM . . . . . . . 43 76 7.1.1. MD Configuration Extension . . . . . . . . . . . . . 43 77 7.1.2. MA Configuration Extension . . . . . . . . . . . . . 43 78 7.1.3. MEP Configuration Extension . . . . . . . . . . . . . 44 79 7.1.4. RPC extension . . . . . . . . . . . . . . . . . . . . 45 80 7.2. Generic YANG Model extension for MPLS-TP OAM . . . . . . 45 81 7.2.1. MD Configuration Extension . . . . . . . . . . . . . 46 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 3. Architecture of Generic YANG Model for OAM 253 In this document we define a generic YANG model for connection 254 oriented OAM protocols. The YANG model defined here is generic in a 255 sense that other technologies can extend it for technology specific 256 needs. The Generic YANG model acts as the root for other OAM YANG 257 models. This allows users to traverse between different OAM 258 protocols with ease through a uniform API set. This also enables a 259 nested OAM workflow. Figure 1 depicts the relationship of different 260 OAM YANG models to the Generic YANG Model for connection oriented 261 OAM. The Generic YANG model for OAM provides a framework where 262 technology- specific YANG models can inherit constructs from the base 263 YANG models without needing to redefine them within the sub- 264 technology. 266 Figure 1 depicts relationship of different YANG modules. 268 +----------+ 269 |Connection| 270 | Oriented | 271 | gen | 272 |OAM YANG | 273 +-+-+-+-+-++ 274 | 275 | 276 | 277 +------------------------------------------+ 278 | | | 279 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 280 | TRILL | | MPLS-TP | . . .| foo | 281 |OAM YANG | |OAM YANG | |OAM YANG | 282 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 283 | | | 284 | | +-+-+-+-+-+ 285 | | . . .| foo | 286 | | |sub tech | 287 | | +-+-+-+-+-+ 288 | | | 289 | | | 290 +-------------------------------------------------------+ 291 | Uniform API | 292 +-------------------------------------------------------+ 294 Relationship of OAM YANG model to generic (base) YANG model 296 4. Overview of the OAM Model 298 In this document we adopt the concepts of the CFM [IEEE802.1ag] model 299 and structure it such that it can be adapted to different connection 300 oriented OAM protocols. 302 At the top of the Model is the Maintenance Domain. Each Maintenance 303 Domain is associated with a Maintenance Name and a Domain Level. 305 Under each Maintenance Domain there is one or more Maintenance 306 Association (MA). In TRILL this can be per Fine-Grained Label or for 307 VPLS this can be per VPLS instance [RFC6136]. 309 Under each MA, there can be two or more MEPs (Maintenance End 310 Points). MEPs are addressed by their respective technology specific 311 address identifiers. The YANG model presented here provides 312 flexibility to accommodate different addressing schemes. 314 In the vertical direction orthogonal to the Maintenance Domain, 315 presented are the commands. Those, in YANG terms, are the RPC 316 commands. These RPC commands provide uniform APIs for continuity 317 check, connectivity verification, path discovery(traceroute) and 318 their equivalents as well as other OAM commands. 320 The OAM entities in the generic YANG model defined here will be 321 either explicitly or implicitly configured using any of the OAM 322 tools. The OAM tools used here are limited to OAM toolset specified 323 in section 5.1 of [RFC7276]. In order to facilitate zero-touch 324 experience, this document defines a default mode of OAM. The default 325 mode of OAM is referred to as the Base Mode and specifies default 326 values for each of model parameters, such as Maintenance Domain 327 Level, Name of the Maintenance Association, Addresses of MEPs and so 328 on. The default values of these depend on the technology. Base Mode 329 for TRILL is defined in [RFC7455]. Base mode for other technologies 330 and future extensions developed in IETF will be defined in their 331 corresponding documents. 333 It is important to note that, no specific enhancements are needed in 334 the YANG model to support Base Mode. Implementations that comply 335 with this document, by default implement the data nodes of the 336 applicable technology. Data nodes of the Base Mode are read-only 337 nodes. 339 4.1. Maintenance Domain (MD) configuration 341 The container "domains" is the top level container within the gen-oam 342 module. Within the container "domains", separate list is maintained 343 per MD. The MD list uses the key MD-name-string for indexing. MD- 344 name-string is a leaf and derived from type string. Additional name 345 formats as defined in [IEEE802.1ag] or other standards can be 346 included by association of the MD-name-format with an identity-ref. 347 MD-name-format indicates the format of the augmented MD-names. MD- 348 name is presented as choice/case construct. Thus, it is easily 349 augmentable by derivative work. 351 module: ietf-conn-oam 352 +--rw domains 353 +--rw domain* [technology MD-name-string] 354 +--rw technology identityref 355 +--rw MD-name-string MD-name-string 356 +--rw MD-name-format? identityref 357 +--rw (MD-name)? 358 | +--:(MD-name-null) 359 | +--rw MD-name-null? empty 360 +--rw md-level? MD-level 362 Snippet of data hierarchy related to OAM domains 364 4.2. Maintenance Association (MA) configuration 366 Within a given Maintenance Domain there can be one or more 367 Maintenance Associations (MA). MAs are represented as a list and 368 indexed by the MA-name-string. Similar to MD-name defined 369 previously, additional name formats can be added by augmenting the 370 name-format identity-ref and adding applicable case statements to MA- 371 name. 373 module: ietf-conn-oam 374 +--rw domains 375 +--rw domain* [technology MD-name-string] 376 . 377 . 378 +--rw MAs 379 +--rw MA* [MA-name-string] 380 +--rw MA-name-string MA-name-string 381 +--rw MA-name-format? identityref 382 +--rw (MA-name)? 383 | +--:(MA-name-null) 384 | +--rw MA-name-null? empty 386 Snippet of data hierarchy related to Maintenance Associations (MA) 388 4.3. Maintenance Endpoint (MEP) configuration 390 Within a given Maintenance Association (MA), there can be one or more 391 Maintenance End Points (MEP). MEPs are represented as a list within 392 the data hierarchy and indexed by the key MEP-name. 394 module: ietf-conn-oam 395 +--rw domains 396 +--rw domain* [technology MD-name-string] 397 +--rw technology identityref 398 . 399 . 400 +--rw MAs 401 +--rw MA* [MA-name-string] 402 +--rw MA-name-string MA-name-string 403 . 404 . 405 +--rw MEP* [mep-name] 406 | +--rw mep-name MEP-name 407 | +--rw (MEP-ID)? 408 | | +--:(MEP-ID-int) 409 | | +--rw MEP-ID-int? int32 410 | +--rw MEP-ID-format? identityref 411 | +--rw (mep-address)? 412 | | +--:(mac-address) 413 | | | +--rw mac-address? yang:mac-address 414 | | +--:(ipv4-address) 415 | | | +--rw ipv4-address? inet:ipv4-address 416 | | +--:(ipv6-address) 417 | | +--rw ipv6-address? inet:ipv6-address 418 . . 419 . . 420 . . 422 Snippet of data hierarchy related to Maintenance Endpoint (MEP) 424 4.4. RPC definitions 426 The RPC model facilitates issuing commands to a NETCONF server (in 427 this case to the device that need to execute the OAM command) and 428 obtain a response. RPC model defined here abstracts OAM specific 429 commands in a technology independent manner. 431 There are several RPC commands defined for the purpose of OAM. In 432 this section we present a snippet of the continuity check command for 433 illustration purposes. Please refer to Section 4.5 for the complete 434 data hierarchy and Section 5 for the YANG model. 436 module: ietf-conn-oam 437 +--rw domains 438 +--rw domain* [technology MD-name-string] 439 +--rw technology identityref 440 . 441 . 443 rpcs: 444 +---x continuity-check {continuity-check}? 445 | +---w input 446 | | +---w technology? identityref 447 | | +---w MD-name-string -> /domains/domain/MD-name-string 448 | | +---w MA-name-string -> /domains/domain/MAs/MA/MA-name-string 449 | | +---w cos-id? uint8 450 | | +---w (ttl)? 451 | | | +--:(ip-ttl) 452 | | | | +---w ip-ttl? uint8 453 | | | +--:(mpls-ttl) 454 | | | +---w mpls-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 | | | | +--:(ipv4-address) 462 | | | | | +---w ipv4-address? inet:ipv4-address 463 | | | | +--:(ipv6-address) 464 | | | | +---w ipv6-address? inet:ipv6-address 465 | | | +---w (MEP-ID)? 466 | | | | +--:(MEP-ID-int) 467 | | | | +---w MEP-ID-int? int32 468 | | | +---w MEP-ID-format? identityref 469 | | +---w count? uint32 470 | | +---w cc-transmit-interval? Interval 471 | | +---w packet-size? uint32 472 | +--ro output 473 | +--ro (monitor-stats)? 474 | +--:(monitor-null) 475 | +--ro monitor-null? empty 476 +---x continuity-verification {connectivity-verification}? 477 | +---w input 478 | | +---w MD-name-string ->/domains/domain/MD-name-string 479 | | +---w MA-name-string ->/domains/domain/MAs/MA/MA-name-string 480 | | +---w cos-id? uint8 481 | | +---w (ttl)? 482 | | | +--:(ip-ttl) 483 | | | | +---w ip-ttl? uint8 484 | | | +--:(mpls-ttl) 485 | | | +---w mpls-ttl? uint8 486 | | +---w sub-type? identityref 487 | | +---w source-mep? -> /domains/domain/MAs/MA/MEP/mep-name 488 | | +---w destination-mep 489 | | | +---w (mep-address)? 490 | | | | +--:(mac-address) 491 | | | | | +---w mac-address? yang:mac-address 492 | | | | +--:(ipv4-address) 493 | | | | | +---w ipv4-address? inet:ipv4-address 494 | | | | +--:(ipv6-address) 495 | | | | +---w ipv6-address? inet:ipv6-address 496 | | | +---w (MEP-ID)? 497 | | | | +--:(MEP-ID-int) 498 | | | | +---w MEP-ID-int? int32 499 | | | +---w MEP-ID-format? identityref 500 | | +---w count? uint32 501 | | +---w interval? Interval 502 | | +---w packet-size? uint32 503 | +--ro output 504 | +--ro (monitor-stats)? 505 | +--:(monitor-null) 506 | +--ro monitor-null? empty 507 +---x traceroute {traceroute}? 508 +---w input 509 | +---w MD-name-string -> /domains/domain/MD-name-string 510 | +---w MA-name-string -> /domains/domain/MAs/MA/MA-name-string 511 | +---w cos-id? uint8 512 | +---w (ttl)? 513 | | +--:(ip-ttl) 514 | | | +---w ip-ttl? uint8 515 | | +--:(mpls-ttl) 516 | | +---w mpls-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)? 537 | +--:(ip-ttl) 538 | | +--ro ip-ttl? uint8 539 | +--:(mpls-ttl) 540 | +--ro mpls-ttl? uint8 541 +--ro destination-mep 542 | +--ro (mep-address)? 543 | | +--:(mac-address) 544 | | | +--ro mac-address? yang:mac-address 545 | | +--:(ipv4-address) 546 | | | +--ro ipv4-address? inet:ipv4-address 547 | | +--:(ipv6-address) 548 | | +--ro ipv6-address? inet:ipv6-address 549 | +--ro (MEP-ID)? 550 | | +--:(MEP-ID-int) 551 | | +--ro MEP-ID-int? int32 552 | +--ro MEP-ID-format? identityref 553 +--ro mip {mip}? 554 | +--ro interface? if:interface-ref 555 | +--ro (mip-address)? 556 | +--:(mac-address) 557 | | +--ro mac-address? yang:mac-address 558 | +--:(ipv4-address) 559 | | +--ro ipv4-address? inet:ipv4-address 560 | +--:(ipv6-address) 561 | +--ro ipv6-address? inet:ipv6-address 562 +--ro (monitor-stats)? 563 +--:(monitor-null) 564 +--ro monitor-null? empty 566 Snippet of data hierarchy related to RPC call continuity-check 568 4.5. Notifications 570 Notification is sent on defect condition and defect clears with 571 Maintenance Domain Name, MA Name, defect-type (The currently active 572 defects), generating-mepid, and defect-message to indicate more 573 details. 575 4.6. Monitor statistics 577 Grouping for monitoring statistics is to be used by Yang modules 578 which Augment Yang to provide statistics due to pro-active OAM like 579 CCM Messages. For example CCM Transmit, CCM Receive, CCM Errors, 580 etc. 582 4.7. OAM data hierarchy 584 The complete data hierarchy related to the connection oriented OAM 585 YANG model is presented below. 587 module: ietf-conn-oam 588 +--rw domains 589 +--rw domain* [technology MD-name-string] 590 +--rw technology identityref 591 +--rw MD-name-string MD-name-string 592 +--rw MD-name-format? identityref 593 +--rw (MD-name)? 594 | +--:(MD-name-null) 595 | +--rw MD-name-null? empty 596 +--rw md-level? MD-level 597 +--rw MAs 598 +--rw MA* [MA-name-string] 599 +--rw MA-name-string MA-name-string 600 +--rw MA-name-format? identityref 601 +--rw (MA-name)? 602 | +--:(MA-name-null) 603 | +--rw MA-name-null? empty 604 +--rw (connectivity-context)? 605 | +--:(context-null) 606 | +--rw context-null? empty 607 +--rw cos-id? uint8 608 +--rw cc-enable? boolean 609 +--rw MEP* [mep-name] 610 | +--rw mep-name MEP-name 611 | +--rw (MEP-ID)? 612 | | +--:(MEP-ID-int) 613 | | +--rw MEP-ID-int? int32 614 | +--rw MEP-ID-format? identityref 615 | +--rw (mep-address)? 616 | | +--:(mac-address) 617 | | | +--rw mac-address? yang:mac-address 618 | | +--:(ipv4-address) 619 | | | +--rw ipv4-address? inet:ipv4-address 620 | | +--:(ipv6-address) 621 | | +--rw ipv6-address? inet:ipv6-address 622 | +--rw cos-id? uint8 623 | +--rw cc-enable? boolean 624 | +--rw session* [session-cookie] 625 | +--rw session-cookie uint32 626 | +--rw destination-mep 627 | | +--rw (MEP-ID)? 628 | | | +--:(MEP-ID-int) 629 | | | +--rw MEP-ID-int? int32 630 | | +--rw MEP-ID-format? identityref 631 | +--rw destination-mep-address 632 | | +--rw (mep-address)? 633 | | +--:(mac-address) 634 | | | +--rw mac-address? yang:mac-address 635 | | +--:(ipv4-address) 636 | | | +--rw ipv4-address? inet:ipv4-address 637 | | +--:(ipv6-address) 638 | | +--rw ipv6-address? inet:ipv6-address 639 | +--rw cos-id? uint8 640 +--rw MIP* [interface] {mip}? 641 +--rw interface if:interface-ref 642 +--rw (mip-address)? 643 | +--:(mac-address) 644 | | +--rw mac-address? yang:mac-address 645 | +--:(ipv4-address) 646 | | +--rw ipv4-address? inet:ipv4-address 647 | +--:(ipv6-address) 648 | +--rw ipv6-address? inet:ipv6-address 649 +--rw level? MD-level 651 rpcs: 652 +---x continuity-check {continuity-check}? 653 | +---w input 654 | | +---w technology? identityref 655 | | +---w MD-name-string -> /domains/domain/MD-name-string 656 | | +---w MA-name-string -> /domains/domain/MAs/MA/MA-name-string 657 | | +---w cos-id? uint8 658 | | +---w (ttl)? 659 | | | +--:(ip-ttl) 660 | | | | +---w ip-ttl? uint8 661 | | | +--:(mpls-ttl) 662 | | | +---w mpls-ttl? uint8 663 | | +---w sub-type? identityref 664 | | +---w source-mep? -> /domains/domain/MAs/MA/MEP/mep-name 665 | | +---w destination-mep 666 | | | +---w (mep-address)? 667 | | | | +--:(mac-address) 668 | | | | | +---w mac-address? yang:mac-address 669 | | | | +--:(ipv4-address) 670 | | | | | +---w ipv4-address? inet:ipv4-address 671 | | | | +--:(ipv6-address) 672 | | | | +---w ipv6-address? inet:ipv6-address 673 | | | +---w (MEP-ID)? 674 | | | | +--:(MEP-ID-int) 675 | | | | +---w MEP-ID-int? int32 676 | | | +---w MEP-ID-format? identityref 677 | | +---w count? uint32 678 | | +---w cc-transmit-interval? Interval 679 | | +---w packet-size? uint32 680 | +--ro output 681 | +--ro (monitor-stats)? 682 | +--:(monitor-null) 683 | +--ro monitor-null? empty 684 +---x continuity-verification {connectivity-verification}? 685 | +---w input 686 | | +---w MD-name-string -> /domains/domain/MD-name-string 687 | | +---w MA-name-string -> /domains/domain/MAs/MA/MA-name-string 688 | | +---w cos-id? uint8 689 | | +---w (ttl)? 690 | | | +--:(ip-ttl) 691 | | | | +---w ip-ttl? uint8 692 | | | +--:(mpls-ttl) 693 | | | +---w mpls-ttl? uint8 694 | | +---w sub-type? identityref 695 | | +---w source-mep? -> /domains/domain/MAs/MA/MEP/mep-name 696 | | +---w destination-mep 697 | | | +---w (mep-address)? 698 | | | | +--:(mac-address) 699 | | | | | +---w mac-address? yang:mac-address 700 | | | | +--:(ipv4-address) 701 | | | | | +---w ipv4-address? inet:ipv4-address 702 | | | | +--:(ipv6-address) 703 | | | | +---w ipv6-address? inet:ipv6-address 704 | | | +---w (MEP-ID)? 705 | | | | +--:(MEP-ID-int) 706 | | | | +---w MEP-ID-int? int32 707 | | | +---w MEP-ID-format? identityref 708 | | +---w count? uint32 709 | | +---w interval? Interval 710 | | +---w packet-size? uint32 711 | +--ro output 712 | +--ro (monitor-stats)? 713 | +--:(monitor-null) 714 | +--ro monitor-null? empty 715 +---x traceroute {traceroute}? 716 +---w input 717 | +---w MD-name-string -> /domains/domain/MD-name-string 718 | +---w MA-name-string -> /domains/domain/MAs/MA/MA-name-string 719 | +---w cos-id? uint8 720 | +---w (ttl)? 721 | | +--:(ip-ttl) 722 | | | +---w ip-ttl? uint8 723 | | +--:(mpls-ttl) 724 | | +---w mpls-ttl? uint8 725 | +---w command-sub-type? identityref 726 | +---w source-mep? -> /domains/domain/MAs/MA/MEP/mep-name 727 | +---w destination-mep 728 | | +---w (mep-address)? 729 | | | +--:(mac-address) 730 | | | | +---w mac-address? yang:mac-address 731 | | | +--:(ipv4-address) 732 | | | | +---w ipv4-address? inet:ipv4-address 733 | | | +--:(ipv6-address) 734 | | | +---w ipv6-address? inet:ipv6-address 735 | | +---w (MEP-ID)? 736 | | | +--:(MEP-ID-int) 737 | | | +---w MEP-ID-int? int32 738 | | +---w MEP-ID-format? identityref 739 | +---w count? uint32 740 | +---w interval? Interval 741 +--ro output 742 +--ro response* [response-index] 743 +--ro response-index uint8 744 +--ro (ttl)? 745 | +--:(ip-ttl) 746 | | +--ro ip-ttl? uint8 747 | +--:(mpls-ttl) 748 | +--ro mpls-ttl? uint8 749 +--ro destination-mep 750 | +--ro (mep-address)? 751 | | +--:(mac-address) 752 | | | +--ro mac-address? yang:mac-address 753 | | +--:(ipv4-address) 754 | | | +--ro ipv4-address? inet:ipv4-address 755 | | +--:(ipv6-address) 756 | | +--ro ipv6-address? inet:ipv6-address 757 | +--ro (MEP-ID)? 758 | | +--:(MEP-ID-int) 759 | | +--ro MEP-ID-int? int32 760 | +--ro MEP-ID-format? identityref 761 +--ro mip {mip}? 762 | +--ro interface? if:interface-ref 763 | +--ro (mip-address)? 764 | +--:(mac-address) 765 | | +--ro mac-address? yang:mac-address 766 | +--:(ipv4-address) 767 | | +--ro ipv4-address? inet:ipv4-address 768 | +--:(ipv6-address) 769 | +--ro ipv6-address? inet:ipv6-address 770 +--ro (monitor-stats)? 771 +--:(monitor-null) 772 +--ro monitor-null? empty 774 notifications: 775 +---n defect-condition-notification 776 | +--ro technology? identityref 777 | +--ro MD-name-string -> /domains/domain/MD-name-string 778 | +--ro MA-name-string -> /domains/domain/MAs/MA/MA-name-string 779 | +--ro mep-name? -> /domains/domain/MAs/MA/MEP/mep-name 780 | +--ro defect-type? identityref 781 | +--ro generating-mepid 782 | | +--ro (MEP-ID)? 783 | | | +--:(MEP-ID-int) 784 | | | +--ro MEP-ID-int? int32 785 | | +--ro MEP-ID-format? identityref 786 | +--ro (defect)? 787 | +--:(defect-null) 788 | | +--ro defect-null? empty 789 | +--:(defect-code) 790 | +--ro defect-code? int32 791 +---n defect-cleared-notification 792 +--ro technology? identityref 793 +--ro MD-name-string -> /domains/domain/MD-name-string 794 +--ro MA-name-string -> /domains/domain/MAs/MA/MA-name-string 795 +--ro mep-name? -> /domains/domain/MAs/MA/MEP/mep-name 796 +--ro defect-type? identityref 797 +--ro generating-mepid 798 | +--ro (MEP-ID)? 799 | | +--:(MEP-ID-int) 800 | | +--ro MEP-ID-int? int32 801 | +--ro MEP-ID-format? identityref 802 +--ro (defect)? 803 +--:(defect-null) 804 | +--ro defect-null? empty 805 +--:(defect-code) 806 +--ro defect-code? int32 808 data hierarchy of OAM 810 5. OAM YANG Module 812 file "ietf-conn-oam.yang" 814 module ietf-conn-oam { 815 namespace "urn:ietf:params:xml:ns:yang:ietf-conn-oam"; 816 prefix goam; 818 import ietf-yang-types { 819 prefix yang; 820 } 821 import ietf-inet-types { 822 prefix inet; 823 } 824 import ietf-interfaces { 825 prefix if; 826 } 827 organization "IETF LIME Working Group"; 828 contact 829 "WG Web: http://tools.ietf.org/wg/lime 830 WG List: mailto:lime@ietf.org 831 WG Chair: Carlos Pignataro cpignata@cisco.com 832 WG Chair: Ron Bonica rbonica@juniper.net 833 Editor: Deepak Kumar dekumar@cisco.com 834 Editor: Qin Wu bill.wu@huawei.com 835 Editor: Zitao Wang wangzitao@huawei.com"; 836 description 837 "This YANG module defines the generic configuration, 838 statistics and rpc for connection oriented OAM 839 to be used within IETF in a protocol indpendent manner. 840 Functional level abstraction is indendent 841 with YANG modeling. It is assumed that each protocol 842 maps corresponding abstracts to its native format. 843 Each protocol may extend the YANG model defined 844 here to include protocol specific extensions"; 846 revision 2017-02-10 { 847 description 848 "Initial revision. - 07 version"; 850 reference "draft-ietf-lime-yang-oam-model"; 851 } 853 /* features */ 854 feature connectivity-verification { 855 description 856 "This feature indicates that the server supports 857 executing connectivity verification OAM command and 858 returning a response. Servers that do not advertise 859 this feature will not support executing 860 connectivity verification command or rpc model for 861 connectivity verification command."; 862 } 863 feature continuity-check{ 864 description 865 "This feature indicates that the server supports 866 executing continuity check OAM command and 867 returning a response. Servers that do not advertise 868 this feature will not support executing 869 continuity check command or rpc model for 870 continuity check command."; 871 } 873 feature traceroute{ 874 description 875 "This feature indicates that the server supports 876 executing traceroute OAM command and 877 returning a response. Servers that do not advertise 878 this feature will not support executing 879 traceroute command or rpc model for 880 traceroute command."; 881 } 882 feature mip { 883 description 884 "This feature indicates that the MIP (Maintenance Intermediate Point) 885 need to 886 be explicit configured"; 887 } 888 /* Identities */ 890 identity technology-types { 891 description 892 "This is the base identy of technology types which are 893 TRILL,MPLS-TP,vpls etc"; 894 } 896 identity command-sub-type { 897 description 898 "Defines different rpc command subtypes, 899 e.g rfc6905 trill OAM, this is optional for most cases"; 900 } 902 identity on-demand { 903 base command-sub-type; 904 description 905 "On demand activation - indicates that the tool is activated 906 manually to detect a specific anomaly."; 907 } 909 identity proactive { 910 base command-sub-type; 911 description 912 "Proactive activation - indicates that the tool is activated on a 913 continual basis, where messages are sent periodically, and errors 914 are detected when a certain number of expected messages are not 915 received."; 916 } 918 identity name-format { 920 description 921 "This defines the name format, IEEE 8021ag CFM defines varying 922 styles of names. It is expected name format as an identity ref 923 to be extended with new types."; 924 } 926 identity name-format-null { 927 base name-format; 928 description 929 "Defines name format as null"; 930 } 932 identity identifier-format { 933 description 934 "Identifier-format identity can be augmented to define other 935 format identifiers used in MEP-ID etc"; 936 } 938 identity identifier-format-integer { 939 base identifier-format; 940 description 941 "Defines identifier-format to be integer"; 943 } 945 identity defect-types { 946 description 947 "Defines different defect types, e.g. remote rdi, 948 mis-connection defect, loss of continuity"; 949 } 950 identity rdi { 951 base defect-types; 952 description 953 "Indicates the aggregate health of the remote MEPs. "; 954 } 956 identity remote-mep-defect{ 957 base defect-types; 958 description 959 "Indicates that one or more of the remote MEPs is 960 reporting a failure "; 961 } 963 identity loss-of-continuity{ 964 base defect-types; 965 description 966 "If no proactive CC OAM packets from the source 967 MEP (and in the case of CV, this includes the 968 requirement to have the expected globally unique 969 Source MEP identifier) are received within the interval. "; 970 } 972 identity invalid-oam-defect{ 973 base defect-types; 974 description 975 "Indicates that one or more invalid OAM messages has been 976 received and that 3.5 times that OAM message transmission 977 interval has not yet expired."; 978 } 980 identity cross-connect-defect{ 981 base defect-types; 982 description 983 "Indicates that one or more cross-connect defect 984 (for example, a service ID does not match the VLAN.) 985 messages has been received and that 3.5 times that OAM message 986 transmission interval has not yet expired."; 987 } 989 /* typedefs */ 991 typedef MEP-name { 992 type string; 993 description 994 "Generic administrative name for a MEP"; 995 } 997 typedef Interval{ 998 type decimal64{ 999 fraction-digits 2; 1000 } 1001 units "milliseconds"; 1002 description 1003 "Interval between packets in milliseconds. 1004 0 means no packets are sent."; 1005 } 1007 typedef MD-name-string { 1008 type string; 1009 description 1010 "Generic administrative name for an MD"; 1011 } 1013 typedef MA-name-string { 1014 type string; 1015 description 1016 "Generic administrative name for an MA"; 1017 } 1019 typedef oam-counter32 { 1020 type yang:zero-based-counter32; 1021 description 1022 "Defines 32 bit counter for OAM"; 1023 } 1025 typedef MD-level { 1026 type uint32 { 1028 range "0..255"; 1029 } 1030 description 1031 "Maintenance Domain level. The level may be restricted in 1032 certain protocols (eg to 0-7)"; 1033 } 1035 /* groupings */ 1037 grouping maintenance-domain-reference { 1038 description 1039 "This grouping uniquely identifies a maintenance domain."; 1041 leaf maintenance-domain { 1042 type leafref { 1043 path "/goam:domains/goam:domain/goam:MD-name-string"; 1044 } 1045 description 1046 "A reference to a specific Maintenance Domain."; 1047 } 1048 } 1050 grouping maintenance-association-reference { 1051 description 1052 "This grouping uniquely identifies a 1053 maintenance association. It consists 1054 of a maintence-domain-reference and 1055 a maintenance-association leafref"; 1056 uses maintenance-domain-reference; 1057 leaf maintenance-association { 1058 type leafref { 1059 path "/goam:domains/goam:domain" 1060 +"[goam:MD-name-string = current()/" 1061 +"../maintenance-domain]/goam:MAs" 1062 +"/goam:MA/goam:MA-name-string"; 1063 } 1064 description 1065 "A reference to a specific Maintenance Association."; 1066 } 1067 } 1068 grouping maintenance-association-end-point-reference { 1069 description 1070 "This grouping uniquely identifies 1071 a maintenance association. It consists 1072 of a maintence-association-reference and 1073 a maintenance-association-end-point leafref"; 1074 uses maintenance-association-reference; 1075 leaf maintenance-association-end-point { 1076 type leafref { 1077 path "/goam:domains/goam:domain" 1078 +"[goam:MD-name-string = current()/" 1079 +"../maintenance-domain]/goam:MAs" 1080 +"/goam:MA[goam:MA-name-string = " 1081 +"current()/../maintenance-association]" 1082 +"/goam:MEP/goam:mep-name"; 1083 } 1084 description 1085 "A reference to a specific Maintenance 1086 association End Point."; 1087 } 1088 } 1090 grouping time-to-live { 1091 choice ttl{ 1092 case ip-ttl{ 1093 leaf ip-ttl{ 1094 type uint8; 1095 default "255"; 1096 description 1097 "Time to live"; 1098 } 1099 } 1100 case mpls-ttl{ 1101 leaf mpls-ttl{ 1103 type uint8; 1104 description 1105 "Time to live. When an IP packet is imposed with a label, 1106 the IP TTL value is first decremented then copied into 1107 the MPLS TTL. As each LSR the MPLS frame's TTL is 1108 decremented.This behavior can be modified with no 1109 mpls ip ttl. When a MPLS label is popped, the MPLS 1110 TTL value is decremented then copied in the IP TTL 1111 field. If the MPLS TTL value is great than IP TTL, 1112 that values is not copied over. This is to prevent 1113 a possible condition of forwarding loop and TTL 1114 never reaching 0. When two MPLS labels are swapped, 1115 decrement by 1 and copy over the result into the new label. 1117 When a new MPLS labels is pushed, decrement by 1 and copy 1118 over the result into the new label. When a new MPLS labels 1119 is popped, decrement by 1 and copy over the result into 1120 the label below.[RFC3443]"; 1122 } 1123 } 1124 description 1125 "Time to Live."; 1126 } 1127 description 1128 "Time to Live grouping."; 1129 } 1130 grouping defect-message { 1131 choice defect { 1132 case defect-null { 1133 description 1135 "This is a placeholder when no defect status is needed"; 1136 leaf defect-null { 1137 type empty; 1138 description 1139 "there is no defect define, it will be defined in 1140 technology specific model."; 1141 } 1142 } 1143 case defect-code { 1144 description 1145 "This is a placeholder to display defect code."; 1146 leaf defect-code { 1147 type int32; 1148 description 1149 "Defect code is integer value specific to technology."; 1150 } 1151 } 1153 description 1154 "Defect Message choices."; 1155 } 1157 description 1158 "Defect Message."; 1159 } 1161 grouping mep-address { 1162 choice mep-address { 1163 case mac-address { 1164 leaf mac-address { 1165 type yang:mac-address; 1166 description 1167 "MAC Address"; 1168 } 1169 description 1170 "MAC Address based MEP Addressing."; 1171 } 1172 case ipv4-address { 1173 leaf ipv4-address { 1174 type inet:ipv4-address; 1175 description 1176 "IPv4 Address"; 1177 } 1178 description 1179 "IP Address based MEP Addressing."; 1180 } 1181 case ipv6-address { 1182 leaf ipv6-address { 1183 type inet:ipv6-address; 1184 description 1185 "IPv6 Address"; 1186 } 1187 description 1188 "IPv6 Address based MEP Addressing."; 1189 } 1190 description 1191 "MEP Addressing."; 1192 } 1193 description 1194 "MEP Address"; 1195 } 1196 grouping mip-address { 1197 choice mip-address { 1198 case mac-address { 1199 leaf mac-address { 1200 type yang:mac-address; 1201 description 1202 "MAC Address"; 1203 } 1204 description 1205 "MAC Address based MIP Addressing."; 1206 } 1207 case ipv4-address { 1208 leaf ipv4-address { 1209 type inet:ipv4-address; 1210 description 1211 "IPv4 Address"; 1212 } 1214 description 1215 "IP Address based MIP Addressing."; 1216 } 1217 case ipv6-address { 1218 leaf ipv6-address { 1219 type inet:ipv6-address; 1220 description 1221 "IPv6 Address"; 1222 } 1223 description 1224 "IPv6 Address based MIP Addressing."; 1225 } 1226 description 1227 "MIP Addressing."; 1228 } 1229 description 1230 "MIP Address"; 1231 } 1232 grouping maintenance-domain-id { 1233 description 1234 "Grouping containing leaves sufficient to identify an MD"; 1235 leaf technology { 1237 type identityref { 1238 base technology-types; 1239 } 1240 mandatory true; 1242 description 1243 "Defines the technology"; 1244 } 1245 leaf MD-name-string { 1246 type MD-name-string; 1247 mandatory true; 1248 description 1249 "Defines the generic administrative maintenance domain name"; 1250 } 1251 } 1253 grouping MD-name { 1254 leaf MD-name-format { 1255 type identityref { 1256 base name-format; 1257 } 1258 description 1259 "Name format."; 1260 } 1261 choice MD-name { 1262 case MD-name-null { 1263 leaf MD-name-null { 1264 when "'../../../MD-name-format' = 'name-format-null'" { 1265 description 1266 "MD name format is equal to null format."; 1267 } 1268 type empty; 1269 description 1270 "MD name Null."; 1271 } 1272 } 1273 description 1274 "MD name."; 1275 } 1276 description 1277 "MD name"; 1278 } 1280 grouping ma-identifier { 1281 description 1282 "Grouping containing leaves sufficient to identify an MA"; 1283 leaf MA-name-string { 1284 type MA-name-string; 1286 description 1288 "MA name string."; 1289 } 1290 } 1292 grouping MA-name { 1293 description 1294 "MA name"; 1295 leaf MA-name-format { 1296 type identityref { 1297 base name-format; 1298 } 1299 description 1300 "Ma name format"; 1301 } 1302 choice MA-name { 1303 case MA-name-null { 1304 leaf MA-name-null { 1305 when "'../../../MA-name-format' = 'name-format-null'" { 1306 description 1307 "MA"; 1308 } 1309 type empty; 1310 description 1311 "Empty"; 1312 } 1313 } 1314 description 1315 "MA name"; 1316 } 1317 } 1319 grouping MEP-ID { 1320 choice MEP-ID { 1321 default "MEP-ID-int"; 1322 case MEP-ID-int { 1323 leaf MEP-ID-int { 1324 type int32; 1325 description 1326 "MEP ID in integer format"; 1327 } 1328 } 1329 description 1330 "MEP-ID"; 1331 } 1333 leaf MEP-ID-format { 1335 type identityref { 1336 base identifier-format; 1337 } 1338 description 1339 "MEP ID format."; 1340 } 1341 description 1342 "MEP-ID"; 1343 } 1345 grouping MEP { 1346 description 1347 "Defines elements within the MEP"; 1348 leaf mep-name { 1349 type MEP-name; 1350 mandatory true; 1351 description 1352 "Generic administrative name of the MEP"; 1353 } 1354 uses MEP-ID; 1355 uses mep-address; 1356 } 1358 grouping monitor-stats { 1359 description 1360 "grouping for monitoring statistics, this will be augmented 1361 by others who use this component"; 1362 choice monitor-stats { 1364 default "monitor-null"; 1365 case monitor-null { 1366 description 1367 "This is a place holder when 1368 no monitoring statistics is needed"; 1369 leaf monitor-null { 1370 type empty; 1371 description 1372 "There is no monitoring statistics to be defined"; 1373 } 1374 } 1375 description 1376 "Define the monitor stats"; 1377 } 1378 } 1380 grouping connectivity-context { 1381 description 1382 "Grouping defining the connectivity context for an MA; for 1383 example, a VRF for VPLS, or an LSP for MPLS-TP. This will be 1384 augmented by each protocol who use this component"; 1385 choice connectivity-context { 1386 default "context-null"; 1387 case context-null { 1388 description 1389 "This is a place holder when no context is needed"; 1390 leaf context-null { 1391 type empty; 1392 description 1393 "There is no context define"; 1394 } 1395 } 1396 description 1397 "Connectivity context"; 1398 } 1399 } 1400 grouping cos { 1401 description 1403 "Priority used in transmitted packets; for example, in the 1404 EXP field in MPLS-TP."; 1406 leaf cos-id { 1407 type uint8; 1408 description 1409 "Class of service"; 1410 } 1411 } 1412 grouping MIP-grouping { 1413 uses mip-address; 1414 leaf level { 1415 type MD-level; 1416 description 1417 "Configure a level of maintenance intermediate point (MIP) 1418 for the interface. The MIP level range is 0 to 7."; 1419 } 1420 description 1421 "Grouping for MIP configuration"; 1422 } 1424 container domains { 1425 description 1426 "Contains configuration related data. Within the container 1427 is list of fault domains. Wihin each domian has List of MA."; 1428 list domain { 1429 key "technology MD-name-string"; 1431 ordered-by system; 1432 description 1434 "Define the list of Domains within the IETF-OAM"; 1435 uses maintenance-domain-id; 1436 uses MD-name; 1437 leaf md-level { 1438 type MD-level; 1439 description 1440 "Defines the MD-Level"; 1441 } 1442 container MAs { 1443 description 1444 "This container defines MA, within that have multiple MA 1445 and within MA have MEP"; 1446 list MA { 1447 key "MA-name-string"; 1448 ordered-by system; 1449 uses ma-identifier; 1450 uses MA-name; 1451 uses connectivity-context; 1452 uses cos { 1453 description 1454 "Default class of service for this MA, 1455 which may be overridden 1456 for particular MEPs, 1457 sessions or operations."; 1458 } 1459 leaf cc-enable{ 1460 type boolean; 1461 description 1462 "Indicate whether the CC enable."; 1463 } 1464 list MEP { 1465 key "mep-name"; 1467 ordered-by system; 1468 description 1469 "Contain list of MEPS"; 1470 uses MEP; 1471 uses cos; 1472 leaf cc-enable{ 1473 type boolean; 1474 description 1475 "Indicate whether the CC enable."; 1476 } 1477 list session { 1478 key "session-cookie"; 1479 ordered-by user; 1480 description 1481 "Monitoring session to/from a particular remote MEP. 1482 Depending on the protocol, this could represent CC 1483 messages received from a single remote MEP (if the 1484 protocol uses multicast CCs) or a target to which 1485 unicast echo request CCs are sent and from which 1486 responses are received (if the protocol uses a 1487 unicast request/response mechanism)."; 1488 leaf session-cookie { 1489 type uint32; 1490 description 1491 "Cookie to identify different sessions, when there 1492 are multiple remote MEPs or multiple sessions to 1493 the same remote MEP."; 1494 } 1495 container destination-mep { 1496 uses MEP-ID; 1497 description 1498 "Destination MEP"; 1499 } 1500 container destination-mep-address { 1501 uses mep-address; 1502 description 1503 "Destination MEP Address"; 1504 } 1505 uses cos; 1506 } 1507 } 1508 list MIP { 1509 if-feature mip; 1510 key "interface"; 1511 leaf interface { 1512 type if:interface-ref; 1513 description 1514 "Interface"; 1515 } 1516 uses MIP-grouping; 1517 description 1518 "List for MIP"; 1519 } 1521 description 1522 "Maintenance Association list"; 1523 } 1524 } 1525 } 1527 } 1529 notification defect-condition-notification { 1530 description 1531 "When defect condition is met this notification is sent"; 1532 leaf technology { 1533 type identityref { 1534 base technology-types; 1535 } 1536 description 1537 "The technology"; 1538 } 1539 leaf MD-name-string { 1540 type leafref{ 1541 path "/domains/domain/MD-name-string"; 1542 } 1543 mandatory true; 1544 description 1545 "Indicate which MD is seeing the defect"; 1546 } 1547 leaf MA-name-string{ 1548 type leafref{ 1549 path "/domains/domain/MAs/MA/MA-name-string"; 1551 } 1552 mandatory true; 1553 description 1554 "Indicate which MA is seeing the defect"; 1555 } 1556 leaf mep-name { 1557 type leafref{ 1558 path "/domains/domain/MAs/MA/MEP/mep-name"; 1559 } 1560 description 1561 "Indicate which MEP is seeing the defect"; 1562 } 1563 leaf defect-type { 1564 type identityref { 1565 base defect-types; 1566 } 1567 description 1569 "The currently active defects on the specific MEP."; 1570 } 1571 container generating-mepid { 1573 uses MEP-ID; 1574 description 1575 "Who is generating the defect (if known) if 1576 unknown make it 0."; 1577 } 1578 uses defect-message { 1579 description 1580 "Defect message to indicate more details."; 1581 } 1582 } 1584 notification defect-cleared-notification { 1585 description 1586 "When defect cleared is met this notification is sent"; 1587 leaf technology { 1588 type identityref { 1589 base technology-types; 1590 } 1591 description 1592 "The technology"; 1593 } 1594 leaf MD-name-string { 1595 type leafref{ 1596 path "/domains/domain/MD-name-string"; 1597 } 1598 mandatory true; 1599 description 1600 "Indicate which MD is seeing the defect"; 1601 } 1602 leaf MA-name-string{ 1603 type leafref{ 1604 path "/domains/domain/MAs/MA/MA-name-string"; 1605 } 1606 mandatory true; 1607 description 1608 "Indicate which MA is seeing the defect"; 1609 } 1610 leaf mep-name { 1611 type leafref{ 1612 path "/domains/domain/MAs/MA/MEP/mep-name"; 1613 } 1614 description 1615 "Indicate which MEP is seeing the defect"; 1616 } 1618 leaf defect-type { 1619 type identityref { 1620 base defect-types; 1622 } 1623 description 1625 "The currently active defects on the specific MEP."; 1626 } 1627 container generating-mepid { 1628 uses MEP-ID; 1629 description 1630 "Who is generating the defect (if known) if 1631 unknown make it 0."; 1632 } 1633 uses defect-message { 1634 description 1635 "Defect message to indicate more details."; 1636 } 1637 } 1639 rpc continuity-check { 1640 if-feature "continuity-check"; 1641 description 1642 "Generates continuity-check as per RFC7276 Table 4."; 1643 input { 1644 leaf technology { 1645 type identityref { 1646 base technology-types; 1648 } 1649 description 1650 "The technology"; 1651 } 1652 leaf MD-name-string { 1653 type leafref{ 1654 path "/domains/domain/MD-name-string"; 1655 } 1656 mandatory true; 1657 description 1658 "Indicate which MD is seeing the defect"; 1659 } 1660 leaf MA-name-string{ 1661 type leafref{ 1662 path "/domains/domain/MAs/MA/MA-name-string"; 1663 } 1664 mandatory true; 1665 description 1666 "Indicate which MA is seeing the defect"; 1667 } 1668 uses cos; 1669 uses time-to-live; 1670 leaf sub-type { 1672 type identityref { 1673 base command-sub-type; 1674 } 1675 description 1676 "Defines different command types"; 1677 } 1678 leaf source-mep { 1679 type leafref{ 1680 path "/domains/domain/MAs/MA/MEP/mep-name"; 1681 } 1682 description 1683 "Source MEP"; 1684 } 1685 container destination-mep { 1686 uses mep-address; 1687 uses MEP-ID { 1688 description 1689 "Only applicable if the destination is a MEP"; 1690 } 1691 description 1692 "Destination MEP"; 1694 } 1695 leaf count { 1696 type uint32; 1697 default "3"; 1698 description 1699 "Number of continuity-check message to send"; 1700 } 1701 leaf cc-transmit-interval { 1702 type Interval; 1703 description 1705 "Interval between echo requests"; 1706 } 1707 leaf packet-size { 1708 type uint32 { 1709 range "0..10000"; 1710 } 1711 default "64"; 1712 description 1713 "Size of continuity-check packets, in octets"; 1714 } 1715 } 1716 output { 1717 uses monitor-stats { 1718 description 1719 "Stats of continuity check."; 1720 } 1722 } 1723 } 1725 rpc continuity-verification { 1726 if-feature connectivity-verification; 1727 description 1728 "Generates continuity-verification as per RFC7276 Table 4."; 1729 input { 1730 leaf MD-name-string { 1731 type leafref{ 1732 path "/domains/domain/MD-name-string"; 1733 } 1734 mandatory true; 1735 description 1736 "Indicate which MD is seeing the defect"; 1737 } 1738 leaf MA-name-string{ 1739 type leafref{ 1740 path "/domains/domain/MAs/MA/MA-name-string"; 1741 } 1742 mandatory true; 1743 description 1744 "Indicate which MA is seeing the defect"; 1745 } 1746 uses cos; 1747 uses time-to-live; 1748 leaf sub-type { 1750 type identityref { 1751 base command-sub-type; 1752 } 1753 description 1754 "Defines different command types"; 1755 } 1756 leaf source-mep { 1757 type leafref{ 1758 path "/domains/domain/MAs/MA/MEP/mep-name"; 1759 } 1760 description 1761 "Source MEP"; 1762 } 1763 container destination-mep { 1764 uses mep-address; 1765 uses MEP-ID { 1766 description "Only applicable if the destination is a MEP"; 1767 } 1768 description 1769 "Destination MEP"; 1771 } 1772 leaf count { 1773 type uint32; 1774 default "3"; 1775 description 1776 "Number of continuity-verification message to send"; 1777 } 1778 leaf interval { 1779 type Interval; 1780 description 1781 "Interval between echo requests"; 1782 } 1783 leaf packet-size { 1784 type uint32 { 1785 range "64..10000"; 1786 } 1787 default "64"; 1788 description 1789 "Size of continuity-verification packets, in octets"; 1790 } 1791 } 1792 output { 1793 uses monitor-stats { 1794 description 1795 "Stats of continuity check."; 1796 } 1797 } 1798 } 1799 rpc traceroute { 1800 if-feature traceroute; 1801 description 1802 "Generates Traceroute or Path Trace and return response. 1803 Referencing RFC7276 for common Toolset name, for 1804 MPLS-TP OAM it's Route Tracing, and for TRILL OAM It's 1805 Path Tracing tool. Starts with TTL of one and increment 1806 by one at each hop. Untill destination reached or TTL 1807 reach max value"; 1808 input { 1809 leaf MD-name-string { 1810 type leafref{ 1811 path "/domains/domain/MD-name-string"; 1812 } 1813 mandatory true; 1814 description 1815 "Indicate which MD is seeing the defect"; 1816 } 1817 leaf MA-name-string{ 1818 type leafref{ 1820 path "/domains/domain/MAs/MA/MA-name-string"; 1821 } 1822 mandatory true; 1823 description 1824 "Indicate which MA is seeing the defect"; 1825 } 1826 uses cos; 1827 uses time-to-live; 1828 leaf command-sub-type { 1829 type identityref { 1831 base command-sub-type; 1832 } 1833 description 1834 "Defines different command types"; 1835 } 1836 leaf source-mep { 1837 type leafref{ 1838 path "/domains/domain/MAs/MA/MEP/mep-name"; 1839 } 1841 description 1842 "Source MEP"; 1843 } 1844 container destination-mep { 1845 uses mep-address; 1846 uses MEP-ID { 1847 description 1848 "Only applicable if the destination is a MEP"; 1849 } 1850 description 1851 "Destination MEP"; 1852 } 1853 leaf count { 1854 type uint32; 1855 default "1"; 1856 description 1857 "Number of traceroute probes to send. In protocols where a 1858 separate message is sent at each TTL, this is the number 1859 of packets to send at each TTL."; 1860 } 1861 leaf interval { 1862 type Interval; 1863 description 1864 "Interval between echo requests"; 1865 } 1866 } 1867 output { 1868 list response { 1869 key "response-index"; 1871 leaf response-index { 1872 type uint8; 1873 description 1874 "Arbitrary index for the response. In protocols that 1875 guarantee there is only a single response at each TTL 1876 , the TTL can be used as the response 1877 index."; 1878 } 1879 uses time-to-live; 1880 container destination-mep { 1881 description "MEP from which the response has been received"; 1882 uses mep-address; 1883 uses MEP-ID { 1884 description 1885 "Only applicable if the destination is a MEP"; 1886 } 1887 } 1888 container mip { 1889 if-feature mip; 1890 leaf interface { 1891 type if:interface-ref; 1892 description 1893 "MIP interface"; 1894 } 1895 uses mip-address; 1896 description 1897 "MIP responding with traceroute"; 1898 } 1899 uses monitor-stats { 1900 description 1901 "Stats of traceroute."; 1902 } 1903 description 1904 "List of response."; 1905 } 1906 } 1907 } 1908 } 1910 1912 6. Base Mode 1914 The Base Mode ('default mode' described in section 4) defines default 1915 configuration that MUST be present in the devices that comply with 1916 this document. Base Mode allows users to have "zero-touch" 1917 experience. Several parameters require technology specific 1918 definition. 1920 6.1. MEP Address 1922 In the Base Mode of operation, the MEP Address is by default the IP 1923 address of the interface on which the MEP is located. 1925 6.2. MEP ID for Base Mode 1927 In the Base Mode of operation, each device creates a single UP MEP 1928 associated with a virtual OAM port with no physical layer (NULL PHY). 1929 The MEP-ID associated with this MEP is zero (0). The choice of MEP- 1930 ID zero is explained below. 1932 MEP-ID is 2 octet field by default. It is never used on the wire 1933 except when using CCM. It is important to have method that can 1934 derive MEP-ID of base mode in an automatic manner with no user 1935 intervention. IP address cannot be directly used for this purpose as 1936 the MEP-ID is much smaller field. For Base Mode of operation we 1937 propose to use MEP-ID zero (0) as the default MEP-ID. 1939 CCM packet use MEP-ID on the payload. CCM MUST NOT be used in the 1940 Base Mode. Hence CCM MUST be disabled on the Maintenance Association 1941 of the Base Mode. 1943 If CCM is required, users MUST configure a separate Maintenance 1944 association and assign unique value for the corresponding MEP IDs. 1946 CFM [IEEE802.1ag] defines MEP ID as an unsigned integer in the range 1947 1 to 8191. In this document we propose extend the range to 0 to 1948 65535. Value 0 is reserved for MEP-ID of Base Mode operation and 1949 MUST NOT be used for other purposes. 1951 6.3. Maintenance Association 1953 The ID of the Maintenance Association (MA-ID) [IEEE802.1ag] has a 1954 flexible format and includes two parts: Maintenance Domain Name and 1955 Short MA name. In the Based Mode of operation, the value of the 1956 Maintenance Domain Name must be the character string 1957 "GenericBaseMode" (excluding the quotes "). In Base Mode operation 1958 Short MA Name format is set to 2-octet integer format (value 3 in 1959 Short MA Format field [IEEE802.1ag]) and Short MA name set to 65532 1960 (0xFFFC). 1962 7. Connection-oriented OAM YANG model applicability 1964 "ietf-conn-oam" model defined in this document provides technology- 1965 independent abstraction of key OAM constructs for connection oriented 1966 protocols. This model can be further extended to include technology 1967 specific details, e.g., adding new data nodes with technology 1968 specific functions and parameters into proper anchor points of the 1969 base model, so as to develop a technology-specific connection- 1970 oriented OAM model. 1972 This section demonstrates the usability of the connection-oriented 1973 YANG OAM data model to various connection-oriented OAM technologies, 1974 e.g., TRILL and MPLS-TP. Note that, in this section, we only present 1975 several snippets of technology-specific model extensions for 1976 illustrative purposes. The complete model extensions should be 1977 worked on in respective protocol working groups. 1979 7.1. Generic YANG Model extension for TRILL OAM 1981 The TRILL YANG module is augmenting connection oriented OAM module 1982 for both configuration and RPC commands. 1984 The TRILL YANG module requires the base TRILL module ([I-D.ietf- 1985 trill-yang]) to be supported as there is a strong relationship 1986 between those modules. 1988 The configuration extensions for connection oriented OAM include MD 1989 configuration extension, Technology type extension, MA configuration 1990 extension, Connectivity-Context Extension, MEP Configuration 1991 Extension, ECMP extension. In the RPC extension, the continuity- 1992 check and path-discovery RPC are extended with TRILL specific. 1994 7.1.1. MD Configuration Extension 1996 MD level configuration parameters are management information which 1997 can be inherited in the TRILL OAM model and set by connection 1998 oriented base model as default values. For example domain name can 1999 be set to area-ID in the TRILL OAM case. In addition, at the 2000 Maintenance Domain level, domain data node at root level can be 2001 augmented with technology type. 2003 Note that MD level configuration parameters provides context 2004 information for management system to correlate faults, defects, 2005 network failures with location information, which helps quickly 2006 identify root causes of network failures. 2008 7.1.1.1. Technology Type Extension 2010 No TRILL technology type has been defined in the connection oriented 2011 base model. Therefore a technology type extension is required in the 2012 TRILL OAM model. The technology type "trill" is defined as an 2013 identity that augments the base "technology-types" defined in the 2014 connection oriented base model: 2016 identity trill{ 2017 base goam:technology-types; 2018 description 2019 "trill type"; 2020 } 2022 7.1.2. MA Configuration Extension 2024 MA level configuration parameters are management information which 2025 can be inherited in the TRILL OAM model and set by connection 2026 oriented base model as default values. In addition, at the 2027 Maintenance Association(MA) level, MA data node at the second level 2028 can be augmented with connectivity-context extension. 2030 Note that MA level configuration parameters provides context 2031 information for management system to correlate faults, defects, 2032 network failures with location information, which helps quickly 2033 identify root causes of network failures. 2035 7.1.2.1. Connectivity-Context Extension 2037 In TRILL OAM, one example of connectivity-context is either a 12 bit 2038 VLAN ID or a 24 bit Fine Grain Label. The connection oriented base 2039 model defines a placeholder for context-id. This allows other 2040 technologies to easily augment that to include technology specific 2041 extensions. The snippet below depicts an example of augmenting 2042 connectivity-context to include either VLAN ID or Fine Grain Label. 2044 augment /goam:domains/goam:domain/goam:MAs 2045 /goam:MA /goam:connectivity-context: 2046 +--:(connectivity-context-vlan) 2047 | +--rw connectivity-context-vlan? vlan 2048 +--:(connectivity-context-fgl) 2049 +--rw connectivity-context-fgl? fgl 2051 7.1.3. MEP Configuration Extension 2053 The MEP configuration definition in the connection oriented base 2054 model already supports configuring the interface of MEP with either 2055 MAC address or IP address. In addition, the MEP address can be 2056 represented using a 2 octet RBridge Nickname in TRILL OAM . Hence, 2057 the TRILL OAM model augments the MEP configuration in base model to 2058 add a nickname case into the MEP address choice node as follows: 2060 augment /goam:domains/goam:domain/goam:MAs 2061 /goam:MA/ goam:MEP/goam:mep-address: 2062 +--:( mep-address-trill) 2063 | +--rw mep-address-trill? tril-rb-nickname 2065 In addition, at the Maintenance Association Endpoint(MEP) level, MEP 2066 data node at the third level can be augmented with ECMP extension. 2068 7.1.3.1. ECMP Extension 2070 Since TRILL supports ECMP path selection, flow-entropy in TRILL is 2071 defined as a 96 octet field in the LIME model extension for TRILL 2072 OAM. The snippet below illustrates its extension. 2074 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP: 2075 +--rw flow-entropy-trill? flow-entropy-trill 2076 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 2077 /goam:session: 2078 +--rw flow-entropy-trill? flow-entropy-trill 2080 7.1.4. RPC extension 2082 In the TRILL OAM YANG model, the continuity-check and path-discovery 2083 RPC commands are extended with TRILL specific requirements. The 2084 snippet below depicts an example of illustrates the TRILL OAM RPC 2085 extension. 2087 augment /goam:continuity-check/goam:input: 2088 +--ro (out-of-band)? 2089 | +--:(ipv4-address) 2090 | | +--ro ipv4-address? inet:ipv4-address 2091 | +--:(ipv6-address) 2092 | | +--ro ipv6-address? inet:ipv6-address 2093 | +--:(trill-nickname) 2094 | +--ro trill-nickname? tril-rb-nickname 2095 +--ro diagnostic-vlan? boolean 2096 augment /goam:continuity-check/goam:input: 2097 +--ro flow-entropy-trill? flow-entropy-trill 2098 augment /goam:continuity-check/goam:output: 2099 +--ro upstream-rbridge? tril-rb-nickname 2100 +--ro next-hop-rbridge* tril-rb-nickname 2101 augment /goam:path-discovery/goam:input: 2102 +--ro (out-of-band)? 2103 | +--:(ipv4-address) 2104 | | +--ro ipv4-address? inet:ipv4-address 2105 | +--:(ipv6-address) 2106 | | +--ro ipv6-address? inet:ipv6-address 2107 | +--:(trill-nickname) 2108 | +--ro trill-nickname? tril-rb-nickname 2109 +--ro diagnostic-vlan? boolean 2110 augment /goam:path-discovery/goam:input: 2111 +--ro flow-entropy-trill? flow-entropy-trill 2112 augment /goam:path-discovery/goam:output/goam:response: 2113 +--ro upstream-rbridge? tril-rb-nickname 2114 +--ro next-hop-rbridge* tril-rb-nickname 2116 7.2. Generic YANG Model extension for MPLS-TP OAM 2118 The MPLS-TP OAM YANG module can augment connection oriented OAM 2119 Module with some technology-specific details. And the 2120 [mpls-tp-oam-yang] presents the YANG Data model for MPLS-TP OAM. 2122 The configuration extensions for connection oriented OAM include MD 2123 configuration extension, Technology type extension, Sub Technology 2124 Type Extension ,MA configuration extension, MEP Configuration 2125 Extension. 2127 7.2.1. MD Configuration Extension 2129 MD level configuration parameters are management information which 2130 can be inherited in the MPLS-TP OAM model and set by LIME base model 2131 as default values. For example domain name can be set to area-ID or 2132 the provider's Autonomous System Number(ASN) [RFC6370] in the MPLS-TP 2133 OAM case. In addition, at the Maintenance Domain level, domain data 2134 node at root level can be augmented with technology type and sub- 2135 technology type. 2137 Note that MD level configuration parameters provides context 2138 information for management system to correlate faults, defects, 2139 network failures with location information, which helps quickly 2140 identify root causes of network failures 2142 7.2.1.1. Technology Type Extension 2144 No MPLS-TP technology type has been defined in the connection 2145 oriented base model, hence it is required in the MPLS OAM model. The 2146 technology type "mpls-tp" is defined as an identity that augments the 2147 base "technology-types" defined in the connection oriented base 2148 model: 2150 identity mpls-tp{ 2151 base goam:technology-types; 2152 description 2153 "mpls-tp type"; 2154 } 2156 7.2.1.2. Sub Technology Type Extension 2158 In MPLS-TP, since different encapsulation types such as IP/UDP 2159 Encapsulation, PW-ACH encapsulation can be employed, the "technology- 2160 sub-type" data node is defined and added into the MPLS OAM model to 2161 further identify the encapsulation types within the MPLS-TP OAM 2162 model. Based on it, we also define a technology sub-type for IP/UDP 2163 encapsulation and PW-ACH encapsulation. Other Encapsulation types 2164 can be defined in the same way. The snippet below depicts an example 2165 of several encapsulation types. 2167 identity technology-sub-type { 2168 description 2169 "certain implementations can have different 2170 encapsulation types such as ip/udp, pw-ach and so on. 2171 Instead of defining separate models for each 2172 encapsulation, we define a technology sub-type to 2173 further identify different encapsulations. 2174 Technology sub-type is associated at the MA level"; } 2176 identity technology-sub-type-udp { 2177 base technology-sub-type; 2178 description 2179 "technology sub-type is IP/UDP encapsulation"; 2180 } 2182 identity technology-sub-type-ach { 2183 base technology-sub-type; 2184 description 2185 "technology sub-type is PW-ACH encapsulation"; 2186 } 2187 } 2189 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { 2190 leaf technology-sub-type { 2191 type identityref { 2192 base technology-sub-type; 2193 } 2194 } 2195 } 2197 7.2.2. MA Configuration Extension 2199 MA level configuration parameters are management information which 2200 can be inherited in the MPLS-TP OAM model and set by Connection 2201 Oriented base model as default values. One example of MA Name could 2202 be MEG LSP ID or MEG Section ID or MEG PW ID[RFC6370]. 2204 Note that MA level configuration parameters provides context 2205 information for management system to correlate faults, defects, 2206 network failures with location information, which helps quickly 2207 identify root causes of network failures. 2209 7.2.3. MEP Configuration Extension 2211 In MPLS-TP, MEP-ID is either a variable length label value in case of 2212 G-ACH encapsulation or a 2 octet unsigned integer value in case of 2213 IP/UDP encapsulation. One example of MEP-ID is MPLS-TP LSP_MEP_ID 2214 [RFC6370]. In the connection-oriented base model, MEP-ID is defined 2215 as a choice/case node which can supports an int32 value, and the same 2216 definition can be used for MPLS-TP with no further modification. In 2217 addition, at the Maintenance Association Endpoint(MEP) level, MEP 2218 data node at the third level can be augmented with Session extension 2219 and interface extension. 2221 8. Security Considerations 2223 The YANG module defined in this memo is designed to be accessed via 2224 the NETCONF protocol [RFC6241] [RFC6241]. The lowest NETCONF layer 2225 is the secure transport layer and the mandatory-to-implement secure 2226 transport is SSH [RFC6242] [RFC6242]. The NETCONF access control 2227 model [RFC6536] [RFC6536] provides the means to restrict access for 2228 particular NETCONF users to a pre-configured subset of all available 2229 NETCONF protocol operations and content. 2231 There are a number of data nodes defined in the YANG module which are 2232 writable/creatable/deletable (i.e., config true, which is the 2233 default). These data nodes may be considered sensitive or vulnerable 2234 in some network environments. Write operations (e.g., ) 2235 to these data nodes without proper protection can have a negative 2236 effect on network operations. 2238 The vulnerable "config true" subtrees and data nodes are the 2239 following: 2241 /goam:domains/goam:domain/ 2243 /goam:domains/goam:domain/goam:MAs/goam:MA/ 2245 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 2247 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/ 2249 Unauthorized access to any of these lists can adversely affect OAM 2250 management system handling of end-to-end OAM and coordination of OAM 2251 within underlying network layers This may lead to inconsistent 2252 configuration, reporting, and presentation for the OAM mechanisms 2253 used to manage the network. 2255 9. IANA Considerations 2257 This document registers a URI in the IETF XML registry [RFC3688] 2258 [RFC3688]. Following the format in RFC 3688, the following 2259 registration is requested to be made: 2261 URI: urn:ietf:params:xml:ns:yang:ietf-gen-oam 2263 Registrant Contact: The IESG. 2265 XML: N/A, the requested URI is an XML namespace. 2267 This document registers a YANG module in the YANG Module Names 2268 registry [RFC6020]. 2270 name: ietf-gen-oam namespace: urn:ietf:params:xml:ns:yang:ietf-gen-oam 2271 prefix: goam reference: RFC XXXX 2273 10. Acknowledgments 2275 Giles Heron came up with the idea of developing a YANG model as a way 2276 of creating a unified OAM API set (interface), work in this document 2277 is largely an inspiration of that. Alexander Clemm provided many 2278 valuable tips, comments and remarks that helped to refine the YANG 2279 model presented in this document. 2281 Carlos Pignataro, David Ball,Mahesh Jethanandani,Benoit 2282 Claise,Ladislav Lhotka,GUBALLA JENS,Yuji Tochio,Gregory Mirsky, Huub 2283 van Helvoort, Tom Taylor, Dapeng Liu,Mishael Wexler, Adi Molkho 2284 participated and contributed to this document. 2286 11. References 2288 11.1. Normative References 2290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2291 Requirement Levels", BCP 14, RFC 2119, 2292 DOI 10.17487/RFC2119, March 1997, 2293 . 2295 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2296 DOI 10.17487/RFC3688, January 2004, 2297 . 2299 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2300 the Network Configuration Protocol (NETCONF)", RFC 6020, 2301 DOI 10.17487/RFC6020, October 2010, 2302 . 2304 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2305 and A. Bierman, Ed., "Network Configuration Protocol 2306 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2307 . 2309 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2310 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2311 . 2313 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 2314 Profile (MPLS-TP) Identifiers", RFC 6370, 2315 DOI 10.17487/RFC6370, September 2011, 2316 . 2318 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2319 Protocol (NETCONF) Access Control Model", RFC 6536, 2320 DOI 10.17487/RFC6536, March 2012, 2321 . 2323 11.2. Informative References 2325 [G.8013] "OAM functions and mechanisms for Ethernet based 2326 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 2328 [IEEE802.1ag] 2329 "Connectivity Fault Management", IEEE Std 802.1ag-2011, 2330 August 2011. 2332 [mpls-tp-oam-yang] 2333 Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, "YANG 2334 Data Model for MPLS-TP Operations, Administration, and 2335 Maintenance", draft-zhang-mpls-tp-yang-oam (work in 2336 progress), 2016. 2338 [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual 2339 Private Network (L2VPN) Operations, Administration, and 2340 Maintenance (OAM) Requirements and Framework", RFC 6136, 2341 DOI 10.17487/RFC6136, March 2011, 2342 . 2344 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 2345 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 2346 Acronym in the IETF", BCP 161, RFC 6291, 2347 DOI 10.17487/RFC6291, June 2011, 2348 . 2350 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 2351 Ghanwani, "Routing Bridges (RBridges): Base Protocol 2352 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 2353 . 2355 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 2356 Administration, and Maintenance Framework for MPLS-Based 2357 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 2358 September 2011, . 2360 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 2361 3rd, "Transparent Interconnection of Lots of Links (TRILL) 2362 Operations, Administration, and Maintenance (OAM) 2363 Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, 2364 . 2366 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2367 Weingarten, "An Overview of Operations, Administration, 2368 and Maintenance (OAM) Tools", RFC 7276, 2369 DOI 10.17487/RFC7276, June 2014, 2370 . 2372 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 2373 3rd, D., Aldrin, S., and Y. Li, "Transparent 2374 Interconnection of Lots of Links (TRILL): Fault 2375 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 2376 . 2378 Appendix A. Contributors' Addresses 2380 Tissa Senevirathne 2381 Consultant 2383 Email: tsenevir@gmail.com 2385 Norman Finn 2386 CISCO Systems 2387 510 McCarthy Blvd 2388 Milpitas, CA 95035 2389 USA 2391 Email: nfinn@cisco.com 2393 Samer Salam 2394 CISCO Systems 2395 595 Burrard St. Suite 2123 2396 Vancouver, BC V7X 1J1 2397 Canada 2399 Email: ssalam@cisco.com 2401 Authors' Addresses 2403 Deepak Kumar 2404 CISCO Systems 2405 510 McCarthy Blvd 2406 Milpitas, CA 95035 2407 USA 2409 Email: dekumar@cisco.com 2411 Qin Wu 2412 Huawei 2413 101 Software Avenue, Yuhua District 2414 Nanjing, Jiangsu 210012 2415 China 2417 Email: bill.wu@huawei.com 2419 Michael Wang 2420 Huawei Technologies,Co.,Ltd 2421 101 Software Avenue, Yuhua District 2422 Nanjing 210012 2423 China 2425 Email: wangzitao@huawei.com