idnits 2.17.1 draft-tissa-lime-yang-oam-model-04.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 408 has weird spacing: '...terface if:...' == Line 560 has weird spacing: '...terface lea...' == Line 562 has weird spacing: '...terface if:...' == Line 583 has weird spacing: '...terface if:...' == Line 624 has weird spacing: '...terface if:...' == (1 more instance...) -- The document date (April 16, 2015) is 3269 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: 'I-D.tissa-lime-yang-oam-model' is mentioned on line 88, but not defined == Missing Reference: 'RFC6020' is mentioned on line 88, but not defined == Missing Reference: 'Y1731' is mentioned on line 107, but not defined == Missing Reference: 'TRILLOAMFM' is mentioned on line 107, but not defined == Missing Reference: '8021Q' is mentioned on line 188, but not defined == Missing Reference: 'MA-name-string' is mentioned on line 481, but not defined == Unused Reference: 'RFC6241' is defined on line 1951, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1960, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1963, but no explicit reference was found in the text == Unused Reference: 'RFC4676' is defined on line 1974, but no explicit reference was found in the text == Unused Reference: 'RFC6374' is defined on line 1990, but no explicit reference was found in the text == Unused Reference: 'RFC7456' is defined on line 2007, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Q' -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4676 (Obsoleted by RFC 4776) Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Senevirathne 3 Internet-Draft N. Finn 4 Intended status: Standards Track D. Kumar 5 Expires: October 18, 2015 S. Salam 6 Cisco 7 Q. Wu 8 M. Wang 9 Huawei 10 April 16, 2015 12 Generic YANG Data Model for Operations, Administration, and Maintenance 13 (OAM) 14 draft-tissa-lime-yang-oam-model-04 16 Abstract 18 Operations, Administration, and Maintenance (OAM) are important 19 networking functions that allow operators to: 21 1. Monitor networks (Connectivity Verification, Continuity Check). 23 2. Troubleshoot failures (Fault verification and isolation). 25 3. Measure Performance 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 http://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 October 18, 2015. 44 Copyright Notice 46 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 4 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Architecture of Generic YANG Model for OAM . . . . . . . . . 5 65 4. Overview of the OAM Model . . . . . . . . . . . . . . . . . . 6 66 4.1. Maintenance Domain (MD) configuration . . . . . . . . . . 7 67 4.2. Maintenance Association (MA) configuration . . . . . . . 8 68 4.3. Maintenance Endpoint (MEP) configuration . . . . . . . . 8 69 4.4. rpc definitions . . . . . . . . . . . . . . . . . . . . . 9 70 4.5. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 11 71 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 72 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 40 73 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 41 74 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 41 75 6.3. Maintenance Domain . . . . . . . . . . . . . . . . . . . 41 76 6.4. Maintenance Association . . . . . . . . . . . . . . . . . 41 77 7. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 42 82 10.2. Informative References . . . . . . . . . . . . . . . . . 42 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 44 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 86 1. Introduction 88 [I-D.tissa-lime-yang-oam-model] defines a YANG [RFC6020] data model 89 for Layer independent OAM Management implementations that can be 90 applied to various network technologies. This YANG module describes 91 the abstract common core configuration, statistics for Unified 92 Management Plane OAM to be used within IETF in a layer independent 93 manner.This document describes the abstract notification and rpc 94 command which is complementary to the one defined in the [I-D.tissa- 95 lime-yang-oam-model] . The abstract notification and rpc command 96 includes technology independent configuration data and state data. 98 An overview of OAM tools is presented at [RFC7276]. 100 Ping and Traceroute [RFC792], [RFC4443] are well-known fault 101 verification and isolation tools, respectively, for IP networks. 102 Over the years, different technologies have developed similar tools 103 for similar purposes. 105 [IEEE802.1Q] Connectivity Fault Management is a well-established OAM 106 standard that is widely adopted for Ethernet networks. ITU-T 107 [Y1731], MEF Service OAM, MPLS-TP [RFC6371], TRILL [TRILLOAMFM] all 108 define OAM methods based on manageability frame work of [IEEE802.1Q] 109 CFM. 111 Given the wide adoption of the underlying OAM concepts defined in 112 [IEEE802.1Q] CFM, it is a reasonable choice to develop the unified 113 management framework based on those concepts. In this document, we 114 take the [IEEE802.1Q] CFM model and extend it to a technology 115 independent framework and build the corresponding YANG model 116 accordingly. The YANG model presented in this document is the base 117 model and supports generic continuity check, connectivity 118 verification and path discovery. The generic OAM YANG model is 119 designed such that it can be extended to cover various technologies. 120 Technology dependent nodes and RPC commands are defined in technology 121 specific YANG models, which use and extend the base model defined 122 here. As an example, VXLAN uses source UDP port number for flow 123 entropy, while MPLS [RFC4379] uses IP addresses or the label stack 124 for flow entropy in the hashing for multipath selection. To capture 125 this variation, corresponding YANG models would define the applicable 126 structures as augmentation to the generic base model presented here. 127 This accomplishes three purposes: first it keeps each YANG model 128 smaller and manageable. Second, it allows independent development of 129 corresponding YANG models. Third, implementations can limit support 130 to only the applicable set of YANG models. (e.g. TRILL RBridge may 131 only need to implement Generic OAM model and the TRILL YANG model). 133 All implementations that follow the YANG framework presented in this 134 document MUST implement the generic OAM YANG model presented here. 136 The YANG data model presented in this document occurs at the 137 management layer. Encapsulations and state machines may differ 138 according to each OAM protocol. A user who wishes to issues a Ping 139 command or a Traceroute or initiate a performance monitoring session 140 can do so in the same manner regardless of the underlying protocol or 141 technology or specific vendor implementation. 143 As an example, consider a scenario where an IP ping from device A to 144 Device B failed. Between device A and B there are IEEE 802.1 bridges 145 a,b and c. Let's assume a,b and c are using [IEEE802.1Q] CFM. A 146 user upon detecting the IP layer ping failures may decide to drill 147 down to the Ethernet layer and issue the corresponding fault 148 verification (LBM) and fault isolation (LTM) tools, using the same 149 API. This ability to go up and down to different layers for 150 troubleshooting is referred to as "nested OAM workflow" and is a 151 useful concept that leads to efficient network troubleshooting and 152 maintenance. The OAM YANG model presented in this document 153 facilitates that without needing changes to the underlying protocols. 155 2. Conventions used in this document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 In this document, these words will appear with that interpretation 162 only when in ALL CAPS. Lower case uses of these words are not to be 163 interpreted as carrying RFC-2119 significance. 165 2.1. Terminology 167 CCM Continuity Check Message [IEEE802.1Q]. 169 ECMP 170 Equal Cost Multipath. 172 LBM 173 Loopback Message [IEEE802.1Q]. 175 MP 176 Maintenance Point [IEEE802.1Q]. 178 MEP 179 Maintenance End Point [RFC7174] [IEEE802.1Q] [RFC6371]. 181 MIP 182 Maintenance Intermediate Point [RFC7174] [IEEE802.1Q] [RFC6371]. 184 MA 185 Maintenance Association [IEEE802.1Q] [RFC7174]. 187 MD 188 Maintenance Domain [8021Q] 190 MTV 191 Multi-destination Tree Verification Message. 193 OAM 194 Operations, Administration, and Maintenance [RFC6291]. 196 TRILL 197 Transparent Interconnection of Lots of Links [RFC6325]. 199 3. Architecture of Generic YANG Model for OAM 201 In this document we define a generic YANG model for OAM. The YANG 202 model defined here is generic such that other technologies can extend 203 it for technology specific needs. The Generic OAM YANG model acts as 204 the root for other OAM YANG models. This allows users to traverse 205 between OAM of different technologies at ease through a uniform API 206 set. This is also provides a nested OAM workflow. Figure 1 depicts 207 the relationship of different OAM YANG models to the Generic OAM YANG 208 Model. Some technologies may have different sub-technologies. As an 209 example, consider Network Virtualization Overlays. These could 210 employ either vXLAN or NVGRE as encapsulation. The Generic OAM YANG 211 model provides a framework where technology-specific YANG models can 212 inherit constructs from the base YANG models without needing to 213 redefine them within the sub-technology. 215 Figure 1 depicts relationship of different YANG modules. 217 +-+-+-+-+-+ 218 | gen | 219 |OAM YANG | 220 +-+-+-+-+-+ 221 | 222 O 223 | 224 +---------------------------------------------------------+ 225 | | | | | 226 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 227 | TRILL | | NVO3 | | MPLS | | IP | . . .| foo | 228 |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | 229 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 230 | | | | | 231 | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ 232 | | NVO3 | | MPLS | | . . .| foo | 233 | |sub tech | |sub tech | | |sub tech | 234 | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ 235 | | | | | 236 | | | | | 237 +------------------------------------------------------------+ 238 | Uniform API | 239 +------------------------------------------------------------+ 241 Relationship of OAM YANG model to generic (base) YANG model 243 4. Overview of the OAM Model 245 In this document we adopt the concepts of the [IEEE802.1Q] CFM model 246 and structure it such that it can be adapted to different 247 technologies. 249 At the top of the Model is the Maintenance Domain. Each Maintenance 250 Domain is associated with a Maintenance Name and a Domain Level. 252 Under each Maintenance Domain there is one or more Maintenance 253 Association (MA). In IP, the MA can be per IP Subnet, in NVO3 this 254 can be per VNI and for TRILL this can be per Fine-Grained Label or 255 for VPLS this can be per VPLS instance. 257 Under each MA, there can be two or more MEPs (Maintenance End 258 Points). MEPs are addressed by their respective technology specific 259 address identifiers. The YANG model presented here provides 260 flexibility to accommodate different addressing schemes. 262 In a parallel vertical, presented are the commands. Those, in YANG 263 terms, are the rpc commands. These rpc commands provide uniform APIs 264 for continuity check,connectivity verification, path discovery and 265 their equivalents as well as other OAM commands. 267 [IEEE802.1Q] CFM framework requires explicit configuration of OAM 268 entities prior to using any of the OAM tools. Users of Ping and 269 Traceroute tools within IP devices are expecting ability to use OAM 270 tools with no explicit configuration. In order to facilitate zero- 271 touch experience, this document defines a default mode of OAM. The 272 default mode of OAM is referred to as the Base Mode and specifies 273 default values for each of the [IEEE802.1Q] CFM parameters, such as 274 Maintenance Domain Level, Name of the Maintenance Association and 275 Addresses of MEP and so on. The default values of these depend on 276 the technology. Base Mode for TRILL is defined in [RFC7455]. Base 277 mode for other technologies such as NVO3, MPLS and future extensions 278 will be defined in their corresponding documents. 280 It is important to note that, no specific enhancements are needed in 281 the YANG model to support Base Mode. Implementations that comply 282 with this document, by default implement the data nodes of the 283 applicable technology. Data nodes of the Base Mode are read-only 284 nodes. 286 4.1. Maintenance Domain (MD) configuration 288 The container "domains" is the top level container within the gen-oam 289 module. Within the container "domains", separate list is maintained 290 per MD. The MD list uses the key MD-name-string for indexing. MD- 291 name-string is a leaf and derived from type string. Additional name 292 formats as defined in [IEEE802.1Q] or other standards can be included 293 by association of the MD-name-format with an identity-ref. MD-name- 294 format indicates the format of the augmented MD-names. MD-name is 295 presented as choice/case construct. Thus, it is easily augmentable 296 by derivative work. 298 module: ietf-gen-oam 299 +--rw domains 300 +--rw domain* [technology MD-name-string] 301 +--rw technology identityref 302 +--rw MD-name-string MD-name-string 303 +--rw MD-name-format? identityref 304 +--rw (MD-name)? 305 | +--:(MD-name-null) 306 | +--rw MD-name-null? empty 307 +--rw md-level MD-level . 309 Snippet of data hierarchy related to OAM domains 311 4.2. Maintenance Association (MA) configuration 313 Within a given Maintenance Domain there can be one or more 314 Maintenance Associations (MA). MAs are represented as a list and 315 indexed by the MA-name-string. Similar to MD-name defined 316 previously, additional name formats can be added by augmenting the 317 name-format identity-ref and adding applicable case statements to MA- 318 name. 320 module: ietf-gen-oam 321 +--rw domains 322 +--rw domain* [technology MD-name-string] 323 . 324 . 325 +--rw MAs 326 +--rw MA* [MA-name-string] 327 +--rw MA-name-string MA-name-string 328 +--rw MA-name-format? identityref 329 +--rw (MA-name)? 330 | +--:(MA-name-null) 331 | +--rw MA-name-null? empty 333 Snippet of data hierarchy related to Maintenance Associations (MA) 335 4.3. Maintenance Endpoint (MEP) configuration 337 Within a given Maintenance Association (MA), there can be one or more 338 Maintenance End Points (MEP). MEPs are represented as a list within 339 the data hierarchy and indexed by the key MEP-name. 341 module: ietf-gen-oam 342 +--rw domains 343 +--rw domain* [technology MD-name-string] 344 +--rw technology identityref 345 . 346 . 347 +--rw MAs 348 +--rw MA* [MA-name-string] 349 +--rw MA-name-string MA-name-string 350 . 351 . 352 +--rw MEP* [mep-name] 353 | +--rw mep-name MEP-name 354 | +--rw (MEP-ID)? 355 | | +--:(MEP-ID-int) 356 | | +--rw MEP-ID-int? int32 357 | | +--:(MEP-ID-tlv) 358 | | +--rw MEP-ID-type? int16 359 | | +--rw MEP-ID-len? int16 360 | | +--rw MEP-ID-value? binary 361 | +--rw MEP-ID-format? identityref 362 | +--rw (mp-address)? 363 | | +--:(mac-address) 364 | | | +--rw mac-address? yang:mac-address 365 | | +--:(ipv4-address) 366 | | | +--rw ipv4-address? inet:ipv4-address 367 | | +--:(ipv6-address) 368 | | +--rw ipv6-address? inet:ipv6-address 369 . . 370 . . 371 . . 373 Snippet of data hierarchy related to Maintenance Endpoint (MEP) 375 4.4. rpc definitions 377 The rpc model facilitates issuing commands to a NETCONF server (in 378 this case to the device that need to execute the OAM command) and 379 obtain a response. rpc model defined here abstracts OAM specific 380 commands in a technology independent manner. 382 There are several rpc commands defined for the purpose of OAM. In 383 this section we present a snippet of the ping command for 384 illustration purposes. Please refer to Section 4 for the complete 385 data hierarchy and Section 5 for the YANG model. 387 module: ietf-gen-oam 388 +--rw domains 389 +--rw domain* [technology MD-name-string] 390 +--rw technology identityref 391 . 392 . 393 rpcs: 394 +---x continuity-check 395 | +--ro input 396 | | +--ro technology identityref 397 | | +--ro MD-name-string MD-name-string 398 | | +--ro MA-name-string? MA-name-string 399 | | +--ro (flow-entropy)? 400 | | | +--:(flow-entropy-null) 401 | | | +--ro flow-entropy-null? empty 402 | | +--ro priority? uint8 403 | | +--ro ttl? uint8 404 | | +--ro session-type enumeration 405 | | +--ro ecmp-choice? ecmp-choices 406 | | +--ro sub-type? identityref 407 | | +--ro outgoing-interfaces* [interface] 408 | | | +--ro interface if:interface-ref 409 | | +--ro source-mep? MEP-name 410 | | +--ro destination-mp 411 | | | +--ro (mp-address)? 412 | | | | +--:(mac-address) 413 | | | | | +--ro mac-address? yang:mac-address 414 | | | | +--:(ipv4-address) 415 | | | | | +--ro ipv4-address? inet:ipv4-address 416 | | | | +--:(ipv6-address) 417 | | | | +--ro ipv6-address? inet:ipv6-address 418 | | | +--ro (MEP-ID)? 419 | | | | +--:(MEP-ID-int) 420 | | | | +--ro MEP-ID-int? int32 421 | | | +--ro MEP-ID-format? identityref 422 | | +--ro count? uint32 423 | | +--ro interval? Interval 424 | | +--ro packet-size? uint32 425 | +--ro output 426 | +--ro tx-packt-count? oam-counter32 427 | +--ro rx-packet-count? oam-counter32 428 | +--ro min-delay? oam-counter32 429 | +--ro average-delay? oam-counter32 430 | +--ro max-delay? oam-counter32 432 Snippet of data hierarchy related to rpc call continuity-check 434 4.5. OAM data hierarchy 436 The complete data hierarchy related to the OAM YANG model is 437 presented below. The following notations are used within the data 438 tree and carry the meaning as below. 440 Each node is printed as: 442 444 is one of: 445 + for current 446 x for deprecated 447 o for obsolete 449 is one of: 451 rw for configuration data 452 ro for non-configuration data 453 -x for rpcs 454 -n for notifications 456 is the name of the node 458 If the node is augmented into the tree from another module, its name 459 is printed as :. 461 is one of: 463 ? for an optional leaf or choice 464 ! for a presence container 465 * for a leaf-list or list 466 [] for a list's keys 468 is the name of the type for leafs and leaf-lists 470 module: ietf-gen-oam 471 +--rw domains 472 +--rw domain* [technology MD-name-string] 473 +--rw technology identityref 474 +--rw MD-name-string MD-name-string 475 +--rw MD-name-format? identityref 476 +--rw (MD-name)? 477 | +--:(MD-name-null) 478 | +--rw MD-name-null? empty 479 +--rw md-level? MD-level 480 +--rw MAs 481 +--rw MA* [MA-name-string] 482 +--rw MA-name-string MA-name-string 483 +--rw MA-name-format? identityref 484 +--rw (MA-name)? 485 | +--:(MA-name-null) 486 | +--rw MA-name-null? empty 487 +--rw (connectivity-context)? 488 | +--:(context-null) 489 | +--rw context-null? empty 490 +--rw mep-direction MEP-direction 491 +--rw interval? Interval 492 +--rw loss-threshold? uint32 493 +--rw ttl? uint8 494 +--rw (flow-entropy)? 495 | +--:(flow-entropy-null) 496 | +--rw flow-entropy-null? empty 497 +--rw priority? uint8 498 +--rw MEP* [mep-name] 499 | +--rw mep-name MEP-name 500 | +--rw (MEP-ID)? 501 | | +--:(MEP-ID-int) 502 | | | +--rw MEP-ID-int? int32 503 | | +--:(MEP-ID-tlv) 504 | | +--rw MEP-ID-type? int16 505 | | +--rw MEP-ID-len? int16 506 | | +--rw MEP-ID-value? binary 507 | +--rw MEP-ID-format? identityref 508 | +--rw (mp-address)? 509 | | +--:(mac-address) 510 | | | +--rw mac-address? yang:mac-address 511 | | +--:(ipv4-address) 512 | | | +--rw ipv4-address? inet:ipv4-address 513 | | +--:(ipv6-address) 514 | | +--rw ipv6-address? inet:ipv6-address 515 | +--rw (connectivity-context)? 516 | | +--:(context-null) 517 | | +--rw context-null? empty 518 | +--rw Interface? if:interface-ref 519 | +--rw (topology)? 520 | | +--:(topo-null) 521 | | +--rw topo-null? empty 522 | +--ro admin-status? leafref 523 | +--ro oper-status? leafref 524 | +--rw (flow-entropy)? 525 | | +--:(flow-entropy-null) 526 | | +--rw flow-entropy-null? empty 527 | +--rw priority? uint8 528 | +--rw session* [session-cookie] 529 | +--rw session-cookie uint32 530 | +--rw ttl? uint8 531 | +--rw interval? Interval 532 | +--rw enable? boolean 533 | +--rw ecmp-choice? ecmp-choices 534 | +--rw source-mep? MEP-name 535 | +--rw destination-mep 536 | | +--rw (MEP-ID)? 537 | | | +--:(MEP-ID-int) 538 | | | | +--rw MEP-ID-int? int32 539 | | | +--:(MEP-ID-tlv) 540 | | | +--rw MEP-ID-type? int16 541 | | | +--rw MEP-ID-len? int16 542 | | | +--rw MEP-ID-value? binary 543 | | +--rw MEP-ID-format? identityref 544 | +--rw destination-mep-address 545 | | +--rw (mp-address)? 546 | | +--:(mac-address) 547 | | | +--rw mac-address? yang:mac-address 548 | | +--:(ipv4-address) 549 | | | +--rw ipv4-address? inet:ipv4-address 550 | | +--:(ipv6-address) 551 | | +--rw ipv6-address? inet:ipv6-address 552 | +--rw (connectivity-context)? 553 | | +--:(context-null) 554 | | +--rw context-null? empty 555 | +--rw (flow-entropy)? 556 | | +--:(flow-entropy-null) 557 | | +--rw flow-entropy-null? empty 558 | +--rw priority? uint8 559 | +--rw outgoing-interface* [interface] 560 | +--rw interface leafref 561 +--rw MIP* [interface] 562 | +--rw interface if:interface-ref 563 +--rw related-oam-layer* [offset] 564 +--rw offset int32 565 +--rw technology identityref 566 +--rw MD-name-string MD-name-string 567 +--rw MA-name-string? MA-name-string 568 rpcs: 569 +---x continuity-check 570 | +--ro input 571 | | +--ro technology identityref 572 | | +--ro MD-name-string MD-name-string 573 | | +--ro MA-name-string? MA-name-string 574 | | +--ro (flow-entropy)? 575 | | | +--:(flow-entropy-null) 576 | | | +--ro flow-entropy-null? empty 577 | | +--ro priority? uint8 578 | | +--ro ttl? uint8 579 | | +--ro session-type-enum? enumeration 580 | | +--ro ecmp-choice? ecmp-choices 581 | | +--ro sub-type? identityref 582 | | +--ro outgoing-interfaces* [interface] 583 | | | +--ro interface if:interface-ref 584 | | +--ro source-mep? MEP-name 585 | | +--ro destination-mp 586 | | | +--ro (mp-address)? 587 | | | | +--:(mac-address) 588 | | | | | +--ro mac-address? yang:mac-address 589 | | | | +--:(ipv4-address) 590 | | | | | +--ro ipv4-address? inet:ipv4-address 591 | | | | +--:(ipv6-address) 592 | | | | +--ro ipv6-address? inet:ipv6-address 593 | | | +--ro (MEP-ID)? 594 | | | | +--:(MEP-ID-int) 595 | | | | | +--ro MEP-ID-int? int32 596 | | | | +--:(MEP-ID-tlv) 597 | | | | +--ro MEP-ID-type? int16 598 | | | | +--ro MEP-ID-len? int16 599 | | | | +--ro MEP-ID-value? binary 600 | | | +--ro MEP-ID-format? identityref 601 | | +--ro count? uint32 602 | | +--ro interval? Interval 603 | | +--ro packet-size? uint32 604 | +--ro output 605 | +--ro tx-packt-count? oam-counter32 606 | +--ro rx-packet-count? oam-counter32 607 | +--ro min-delay? oam-counter32 608 | +--ro average-delay? oam-counter32 609 | +--ro max-delay? oam-counter32 610 +---x continuity-verification {connectivity-verification}? 611 | +--ro input 612 | | +--ro technology identityref 613 | | +--ro MD-name-string MD-name-string 614 | | +--ro MA-name-string? MA-name-string 615 | | +--ro (flow-entropy)? 616 | | | +--:(flow-entropy-null) 617 | | | +--ro flow-entropy-null? empty 618 | | +--ro priority? uint8 619 | | +--ro ttl? uint8 620 | | +--ro session-type-enum? enumeration 621 | | +--ro ecmp-choice? ecmp-choices 622 | | +--ro sub-type? identityref 623 | | +--ro outgoing-interfaces* [interface] 624 | | | +--ro interface if:interface-ref 625 | | +--ro source-mep? MEP-name 626 | | +--ro destination-mp 627 | | | +--ro (mp-address)? 628 | | | | +--:(mac-address) 629 | | | | | +--ro mac-address? yang:mac-address 630 | | | | +--:(ipv4-address) 631 | | | | | +--ro ipv4-address? inet:ipv4-address 632 | | | | +--:(ipv6-address) 633 | | | | +--ro ipv6-address? inet:ipv6-address 634 | | | +--ro (MEP-ID)? 635 | | | | +--:(MEP-ID-int) 636 | | | | | +--ro MEP-ID-int? int32 637 | | | | +--:(MEP-ID-tlv) 638 | | | | +--ro MEP-ID-type? int16 639 | | | | +--ro MEP-ID-len? int16 640 | | | | +--ro MEP-ID-value? binary 641 | | | +--ro MEP-ID-format? identityref 642 | | +--ro count? uint32 643 | | +--ro interval? Interval 644 | | +--ro packet-size? uint32 645 | +--ro output 646 | +--ro tx-packt-count? oam-counter32 647 | +--ro rx-packet-count? oam-counter32 648 | +--ro min-delay? oam-counter32 649 | +--ro average-delay? oam-counter32 650 | +--ro max-delay? oam-counter32 651 +---x path-discovery 652 +--ro input 653 | +--ro technology identityref 654 | +--ro MD-name-string MD-name-string 655 | +--ro MA-name-string? MA-name-string 656 | +--ro (flow-entropy)? 657 | | +--:(flow-entropy-null) 658 | | +--ro flow-entropy-null? empty 659 | +--ro priority? uint8 660 | +--ro ttl? uint8 661 | +--ro session-type-enum? enumeration 662 | +--ro command-sub-type? identityref 663 | +--ro ecmp-choice? ecmp-choices 664 | +--ro outgoing-interfaces* [interface] 665 | | +--ro interface if:interface-ref 666 | +--ro source-mep? MEP-name 667 | +--ro destination-mp 668 | | +--ro (mp-address)? 669 | | | +--:(mac-address) 670 | | | | +--ro mac-address? yang:mac-address 671 | | | +--:(ipv4-address) 672 | | | | +--ro ipv4-address? inet:ipv4-address 673 | | | +--:(ipv6-address) 674 | | | +--ro ipv6-address? inet:ipv6-address 675 | | +--ro (MEP-ID)? 676 | | | +--:(MEP-ID-int) 677 | | | | +--ro MEP-ID-int? int32 678 | | | +--:(MEP-ID-tlv) 679 | | | +--ro MEP-ID-type? int16 680 | | | +--ro MEP-ID-len? int16 681 | | | +--ro MEP-ID-value? binary 682 | | +--ro MEP-ID-format? identityref 683 | +--ro count? uint32 684 | +--ro interval? Interval 685 +--ro output 686 +--ro response* [response-index] 687 +--ro response-index uint8 688 +--ro ttl? uint8 689 +--ro destination-mp 690 | +--ro (mp-address)? 691 | | +--:(mac-address) 692 | | | +--ro mac-address? yang:mac-address 693 | | +--:(ipv4-address) 694 | | | +--ro ipv4-address? inet:ipv4-address 695 | | +--:(ipv6-address) 696 | | +--ro ipv6-address? inet:ipv6-address 697 | +--ro (MEP-ID)? 698 | | +--:(MEP-ID-int) 699 | | | +--ro MEP-ID-int? int32 700 | | +--:(MEP-ID-tlv) 701 | | +--ro MEP-ID-type? int16 702 | | +--ro MEP-ID-len? int16 703 | | +--ro MEP-ID-value? binary 704 | +--ro MEP-ID-format? identityref 705 +--ro tx-packt-count? oam-counter32 706 +--ro rx-packet-count? oam-counter32 707 +--ro min-delay? oam-counter32 708 +--ro average-delay? oam-counter32 709 +--ro max-delay? oam-counter32 710 notifications: 711 +---n defect-condition-notification 712 +--ro technology identityref 713 +--ro MD-name-string MD-name-string 714 +--ro MA-name-string? MA-name-string 715 +--ro mep-name? MEP-name 716 +--ro defect-type? identityref 717 +--ro generating-mepid 718 | +--ro (MEP-ID)? 719 | | +--:(MEP-ID-int) 720 | | | +--ro MEP-ID-int? int32 721 | | +--:(MEP-ID-tlv) 722 | | +--ro MEP-ID-type? int16 723 | | +--ro MEP-ID-len? int16 724 | | +--ro MEP-ID-value? binary 725 | +--ro MEP-ID-format? identityref 726 +--ro (error)? 727 +--:(error-null) 728 | +--ro error-null? empty 729 +--:(error-code) 730 +--ro error-code? int3 731 +--ro error-code? int32 733 data hierarchy of OAM 735 5. OAM YANG Module 737 file "ietf-gen-oam.yang" 739 module ietf-gen-oam { 740 namespace "urn:ietf:params:xml:ns:yang:gen-oam"; 741 prefix goam; 743 import ietf-interfaces { 744 prefix if; 745 } 746 import ietf-yang-types { 747 prefix yang; 748 } 749 import ietf-inet-types { 750 prefix inet; 751 } 753 organization "IETF LIME Working Group"; 754 contact 755 "Tissa Senevirathne tsenevir@cisco.com"; 756 description 757 "This YANG module defines the generic configuration, 758 statistics and rpc for OAM to be used within IETF in 759 a protocol indpendent manner. Functional level 760 abstraction is indendent with YANG modeling. It is 761 assumed that each protocol maps corresponding 762 abstracts to its native format. 763 Each protocol may extend the YANG model defined 764 here to include protocol specific extensions"; 766 revision 2015-04-09 { 767 description 768 "Initial revision. - 04 version"; 769 reference "draft-tissa-lime-oam"; 770 } 772 /* features */ 773 feature connectivity-verification { 774 description 775 "This feature indicates that the server supports 776 executing connectivity verification OAM command and 777 returning a response. Servers that do not advertise 778 this feature will not support executing 779 connectivity verification command or rpc model for 780 connectivity verification command."; 781 } 783 /* Identities */ 785 identity technology-types { 786 description 787 "this is the base identy of technology types which are 788 vpls, nvo3, TRILL, ipv4, ipv6, mpls, etc"; 789 } 791 identity ipv4 { 792 base technology-types; 793 description 794 "technology of ipv4"; 795 } 797 identity ipv6 { 798 base technology-types; 799 description 800 "technology of ipv6"; 801 } 803 identity command-sub-type { 804 description 805 "defines different rpc command subtypes, e.g rfc792 IP 806 ping, rfc4379 LSP ping, rfc6905 trill OAM, this is 807 optional for most cases"; 808 } 810 identity icmp-rfc792 { 811 base command-sub-type; 812 description 813 "Defines the command subtypes for ICMP ping"; 815 reference "RFC 792"; 816 } 818 identity name-format { 819 description 820 "This defines the name format, IEEE 8021Q CFM defines varying 821 styles of names. It is expected name format as an identity ref 822 to be extended with new types."; 823 } 825 identity name-format-null { 826 base name-format; 827 description 828 "defines name format as null"; 829 } 831 identity identifier-format { 832 description 833 "identifier-format identity can be augmented to define other 834 format identifiers used in MEPD-ID etc"; 835 } 837 identity identifier-format-integer { 838 base identifier-format; 839 description 840 "defines identifier-format to be integer"; 841 } 843 identity defect-types { 844 description 845 "defines different defect types, e.g. remote rdi, 846 mis-connection defect, loss of continuity"; 847 } 849 /* typedefs */ 850 typedef MEP-direction { 851 type enumeration { 852 enum "Up" { 853 value 0; 854 description 855 "UP direction."; 856 } 857 enum "Down" { 858 value 1; 859 description 860 "Down direction."; 862 } 864 } 865 description 866 "MEP direction."; 867 } 869 typedef MEP-name { 870 type string; 871 description 872 "Generic administrative name for a MEP"; 873 } 875 typedef Interval { 876 type uint32; 877 units "milliseconds"; 878 default "1000"; 879 description 880 "Interval between packets in milliseconds. 881 0 means no packets are sent."; 882 } 884 typedef ecmp-choices { 885 type enumeration { 886 enum "ecmp-use-platform-hash" { 887 value 0; 888 description 889 "Use Platform hashing."; 890 } 891 enum "ecmp-use-round-robin" { 892 value 1; 893 description 894 "Use round robin hashing."; 895 } 896 } 897 description 898 "Equal cost multi Path Choices"; 899 } 901 typedef MD-name-string { 902 type string; 903 default ""; 904 description 905 "Generic administrative name for an MD"; 906 } 908 typedef MA-name-string { 909 type string; 910 default ""; 911 description 912 "Generic administrative name for an MA"; 913 } 915 typedef oam-counter32 { 916 type yang:zero-based-counter32; 917 description 918 "defines 32 bit counter for OAM"; 919 } 921 typedef MD-level { 922 type uint32 { 923 range "0..255"; 924 } 925 description 926 "Maintenance Domain level. The level may be restricted in 927 certain protocols (eg to 0-7)"; 928 } 930 /* groupings */ 932 grouping topology { 933 choice topology { 934 case topo-null { 935 description 936 "this is a placeholder when no topology is needed"; 937 leaf topo-null { 938 type empty; 939 description 940 "there is no topology define, it will be defined 941 in technology specific model."; 942 } 943 } 944 description 945 "Topology choices"; 946 } 947 description 948 "Topology"; 949 } 951 grouping error-message { 952 choice error { 953 case error-null { 954 description 955 "this is a placeholder when no error status is needed"; 956 leaf error-null { 957 type empty; 958 description 959 "there is no error define, it will be defined in 960 technology specific model."; 961 } 962 } 963 case error-code { 964 description 965 "this is a placeholder to display error code."; 966 leaf error-code { 967 type int32; 968 description 969 "error code is integer value specific to technology."; 970 } 971 } 972 description 973 "Error Message choices."; 974 } 975 description 976 "Error Message."; 977 } 979 grouping mp-address { 980 choice mp-address { 981 case mac-address { 982 leaf mac-address { 983 type yang:mac-address; 984 description 985 "MAC Address"; 986 } 987 description 988 "MAC Address based MP Addressing."; 989 } 990 case ipv4-address { 991 leaf ipv4-address { 992 type inet:ipv4-address; 993 description 994 "Ipv4 Address"; 995 } 996 description 997 "Ip Address based MP Addressing."; 998 } 999 case ipv6-address { 1000 leaf ipv6-address { 1001 type inet:ipv6-address; 1002 description 1003 "Ipv6 Address"; 1004 } 1005 description 1006 "ipv6 Address based MP Addressing."; 1007 } 1008 description 1009 "MP Addressing."; 1010 } 1011 description 1012 "MP Address"; 1013 } 1015 grouping maintenance-domain-id { 1016 description 1017 "Grouping containing leaves sufficient to identify an MD"; 1018 leaf technology { 1019 type identityref { 1020 base technology-types; 1021 } 1022 mandatory true; 1024 description 1025 "Defines the technology"; 1026 } 1027 leaf MD-name-string { 1028 type MD-name-string; 1029 mandatory true; 1030 description 1031 "Defines the generic administrative maintenance domain name"; 1032 } 1033 } 1035 grouping MD-name { 1036 leaf MD-name-format { 1037 type identityref { 1038 base name-format; 1039 } 1040 description 1041 "Name format."; 1042 } 1043 choice MD-name { 1044 case MD-name-null { 1045 leaf MD-name-null { 1046 when "../../../MD-name-format = name-format-null" { 1047 description 1048 "MD name format is equal to null format."; 1049 } 1050 type empty; 1051 description 1052 "MD name Null."; 1053 } 1054 } 1055 description 1056 "MD name."; 1057 } 1058 description 1059 "MD name"; 1060 } 1062 grouping ma-identifier { 1063 description 1064 "Grouping containing leaves sufficient to identify an MA"; 1065 leaf MA-name-string { 1066 type MA-name-string; 1067 description 1068 "MA name string."; 1069 } 1070 } 1072 grouping MA-name { 1073 description 1074 "MA name"; 1075 leaf MA-name-format { 1076 type identityref { 1077 base name-format; 1078 } 1079 description 1080 "Ma name format"; 1081 } 1082 choice MA-name { 1083 case MA-name-null { 1084 leaf MA-name-null { 1085 when "../../../MA-name-format = name-format-null" { 1086 description 1087 "MA"; 1088 } 1089 type empty; 1090 description 1091 "empty"; 1092 } 1093 } 1094 description 1095 "MA name"; 1096 } 1097 } 1099 grouping MEP-ID { 1100 choice MEP-ID { 1101 default "MEP-ID-int"; 1102 case MEP-ID-int { 1103 leaf MEP-ID-int { 1104 type int32; 1105 description 1106 "MEP ID in integer format"; 1107 } 1108 } 1109 case MEP-ID-tlv { 1110 leaf MEP-ID-type { 1111 type int16; 1112 description 1113 "Type of MEP-ID"; 1114 } 1115 leaf MEP-ID-len { 1116 type int16; 1117 description 1118 "Length of MEP-ID value"; 1119 } 1120 leaf MEP-ID-value { 1121 type binary { 1122 length "12..255"; 1123 } 1124 description 1125 "Value please refer RFC6428."; 1126 } 1127 } 1128 description 1129 "MEP-ID"; 1130 } 1131 leaf MEP-ID-format { 1132 type identityref { 1133 base identifier-format; 1134 } 1135 description 1136 "MEP ID format."; 1137 } 1138 description 1139 "MEP-ID"; 1140 } 1142 grouping MEP { 1143 description 1144 "Defines elements within the MEP"; 1145 leaf mep-name { 1146 type MEP-name; 1147 mandatory true; 1148 description 1149 "Generic administrative name of the MEP"; 1150 } 1151 uses MEP-ID; 1152 uses mp-address; 1153 uses connectivity-context; 1154 leaf Interface { 1155 type if:interface-ref; 1156 description 1157 "Interface name as defined by ietf-interfaces"; 1158 } 1159 uses topology; 1160 } 1162 grouping session-type { 1163 description 1164 "This object indicates the current session 1165 definition."; 1166 leaf session-type-enum { 1167 type enumeration { 1168 enum proactive { 1169 description 1170 "The current session is proactive"; 1171 } 1172 enum on-demand { 1173 description 1174 "The current session is on-demand."; 1175 } 1176 } 1177 description 1178 "session type enum"; 1179 } 1180 } 1182 grouping monitor-stats { 1183 leaf tx-packt-count { 1184 type oam-counter32; 1185 description 1186 "Transmitted Packet count"; 1187 } 1188 leaf rx-packet-count { 1189 type oam-counter32; 1190 description 1191 "Received packet count"; 1192 } 1193 leaf min-delay { 1194 type oam-counter32; 1195 units milliseconds; 1196 description 1197 "Delay is specified in milliseconds"; 1198 } 1199 leaf average-delay { 1200 type oam-counter32; 1201 units millisecond; 1202 description 1203 "average delay in milliseconds"; 1204 } 1205 leaf max-delay { 1206 type oam-counter32; 1207 units millisecond; 1208 description 1209 "Maximum delay in milliseconds"; 1210 } 1211 description 1212 "Monitor Statistics"; 1213 } 1215 grouping MIP { 1216 description 1217 "defines MIP"; 1218 leaf interface { 1219 type if:interface-ref; 1220 description 1221 "Interface"; 1222 } 1223 } 1225 grouping related-oam-layer { 1226 leaf offset { 1227 type int32 { 1228 range "-255..255"; 1229 } 1230 description 1231 "defines offset (in MD levels) to a related OAM layer 1232 +1 is the layer immediately above 1233 -1 is the layer immediately below"; 1234 } 1235 uses maintenance-domain-id; 1236 uses ma-identifier; 1237 description 1238 "related OAM layer"; 1239 } 1241 grouping interface-status { 1242 description 1243 "collection of interface related status"; 1244 leaf admin-status { 1245 type leafref { 1246 path "/if:interfaces-state/if:interface/if:admin-status"; 1247 } 1248 config false; 1249 description 1250 "oper status from ietf-interface module"; 1251 } 1252 leaf oper-status { 1253 type leafref { 1254 path "/if:interfaces-state/if:interface/if:oper-status"; 1255 } 1256 config false; 1257 description 1258 "oper status from ietf-interface module"; 1259 } 1260 } 1262 grouping connectivity-context { 1263 description 1264 "Grouping defining the connectivity context for an MA; for 1265 example, a VRF for IP, or an LSP for MPLS. This will be 1266 augmented by each protocol who use this component"; 1267 choice connectivity-context { 1268 default "context-null"; 1269 case context-null { 1270 description 1271 "this is a place holder when no context is needed"; 1272 leaf context-null { 1273 type empty; 1274 description 1275 "there is no context define"; 1276 } 1277 } 1278 description 1279 "connectivity context"; 1280 } 1281 } 1283 grouping priority { 1284 description 1285 "Priority used in transmitted packets; for example, in the 1286 TOS/DSCP field in IP or the Traffic Class field in MPLS"; 1287 leaf priority { 1288 type uint8; 1289 description 1290 "priority"; 1291 } 1292 } 1294 grouping flow-entropy { 1295 description 1296 "defines the grouping statement for flow-entropy"; 1297 choice flow-entropy { 1298 default "flow-entropy-null"; 1299 case flow-entropy-null { 1300 description 1301 "this is a place holder when no flow entropy is needed"; 1302 leaf flow-entropy-null { 1303 type empty; 1304 description 1305 "there is no flow entropy defined"; 1306 } 1307 } 1308 description 1309 "Flow entropy"; 1310 } 1311 } 1313 grouping measurement-timing-group { 1314 description 1315 "This grouping includes objects used for 1316 proactive and on-demand 1317 scheduling of PM measurement sessions."; 1319 container start-time { 1320 description 1321 "This container defines the session start time."; 1322 choice start-time { 1323 description 1324 "Measurement sessions tart time can be immediate, relative, or 1325 absolute."; 1326 container immediate { 1327 presence "Start the measurement session immediately."; 1328 description 1329 "Start Time of probe immediately."; 1330 } 1331 leaf absolute { 1332 type yang:date-and-time; 1333 description 1334 "This objects specifies the scheduled start time 1335 to perform the on-demand monitoring operations."; 1336 } 1337 } 1338 } 1340 container stop-time { 1341 description 1342 "This container defines the session stop time."; 1343 choice stop-time { 1344 description 1345 "Measurement session stop time can be none, or absolute."; 1346 container none { 1347 presence "Never end the measurement session."; 1348 description 1349 "Stop time is never to end."; 1351 } 1353 leaf absolute { 1354 type yang:date-and-time; 1355 description 1356 "This objects specifies the scheduled stop time 1357 to perform the on-demand monitoring operations."; 1358 } 1359 } 1360 } 1361 } 1363 container domains { 1364 description 1365 "Contains configuration related data. Within the container 1366 is list of fault domains. Wihin each domian has List of MA."; 1367 list domain { 1368 key "technology MD-name-string"; 1369 ordered-by system; 1370 description 1371 "Define the list of Domains within the IETF-OAM"; 1372 uses maintenance-domain-id; 1373 uses MD-name; 1374 leaf md-level { 1375 type MD-level; 1376 description 1377 "Defines the MD-Level"; 1378 } 1379 container MAs { 1380 description 1381 "This container defines MA, within that have multiple MA 1382 and within MA have MEP, MIP"; 1383 list MA { 1384 key "MA-name-string"; 1385 ordered-by system; 1386 uses ma-identifier; 1387 uses MA-name; 1388 uses connectivity-context; 1389 leaf mep-direction { 1390 type MEP-direction; 1391 mandatory true; 1392 description 1393 "Direction for MEPs in this MA"; 1394 } 1395 leaf interval { 1396 type Interval; 1397 default "0"; 1398 description 1399 "Defines default Keepalive/CC Interval. May be 1400 overridden for specific sessions if supported by the 1401 protocol."; 1402 } 1403 leaf loss-threshold { 1404 type uint32; 1405 default "3"; 1406 description 1407 "number of consecutive Keepalive/CC messages missed 1408 before declaring loss of continuity fault. This is 1409 monitored per each remote MEP session"; 1410 } 1411 leaf ttl { 1412 type uint8; 1413 default "255"; 1414 description 1415 "Time to Live"; 1416 } 1417 uses flow-entropy { 1418 description 1419 "Default flow entropy in this MA, which may be 1420 overridden for particular MEPs, sessions or 1421 operations"; 1422 } 1423 uses priority { 1424 description 1425 "Default priority for this MA, which may be overridden 1426 for particular MEPs, sessions or operations."; 1427 } 1428 list MEP { 1429 key "mep-name"; 1430 ordered-by system; 1431 description 1432 "contain list of MEPS"; 1433 uses MEP; 1434 uses interface-status { 1435 description 1436 "status of associated interface"; 1437 } 1438 uses flow-entropy; 1439 uses priority; 1440 list session { 1441 key "session-cookie"; 1442 ordered-by user; 1443 description 1444 "Monitoring session to/from a particular remote MEP. 1445 Depending on the protocol, this could represent CC 1446 messages received from a single remote MEP (if the 1447 protocol uses multicast CCs) or a target to which 1448 unicast echo request CCs are sent and from which 1449 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 MEPs or multiple sessions to 1456 the same remote MEP."; 1457 } 1458 leaf ttl { 1459 type uint8; 1460 default "255"; 1461 description 1462 "Time to Live."; 1463 } 1464 leaf interval { 1465 type Interval; 1466 description 1467 "Transmission interval for CC packets for this 1468 session."; 1469 } 1470 leaf enable { 1471 type boolean; 1472 default "false"; 1473 description 1474 "enable or disable a monitor session"; 1475 } 1476 leaf ecmp-choice { 1477 type ecmp-choices; 1478 description 1479 "0 means use the specified interface 1480 1 means use round robin"; 1481 } 1482 leaf source-mep { 1483 type MEP-name; 1484 description 1485 "Source MEP for this session, if applicable"; 1486 } 1487 container destination-mep { 1488 uses MEP-ID; 1489 description 1490 "Destination MEP"; 1491 } 1492 container destination-mep-address { 1493 uses mp-address; 1494 description 1495 "Destination MEP Address"; 1496 } 1497 uses connectivity-context; 1498 uses flow-entropy; 1499 uses priority; 1500 list outgoing-interface { 1501 key "interface"; 1502 leaf interface { 1503 type leafref { 1504 path "/if:interfaces/if:interface/if:name"; 1505 } 1506 description 1507 "Outgoing Interface"; 1508 } 1509 description 1510 "outgoing interfaces"; 1511 } 1512 } 1513 } 1514 list MIP { 1515 key "interface"; 1516 uses MIP; 1517 description 1518 "Maintenance Intermediate Point"; 1519 } 1520 list related-oam-layer { 1521 key "offset"; 1522 description 1523 "List of OAM layers above and below that are related to 1524 current MA. This allow users to easily navigate up and 1525 down to efficiently troubleshoot a connectivity 1526 issue"; 1527 uses related-oam-layer; 1528 } 1529 description 1530 "Maintenance Association list"; 1531 } 1532 } 1533 } 1534 } 1535 notification defect-condition-notification { 1536 description 1537 "When defect condition is met this notificiation is sent"; 1538 uses maintenance-domain-id { 1539 description 1540 "defines the MD (Maintenance Domain) identifier, which is the 1541 Generic MD-name-string and the technology."; 1542 } 1543 uses ma-identifier; 1544 leaf mep-name { 1545 type MEP-name; 1546 description 1547 "Indicate which MEP is seeing the error"; 1548 } 1549 leaf defect-type { 1550 type identityref { 1551 base defect-types; 1552 } 1553 description 1554 "The currently active defects on the specific MEP."; 1555 } 1556 container generating-mepid { 1557 uses MEP-ID; 1558 description 1559 "Who is generating the error (if known) if 1560 unknown make it 0."; 1561 } 1562 uses error-message { 1563 description 1564 "Error message to indicate more details."; 1565 } 1566 } 1567 rpc continuity-check { 1568 description 1569 "Generates continuity-check as per RFC7276 Table 4."; 1570 input { 1571 uses maintenance-domain-id { 1572 description 1573 "defines the MD (Maintenance Domain) identifier, which is 1574 the generic 1575 MD-name-string and the technology."; 1576 } 1577 uses ma-identifier { 1578 description 1579 "identfies the Maintenance association"; 1580 } 1581 uses flow-entropy; 1582 uses priority; 1583 leaf ttl { 1584 type uint8; 1585 default "255"; 1586 description 1587 "Time to Live"; 1588 } 1589 uses session-type; 1590 leaf ecmp-choice { 1591 type ecmp-choices; 1592 description 1593 "0 means use the specified interface 1594 1 means use round robin"; 1595 } 1596 leaf sub-type { 1597 type identityref { 1598 base command-sub-type; 1599 } 1600 description 1601 "defines different command types"; 1602 } 1603 list outgoing-interfaces { 1604 key "interface"; 1605 leaf interface { 1606 type if:interface-ref; 1607 description 1608 "outgoing interface"; 1609 } 1610 description 1611 "outgoing Interfaces"; 1612 } 1613 leaf source-mep { 1614 type MEP-name; 1615 description 1616 "Source MEP"; 1617 } 1618 container destination-mp { 1619 uses mp-address; 1620 uses MEP-ID { 1621 description "Only applicable if the destination is a MEP"; 1622 } 1623 description 1624 "Destination MEP"; 1625 } 1626 leaf count { 1627 type uint32; 1628 default "3"; 1629 description 1630 "Number of ping echo request message to send"; 1631 } 1632 leaf interval { 1633 type Interval; 1634 description 1635 "Interval between echo requests"; 1636 } 1637 leaf packet-size { 1638 type uint32 { 1639 range "64..10000"; 1640 } 1641 default "64"; 1642 description 1643 "Size of ping echo request packets, in octets"; 1644 } 1645 } 1646 output { 1647 uses monitor-stats { 1648 description 1649 "Stats of continuity check is same as that of 1650 monitor sessions"; 1651 } 1652 } 1653 } 1655 rpc continuity-verification { 1656 if-feature connectivity-verification; 1657 description 1658 "Generates continuity-verification as per RFC7276 Table 4."; 1659 input { 1660 uses maintenance-domain-id { 1661 description 1662 "defines the MD (Maintenance Domain) identifier, which is 1663 the generic 1664 MD-name-string and the technology."; 1665 } 1666 uses ma-identifier { 1667 description 1668 "identfies the Maintenance association"; 1669 } 1670 uses flow-entropy; 1671 uses priority; 1672 leaf ttl { 1673 type uint8; 1674 default "255"; 1675 description 1676 "Time to Live"; 1677 } 1678 uses session-type; 1679 leaf ecmp-choice { 1680 type ecmp-choices; 1681 description 1682 "0 means use the specified interface 1683 1 means use round robin"; 1684 } 1685 leaf sub-type { 1686 type identityref { 1687 base command-sub-type; 1688 } 1689 description 1690 "defines different command types"; 1691 } 1692 list outgoing-interfaces { 1693 key "interface"; 1694 leaf interface { 1695 type if:interface-ref; 1696 description 1697 "outgoing interface"; 1698 } 1699 description 1700 "outgoing Interfaces"; 1701 } 1702 leaf source-mep { 1703 type MEP-name; 1704 description 1705 "Source MEP"; 1706 } 1707 container destination-mp { 1708 uses mp-address; 1709 uses MEP-ID { 1710 description "Only applicable if the destination is a MEP"; 1711 } 1712 description 1713 "Destination MEP"; 1714 } 1715 leaf count { 1716 type uint32; 1717 default "3"; 1718 description 1719 "Number of ping echo request message to send"; 1720 } 1721 leaf interval { 1722 type Interval; 1723 description 1724 "Interval between echo requests"; 1725 } 1726 leaf packet-size { 1727 type uint32 { 1728 range "64..10000"; 1729 } 1730 default "64"; 1731 description 1732 "Size of ping echo request packets, in octets"; 1733 } 1734 } 1735 output { 1736 uses monitor-stats { 1737 description 1738 "Stats of continuity check is same as that of 1739 monitor sessions"; 1740 } 1741 } 1742 } 1743 rpc path-discovery { 1744 description 1745 "Generates Trace-route or Path Trace and return response. 1746 Referencing RFC7276 for common Toolset name, for IP it's 1747 Traceroute, for MPLS OAM it's Traceroute mode, for 1748 MPLS-TP OAM it's Route Tracing, for Pseudowire OAM it's 1749 LSP Ping, and for TRILL OAM It's Path Tracing tool. 1750 Starts with TTL 1751 of one and increment by one at each hop. Untill destination 1752 reached or TTL reach max valune"; 1753 input { 1754 uses maintenance-domain-id { 1755 description 1756 "defines the MD (Maintenance Domain) identifier, which is 1757 the generic MD-name-string and the technology."; 1758 } 1759 uses ma-identifier { 1760 description 1761 "identfies the Maintenance association"; 1762 } 1763 uses flow-entropy; 1764 uses priority; 1765 leaf ttl { 1766 type uint8; 1767 default "255"; 1768 description 1769 "Time to Live"; 1770 } 1771 uses session-type; 1772 leaf command-sub-type { 1773 type identityref { 1774 base command-sub-type; 1775 } 1776 description 1777 "defines different command types"; 1778 } 1779 leaf ecmp-choice { 1780 type ecmp-choices; 1781 description 1782 "0 means use the specified interface 1783 1 means use round robin"; 1784 } 1785 list outgoing-interfaces { 1786 key "interface"; 1787 leaf interface { 1788 type if:interface-ref; 1789 description 1790 "Interface."; 1791 } 1792 description 1793 "Outgoing interface list."; 1794 } 1795 leaf source-mep { 1796 type MEP-name; 1797 description 1798 "Source MEP"; 1799 } 1800 container destination-mp { 1801 uses mp-address; 1802 uses MEP-ID { 1803 description "Only applicable if the destination is a MEP"; 1804 } 1805 description 1806 "Destination MEP"; 1807 } 1808 leaf count { 1809 type uint32; 1810 default "1"; 1811 description 1812 "Number of traceroute probes to send. In protocols where a 1813 separate message is sent at each TTL, this is the number 1814 of packets to send at each TTL."; 1815 } 1816 leaf interval { 1817 type Interval; 1818 description 1819 "Interval between echo requests"; 1820 } 1821 } 1822 output { 1823 list response { 1824 key "response-index"; 1825 leaf response-index { 1826 type uint8; 1827 description 1828 "Arbitrary index for the response. In protocols that 1829 guarantee there is only a single response at each TTL 1830 (eg IP Traceroute), the TTL can be used as the response 1831 index."; 1832 } 1833 leaf ttl { 1834 type uint8; 1835 description 1836 "Time to Live"; 1837 } 1838 description 1839 "Time to Live"; 1840 container destination-mp { 1841 description "MP from which the response has been received"; 1842 uses mp-address; 1843 uses MEP-ID { 1844 description 1845 "Only applicable if the destination is a MEP"; 1846 } 1847 } 1848 uses monitor-stats { 1849 description 1850 "If count is 1, there is a single delay value reported."; 1851 } 1852 } 1853 description 1854 "List of response."; 1855 } 1856 } 1857 } 1859 YANG module of OAM 1861 1863 6. Base Mode 1865 The Base Mode defines default configuration that MUST be present in 1866 the devices that comply with this document. Base Mode allows users 1867 to have "zero-touch" experience. Several parameters require 1868 technology specific definition. 1870 6.1. MEP Address 1872 In the Base Mode of operation, the MEP Address is by default the IP 1873 address of the interface on which the MEP is located. 1875 6.2. MEP ID for Base Mode 1877 In the Base Mode of operation, each device creates a single UP MEP 1878 associated with a virtual OAM port with no physical layer (NULL PHY). 1879 The MEPID associated with this MEP is zero (0). The choice of MEP-ID 1880 zero is explained below. 1882 MEPID is 2 octet field by default. It is never used on the wire 1883 except when using CCM. Ping, traceroute and session monitoring does 1884 not use the MEPID on its message header. It is important to have 1885 method that can derive MEP ID of base mode in an automatic manner 1886 with no user intervention. IP address cannot be directly used for 1887 this purpose as the MEP ID is much smaller field. For Base Mode of 1888 operation we propose to use MEP ID zero (0) as the default MEP-ID. 1890 CCM packet use MEP-ID on the payload. CCM MUST NOT be used in the 1891 Base Mode. Hence CCM MUST be disabled on the Maintenance Association 1892 of the Base Mode. 1894 If CCM is required, users MUST configure a separate Maintenance 1895 association and assign unique value for the corresponding MEP IDs. 1897 [IEEE802.1Q] CFM defines MEP ID as an unsigned integer in the range 1 1898 to 8191. In this document we propose to extend the range to 0 to 1899 65535. Value 0 is reserved for MEP ID of Base Mode operation and 1900 MUST NOT be used for other purposes. 1902 6.3. Maintenance Domain 1904 Default MD-LEVEL is set to 3. 1906 6.4. Maintenance Association 1908 MAID [IEEE802.1Q] has a flexible format and includes two parts: 1909 Maintenance Domain Name and Short MA name. In the Based Mode of 1910 operation, the value of the Maintenance Domain Name must be the 1911 character string "GenericBaseMode" (excluding the quotes "). In Base 1912 Mode operation Short MA Name format is set to 2-octet integer format 1913 (value 3 in Short MA Format field [IEEE802.1Q]) and Short MA name set 1914 to 65532 (0xFFFC). 1916 7. Note 1918 This section will be removed or subject to change in the future if 1919 any agreement is reached. As per investigation of RFC7276 for 1920 performance Monitoring for Loss and Delay are defined for MPLS 1921 OAM(RFC6374), OWAMP (RFC4676) and TWAMP (RFC5357) and TRILL OAM 1922 (RFC7456). In case of Performance Monitoring Statistics are common 1923 between these technologies thus generic Yang model for Performance 1924 will be worked out through separate draft with Augmentation of 1925 Generic LIME model. In case of Other Function, it's technology 1926 specific and thus should be dealt in technology specific Yang model 1927 instead of Generic Model. 1929 8. Security Considerations 1931 TBD. 1933 9. IANA Considerations 1935 This document registers the following namespace URI in the IETF XML 1936 registry. 1938 URI:TBD 1940 10. References 1942 10.1. Normative References 1944 [IEEE802.1Q] 1945 "Media Access Control (MAC) Bridges and Virtual Bridged 1946 Local Area Networks", IEEE Std 802.1Q-2011, August 2011. 1948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1949 Requirement Levels", BCP 14, RFC 2119, March 1997. 1951 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1952 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1953 6241, June 2011. 1955 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 1956 September 1981. 1958 10.2. Informative References 1960 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1961 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1963 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1964 Delay Metric for IPPM", RFC 2681, September 1999. 1966 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1967 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1968 February 2006. 1970 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1971 Message Protocol (ICMPv6) for the Internet Protocol 1972 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1974 [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol 1975 (DHCPv4 and DHCPv6) Option for Civic Addresses 1976 Configuration Information", RFC 4676, October 2006. 1978 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1979 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1980 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 1982 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 1983 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1984 Specification", RFC 6325, July 2011. 1986 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1987 Maintenance Framework for MPLS-Based Transport Networks", 1988 RFC 6371, September 2011. 1990 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1991 Measurement for MPLS Networks", RFC 6374, September 2011. 1993 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake, 1994 "Transparent Interconnection of Lots of Links (TRILL) 1995 Operations, Administration, and Maintenance (OAM) 1996 Framework", RFC 7174, May 2014. 1998 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1999 Weingarten, "An Overview of Operations, Administration, 2000 and Maintenance (OAM) Tools", RFC 7276, June 2014. 2002 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., 2003 Eastlake, D., Aldrin, S., and Y. Li, "Transparent 2004 Interconnection of Lots of Links (TRILL): Fault 2005 Management", RFC 7455, March 2015. 2007 [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and 2008 D. Eastlake, "Loss and Delay Measurement in Transparent 2009 Interconnection of Lots of Links (TRILL)", RFC 7456, March 2010 2015. 2012 [Y.1731] "OAM functions and mechanisms for Ethernet based 2013 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 2015 Appendix A. Acknowledgments 2017 Giles Heron came up with the idea of developing a YANG model as a way 2018 of creating a unified OAM API set (interface), work in this document 2019 is largely an inspiration of that. Alexander Clemm provided many 2020 valuable tips, comments and remarks that helped to refine the YANG 2021 model presented in this document. 2023 Carlos Pignataro, David Ball and others participated and contributed 2024 to this document. 2026 Authors' Addresses 2028 Tissa Senevirathne 2029 CISCO Systems 2030 375 East Tasman Drive. 2031 San Jose, CA 95134 2032 USA 2034 Phone: 408-853-2291 2035 Email: tsenevir@cisco.com 2037 Norman Finn 2038 CISCO Systems 2039 510 McCarthy Blvd 2040 Milpitas, CA 95035 2041 USA 2043 Email: nfinn@cisco.com 2045 Deepak Kumar 2046 CISCO Systems 2047 510 McCarthy Blvd 2048 Milpitas, CA 95035 2049 USA 2051 Email: dekumar@cisco.com 2052 Samer Salam 2053 CISCO Systems 2054 595 Burrard St. Suite 2123 2055 Vancouver, BC V7X 1J1 2056 Canada 2058 Email: ssalam@cisco.com 2060 Qin Wu 2061 Huawei 2062 101 Software Avenue, Yuhua District 2063 Nanjing, Jiangsu 210012 2064 China 2066 Email: bill.wu@huawei.com 2068 Michael Wang 2069 Huawei Technologies,Co.,Ltd 2070 101 Software Avenue, Yuhua District 2071 Nanjing 210012 2072 China 2074 Email: wangzitao@huawei.com