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