idnits 2.17.1 draft-tissa-lime-yang-oam-model-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2015) is 3159 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MA-name-string' is mentioned on line 491, but not defined ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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, Ed. 5 Expires: February 5, 2016 S. Salam 6 Cisco 7 Q. Wu, Ed. 8 M. Wang 9 Huawei 10 August 4, 2015 12 Generic YANG Data Model for Operations, Administration, and Maintenance 13 (OAM) 14 draft-tissa-lime-yang-oam-model-06 16 Abstract 18 This document presents base YANG Data model for OAM. It provides a 19 protocol-independent and technology-independent abstraction of key 20 OAM constructs. Based model presented here can be extended to 21 include technology specific details. This is leading to uniformity 22 between OAM technologies and support nested OAM workflows (i.e., 23 performing OAM functions at different layers through a unified 24 interface). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 5, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 4 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Architecture of Generic YANG Model for OAM . . . . . . . . . 6 64 4. Overview of the OAM Model . . . . . . . . . . . . . . . . . . 7 65 4.1. Maintenance Domain (MD) configuration . . . . . . . . . . 8 66 4.2. Maintenance Association (MA) configuration . . . . . . . 8 67 4.3. Maintenance Endpoint (MEP) configuration . . . . . . . . 9 68 4.4. rpc definitions . . . . . . . . . . . . . . . . . . . . . 9 69 4.5. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 12 70 5. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 71 6. Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 41 72 6.1. MEP Address . . . . . . . . . . . . . . . . . . . . . . . 41 73 6.2. MEP ID for Base Mode . . . . . . . . . . . . . . . . . . 42 74 6.3. Maintenance Domain . . . . . . . . . . . . . . . . . . . 42 75 6.4. Maintenance Association . . . . . . . . . . . . . . . . . 42 76 7. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 44 82 11.2. Informative References . . . . . . . . . . . . . . . . . 45 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 85 1. Introduction 87 Operations, Administration, and Maintenance (OAM) are important 88 networking functions that allow operators to: 90 1. Monitor networks connections (Connectivity Verification, 91 Continuity Check). 93 2. Troubleshoot failures (Fault verification and localization). 95 3. Monitor Performance 96 An overview of OAM tools is presented at [RFC7276]. 98 Ping and Traceroute [RFC792], [RFC4443] are well-known fault 99 verification and isolation tools, respectively, for IP networks. 100 Over the years, different technologies have developed similar tools 101 for similar purposes. 103 [IEEE802.1Q] Connectivity Fault Management is a well-established OAM 104 standard that is widely adopted for Ethernet networks. ITU-T 105 [Y.1731][Y.1731], MEF Service OAM, MPLS-TP [RFC6371], TRILL 106 [RFC7455][RFC7455] all define OAM methods based on manageability 107 frame work of [IEEE802.1Q] [IEEE802.1Q]CFM. 109 Given the wide adoption of the underlying OAM concepts defined in 110 [IEEE802.1Q][IEEE802.1Q] CFM, it is a reasonable choice to develop 111 the unified management framework based on those concepts. In this 112 document, we take the [IEEE802.1Q][IEEE802.1Q] CFM model and extend 113 it to a technology independent framework and build the corresponding 114 YANG model accordingly. The YANG model presented in this document is 115 the base model and supports generic continuity check, connectivity 116 verification and path discovery. The generic YANG model for OAM is 117 designed such that it can be extended to cover various technologies. 118 Technology dependent nodes and RPC (remote process call) commands are 119 defined in technology specific YANG models, which use and extend the 120 base model defined here. As an example, VXLAN uses source UDP port 121 number for flow entropy, while MPLS [RFC4379] uses IP addresses or 122 the label stack for flow entropy in the hashing for multipath 123 selection. To capture this variation, corresponding YANG models 124 would define the applicable structures as augmentation to the generic 125 base model presented here. This accomplishes three purposes: first 126 it keeps each YANG model smaller and manageable. Second, it allows 127 independent development of corresponding YANG models. Third, 128 implementations can limit support to only the applicable set of YANG 129 models. (e.g. TRILL RBridge may only need to implement Generic model 130 and the TRILL YANG model). 132 All implementations that follow the YANG framework presented in this 133 document MUST implement the generic YANG model presented here. 135 The YANG data model presented in this document is generated at the 136 management layer. Encapsulations and state machines may differ 137 according to each OAM protocol. A user who wishes to issues a Ping 138 command or a Traceroute or initiate a performance monitoring session 139 can do so in the same manner regardless of the underlying protocol or 140 technology or specific vendor implementation. 142 As an example, consider a scenario where an IP ping from device A to 143 Device B failed. Between device A and B there are IEEE 802.1 bridges 144 a,b and c. Let's assume a,b and c are using [IEEE802.1Q] CFM. A 145 user upon detecting the IP layer ping failures may decide to drill 146 down to the Ethernet layer and issue the corresponding fault 147 verification (LBM) and fault isolation (LTM) tools, using the same 148 API. This ability to go down to the same portion of path atlower 149 layer for Fault localization and troubleshooting is referred to as 150 "nested OAM workflow" and is a useful concept that leads to efficient 151 network troubleshooting and maintenance. The OAM YANG model 152 presented in this document facilitates that without needing changes 153 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 The following notations are used within the data tree and carry the 162 meaning as below. 164 Each node is printed as: 166 168 is one of: 169 + for current 170 x for deprecated 171 o for obsolete 173 is one of: 175 rw for configuration data 176 ro for non-configuration data 177 -x for rpcs 178 -n for notifications 180 is the name of the node 182 If the node is augmented into the tree from another module, its name 183 is printed as :. 185 is one of: 187 ? for an optional leaf or choice 188 ! for a presence container 189 * for a leaf-list or list 190 [] for a list's keys 192 is the name of the type for leafs and leaf-lists 194 In this document, these words will appear with that interpretation 195 only when in ALL CAPS. Lower case uses of these words are not to be 196 interpreted as carrying RFC-2119 significance. 198 2.1. Terminology 200 CCM - Continuity Check Message [IEEE802.1Q]. 202 ECMP - Equal Cost Multipath. 204 LBM - Loopback Message [IEEE802.1Q]. 206 MP - Maintenance Point [IEEE802.1Q]. 208 MEP - Maintenance End Point [RFC7174] [IEEE802.1Q] [RFC6371]. 210 MIP - Maintenance Intermediate Point [RFC7174] [IEEE802.1Q] 211 [RFC6371]. 213 MA - Maintenance Association [IEEE802.1Q] [RFC7174]. 215 MD - Maintenance Domain [IEEE802.1Q] 217 MTV - Multi-destination Tree Verification Message. 219 OAM - Operations, Administration, and Maintenance [RFC6291]. 221 TRILL - Transparent Interconnection of Lots of Links [RFC6325]. 223 CFM - Connectivity Fault Management [RFC7174] [IEEE802.1Q]. 225 RPC - Remote Process Call. 227 CC - Continuity Check [RFC7276]. Continuity Checks are used to 228 verify that a destination is reachable and therefore also 229 referred to as reachability verification. 231 CV - Connectivity Verification [RFC7276].Connectivity 232 Verifications are also referred to as path verification and 233 used to verify not only that the two MPs are connected, but 234 also that they are connected through the expected path, 235 allowing detection of unexpected topology changes. 237 3. Architecture of Generic YANG Model for OAM 239 In this document we define a generic YANG model for OAM. The YANG 240 model defined here is generic such that other technologies can extend 241 it for technology specific needs. The Generic YANG model acts as the 242 root for other OAM YANG models. This allows users to traverse 243 between OAM of different technologies at ease through a uniform API 244 set. This is also provides a nested OAM workflow. Figure 1 depicts 245 the relationship of different OAM YANG models to the Generic YANG 246 Model for OAM. Some technologies may have different sub- 247 technologies. As an example, consider Network Virtualization 248 Overlays. These could employ either VXLAN or NVGRE as encapsulation. 249 The Generic YANG model for OAM provides a framework where technology- 250 specific YANG models can inherit constructs from the base YANG models 251 without needing to redefine them within the sub-technology. 253 Figure 1 depicts relationship of different YANG modules. 255 +-+-+-+-+-+ 256 | gen | 257 |OAM YANG | 258 +-+-+-+-+-+ 259 | 260 O 261 | 262 +---------------------------------------------------------+ 263 | | | | | 264 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 265 | TRILL | | NVO3 | | MPLS | | IP | . . .| foo | 266 |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | 267 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 268 | | | | | 269 | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ 270 | | NVO3 | | MPLS | | . . .| foo | 271 | |sub tech | |sub tech | | |sub tech | 272 | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ 273 | | | | | 274 | | | | | 275 +------------------------------------------------------------+ 276 | Uniform API | 277 +------------------------------------------------------------+ 279 Relationship of OAM YANG model to generic (base) YANG model 281 4. Overview of the OAM Model 283 In this document we adopt the concepts of the [IEEE802.1Q] CFM model 284 and structure it such that it can be adapted to different 285 technologies. 287 At the top of the Model is the Maintenance Domain. Each Maintenance 288 Domain is associated with a Maintenance Name and a Domain Level. 290 Under each Maintenance Domain there is one or more Maintenance 291 Association (MA). In IP, the MA can be per IP Subnet, in NVO3 this 292 can be per VNI and for TRILL this can be per Fine-Grained Label or 293 for VPLS this can be per VPLS instance. 295 Under each MA, there can be two or more MEPs (Maintenance Association 296 End Points). MEPs are addressed by their respective technology 297 specific address identifiers. The YANG model presented here provides 298 flexibility to accommodate different addressing schemes. 300 In the vertical direction orthogonal to the Maintenance Domain, 301 presented are the commands. Those, in YANG terms, are the rpc 302 commands. These rpc commands provide uniform APIs for continuity 303 check,connectivity verification, path discovery and their equivalents 304 as well as other OAM commands. 306 The generic YANG model defined here does not require explicit 307 configuration of OAM entities prior to using any of the OAM tools.The 308 OAM tools used here are limited to OAM toolset specified in section 309 5.1 of [RFC7276]. Users of Ping and Traceroute tools within IP 310 devices are expecting ability to use OAM tools with no explicit 311 configuration. In order to facilitate zero- touch experience, this 312 document defines a default mode of OAM. The default mode of OAM is 313 referred to as the Base Mode and specifies default values for each of 314 model parameters, such as Maintenance Domain Level, Name of the 315 Maintenance Association and Addresses of MEP and so on. The default 316 values of these depend on the technology. Base Mode for TRILL is 317 defined in [RFC7455]. Base mode for other technologies such as NVO3, 318 MPLS and future extensions will be defined in their corresponding 319 documents. 321 It is important to note that, no specific enhancements are needed in 322 the YANG model to support Base Mode. Implementations that comply 323 with this document, by default implement the data nodes of the 324 applicable technology. Data nodes of the Base Mode are read-only 325 nodes. 327 4.1. Maintenance Domain (MD) configuration 329 The container "domains" is the top level container within the gen-oam 330 module. Within the container "domains", separate list is maintained 331 per MD. The MD list uses the key MD-name-string for indexing. MD- 332 name-string is a leaf and derived from type string. Additional name 333 formats as defined in [IEEE802.1Q] or other standards can be included 334 by association of the MD-name-format with an identity-ref. MD-name- 335 format indicates the format of the augmented MD-names. MD-name is 336 presented as choice/case construct. Thus, it is easily augmentable 337 by derivative work. 339 module: ietf-gen-oam 340 +--rw domains 341 +--rw domain* [technology MD-name-string] 342 +--rw technology identityref 343 +--rw MD-name-string MD-name-string 344 +--rw MD-name-format? identityref 345 +--rw (MD-name)? 346 | +--:(MD-name-null) 347 | +--rw MD-name-null? empty 348 +--rw md-level MD-level . 350 Snippet of data hierarchy related to OAM domains 352 4.2. Maintenance Association (MA) configuration 354 Within a given Maintenance Domain there can be one or more 355 Maintenance Associations (MA). MAs are represented as a list and 356 indexed by the MA-name-string. Similar to MD-name defined 357 previously, additional name formats can be added by augmenting the 358 name-format identity-ref and adding applicable case statements to MA- 359 name. 361 module: ietf-gen-oam 362 +--rw domains 363 +--rw domain* [technology MD-name-string] 364 . 365 . 366 +--rw MAs 367 +--rw MA* [MA-name-string] 368 +--rw MA-name-string MA-name-string 369 +--rw MA-name-format? identityref 370 +--rw (MA-name)? 371 | +--:(MA-name-null) 372 | +--rw MA-name-null? empty 374 Snippet of data hierarchy related to Maintenance Associations (MA) 376 4.3. Maintenance Endpoint (MEP) configuration 378 Within a given Maintenance Association (MA), there can be one or more 379 Maintenance End Points (MEP). MEPs are represented as a list within 380 the data hierarchy and indexed by the key MEP-name. 382 module: ietf-gen-oam 383 +--rw domains 384 +--rw domain* [technology MD-name-string] 385 +--rw technology identityref 386 . 387 . 388 +--rw MAs 389 +--rw MA* [MA-name-string] 390 +--rw MA-name-string MA-name-string 391 . 392 . 393 +--rw MEP* [mep-name] 394 | +--rw mep-name MEP-name 395 | +--rw (MEP-ID)? 396 | | +--:(MEP-ID-int) 397 | | +--rw MEP-ID-int? int32 398 | | +--:(MEP-ID-tlv) 399 | | +--rw MEP-ID-type? int16 400 | | +--rw MEP-ID-len? int16 401 | | +--rw MEP-ID-value? binary 402 | +--rw MEP-ID-format? identityref 403 | +--rw (mp-address)? 404 | | +--:(mac-address) 405 | | | +--rw mac-address? yang:mac-address 406 | | +--:(ipv4-address) 407 | | | +--rw ipv4-address? inet:ipv4-address 408 | | +--:(ipv6-address) 409 | | +--rw ipv6-address? inet:ipv6-address 410 . . 411 . . 412 . . 414 Snippet of data hierarchy related to Maintenance Endpoint (MEP) 416 4.4. rpc definitions 418 The rpc model facilitates issuing commands to a NETCONF server (in 419 this case to the device that need to execute the OAM command) and 420 obtain a response. rpc model defined here abstracts OAM specific 421 commands in a technology independent manner. 423 There are several rpc commands defined for the purpose of OAM. In 424 this section we present a snippet of the continuity check command for 425 illustration purposes. Please refer to Section 4 for the complete 426 data hierarchy and Section 5 for the YANG model. 428 module: ietf-gen-oam 429 +--rw domains 430 +--rw domain* [technology MD-name-string] 431 +--rw technology identityref 432 . 433 . 434 rpcs: 435 +---x continuity-check 436 | +--ro input 437 | | +--ro technology identityref 438 | | +--ro MD-name-string MD-name-string 439 | | +--ro MA-name-string? MA-name-string 440 | | +--ro (flow-entropy)? 441 | | | +--:(flow-entropy-null) 442 | | | +--ro flow-entropy-null? empty 443 | | +--ro priority? uint8 444 | | +--ro ttl? uint8 445 | | +--ro session-type enumeration 446 | | +--ro ecmp-choice? ecmp-choices 447 | | +--ro sub-type? identityref 448 | | +--ro outgoing-interfaces* [interface] 449 | | | +--ro interface if:interface-ref 450 | | +--ro source-mep? MEP-name 451 | | +--ro destination-mp 452 | | | +--ro (mp-address)? 453 | | | | +--:(mac-address) 454 | | | | | +--ro mac-address? yang:mac-address 455 | | | | +--:(ipv4-address) 456 | | | | | +--ro ipv4-address? inet:ipv4-address 457 | | | | +--:(ipv6-address) 458 | | | | +--ro ipv6-address? inet:ipv6-address 459 | | | +--ro (MEP-ID)? 460 | | | | +--:(MEP-ID-int) 461 | | | | +--ro MEP-ID-int? int32 462 | | | +--ro MEP-ID-format? identityref 463 | | +--ro count? uint32 464 | | +--ro interval? Interval 465 | | +--ro packet-size? uint32 466 | +--ro output 467 | +--ro tx-packt-count? oam-counter32 468 | +--ro rx-packet-count? oam-counter32 469 | +--ro min-delay? oam-counter32 470 | +--ro average-delay? oam-counter32 471 | +--ro max-delay? oam-counter32 473 Snippet of data hierarchy related to rpc call continuity-check 475 4.5. OAM data hierarchy 477 The complete data hierarchy related to the OAM YANG model is 478 presented below. 480 module: ietf-gen-oam 481 +--rw domains 482 +--rw domain* [technology MD-name-string] 483 +--rw technology identityref 484 +--rw MD-name-string MD-name-string 485 +--rw MD-name-format? identityref 486 +--rw (MD-name)? 487 | +--:(MD-name-null) 488 | +--rw MD-name-null? empty 489 +--rw md-level? MD-level 490 +--rw MAs 491 +--rw MA* [MA-name-string] 492 +--rw MA-name-string MA-name-string 493 +--rw MA-name-format? identityref 494 +--rw (MA-name)? 495 | +--:(MA-name-null) 496 | +--rw MA-name-null? empty 497 +--rw (connectivity-context)? 498 | +--:(context-null) 499 | +--rw context-null? empty 500 +--rw mep-direction MEP-direction 501 +--rw interval? Interval 502 +--rw loss-threshold? uint32 503 +--rw ttl? uint8 504 +--rw (flow-entropy)? 505 | +--:(flow-entropy-null) 506 | +--rw flow-entropy-null? empty 507 +--rw priority? uint8 508 +--rw MEP* [mep-name] 509 | +--rw mep-name MEP-name 510 | +--rw (MEP-ID)? 511 | | +--:(MEP-ID-int) 512 | | | +--rw MEP-ID-int? int32 513 | | +--:(MEP-ID-tlv) 514 | | +--rw MEP-ID-type? int16 515 | | +--rw MEP-ID-len? int16 516 | | +--rw MEP-ID-value? binary 517 | +--rw MEP-ID-format? identityref 518 | +--rw (mp-address)? 519 | | +--:(mac-address) 520 | | | +--rw mac-address? yang:mac-address 521 | | +--:(ipv4-address) 522 | | | +--rw ipv4-address? inet:ipv4-address 523 | | +--:(ipv6-address) 524 | | +--rw ipv6-address? inet:ipv6-address 525 | +--rw (connectivity-context)? 526 | | +--:(context-null) 527 | | +--rw context-null? empty 528 | +--rw Interface? if:interface-ref 529 | +--rw (topology)? 530 | | +--:(topo-null) 531 | | +--rw topo-null? empty 532 | +--ro admin-status? leafref 533 | +--ro oper-status? leafref 534 | +--rw (flow-entropy)? 535 | | +--:(flow-entropy-null) 536 | | +--rw flow-entropy-null? empty 537 | +--rw priority? uint8 538 | +--rw session* [session-cookie] 539 | +--rw session-cookie uint32 540 | +--rw ttl? uint8 541 | +--rw interval? Interval 542 | +--rw enable? boolean 543 | +--rw ecmp-choice? ecmp-choices 544 | +--rw source-mep? MEP-name 545 | +--rw destination-mep 546 | | +--rw (MEP-ID)? 547 | | | +--:(MEP-ID-int) 548 | | | | +--rw MEP-ID-int? int32 549 | | | +--:(MEP-ID-tlv) 550 | | | +--rw MEP-ID-type? int16 551 | | | +--rw MEP-ID-len? int16 552 | | | +--rw MEP-ID-value? binary 553 | | +--rw MEP-ID-format? identityref 554 | +--rw destination-mep-address 555 | | +--rw (mp-address)? 556 | | +--:(mac-address) 557 | | | +--rw mac-address? yang:mac-address 558 | | +--:(ipv4-address) 559 | | | +--rw ipv4-address? inet:ipv4-address 560 | | +--:(ipv6-address) 561 | | +--rw ipv6-address? inet:ipv6-address 562 | +--rw (connectivity-context)? 563 | | +--:(context-null) 564 | | +--rw context-null? empty 565 | +--rw (flow-entropy)? 566 | | +--:(flow-entropy-null) 567 | | +--rw flow-entropy-null? empty 568 | +--rw priority? uint8 569 | +--rw outgoing-interface* [interface] 570 | +--rw interface leafref 571 +--rw MIP* [interface] 572 | +--rw interface if:interface-ref 573 +--rw related-oam-layer* [offset] 574 +--rw offset int32 575 +--rw technology identityref 576 +--rw MD-name-string MD-name-string 577 +--rw MA-name-string? MA-name-string 578 rpcs: 579 +---x continuity-check 580 | +--ro input 581 | | +--ro technology identityref 582 | | +--ro MD-name-string MD-name-string 583 | | +--ro MA-name-string? MA-name-string 584 | | +--ro (flow-entropy)? 585 | | | +--:(flow-entropy-null) 586 | | | +--ro flow-entropy-null? empty 587 | | +--ro priority? uint8 588 | | +--ro ttl? uint8 589 | | +--ro session-type-enum? enumeration 590 | | +--ro ecmp-choice? ecmp-choices 591 | | +--ro sub-type? identityref 592 | | +--ro outgoing-interfaces* [interface] 593 | | | +--ro interface if:interface-ref 594 | | +--ro source-mep? MEP-name 595 | | +--ro destination-mp 596 | | | +--ro (mp-address)? 597 | | | | +--:(mac-address) 598 | | | | | +--ro mac-address? yang:mac-address 599 | | | | +--:(ipv4-address) 600 | | | | | +--ro ipv4-address? inet:ipv4-address 601 | | | | +--:(ipv6-address) 602 | | | | +--ro ipv6-address? inet:ipv6-address 603 | | | +--ro (MEP-ID)? 604 | | | | +--:(MEP-ID-int) 605 | | | | | +--ro MEP-ID-int? int32 606 | | | | +--:(MEP-ID-tlv) 607 | | | | +--ro MEP-ID-type? int16 608 | | | | +--ro MEP-ID-len? int16 609 | | | | +--ro MEP-ID-value? binary 610 | | | +--ro MEP-ID-format? identityref 611 | | +--ro count? uint32 612 | | +--ro interval? Interval 613 | | +--ro packet-size? uint32 614 | +--ro output 615 | +--ro tx-packt-count? oam-counter32 616 | +--ro rx-packet-count? oam-counter32 617 | +--ro min-delay? oam-counter32 618 | +--ro average-delay? oam-counter32 619 | +--ro max-delay? oam-counter32 620 +---x continuity-verification {connectivity-verification}? 621 | +--ro input 622 | | +--ro technology identityref 623 | | +--ro MD-name-string MD-name-string 624 | | +--ro MA-name-string? MA-name-string 625 | | +--ro (flow-entropy)? 626 | | | +--:(flow-entropy-null) 627 | | | +--ro flow-entropy-null? empty 628 | | +--ro priority? uint8 629 | | +--ro ttl? uint8 630 | | +--ro session-type-enum? enumeration 631 | | +--ro ecmp-choice? ecmp-choices 632 | | +--ro sub-type? identityref 633 | | +--ro outgoing-interfaces* [interface] 634 | | | +--ro interface if:interface-ref 635 | | +--ro source-mep? MEP-name 636 | | +--ro destination-mp 637 | | | +--ro (mp-address)? 638 | | | | +--:(mac-address) 639 | | | | | +--ro mac-address? yang:mac-address 640 | | | | +--:(ipv4-address) 641 | | | | | +--ro ipv4-address? inet:ipv4-address 642 | | | | +--:(ipv6-address) 643 | | | | +--ro ipv6-address? inet:ipv6-address 644 | | | +--ro (MEP-ID)? 645 | | | | +--:(MEP-ID-int) 646 | | | | | +--ro MEP-ID-int? int32 647 | | | | +--:(MEP-ID-tlv) 648 | | | | +--ro MEP-ID-type? int16 649 | | | | +--ro MEP-ID-len? int16 650 | | | | +--ro MEP-ID-value? binary 651 | | | +--ro MEP-ID-format? identityref 652 | | +--ro count? uint32 653 | | +--ro interval? Interval 654 | | +--ro packet-size? uint32 655 | +--ro output 656 | +--ro tx-packt-count? oam-counter32 657 | +--ro rx-packet-count? oam-counter32 658 | +--ro min-delay? oam-counter32 659 | +--ro average-delay? oam-counter32 660 | +--ro max-delay? oam-counter32 661 +---x path-discovery 662 +--ro input 663 | +--ro technology identityref 664 | +--ro MD-name-string MD-name-string 665 | +--ro MA-name-string? MA-name-string 666 | +--ro (flow-entropy)? 667 | | +--:(flow-entropy-null) 668 | | +--ro flow-entropy-null? empty 669 | +--ro priority? uint8 670 | +--ro ttl? uint8 671 | +--ro session-type-enum? enumeration 672 | +--ro command-sub-type? identityref 673 | +--ro ecmp-choice? ecmp-choices 674 | +--ro outgoing-interfaces* [interface] 675 | | +--ro interface if:interface-ref 676 | +--ro source-mep? MEP-name 677 | +--ro destination-mp 678 | | +--ro (mp-address)? 679 | | | +--:(mac-address) 680 | | | | +--ro mac-address? yang:mac-address 681 | | | +--:(ipv4-address) 682 | | | | +--ro ipv4-address? inet:ipv4-address 683 | | | +--:(ipv6-address) 684 | | | +--ro ipv6-address? inet:ipv6-address 685 | | +--ro (MEP-ID)? 686 | | | +--:(MEP-ID-int) 687 | | | | +--ro MEP-ID-int? int32 688 | | | +--:(MEP-ID-tlv) 689 | | | +--ro MEP-ID-type? int16 690 | | | +--ro MEP-ID-len? int16 691 | | | +--ro MEP-ID-value? binary 692 | | +--ro MEP-ID-format? identityref 693 | +--ro count? uint32 694 | +--ro interval? Interval 695 +--ro output 696 +--ro response* [response-index] 697 +--ro response-index uint8 698 +--ro ttl? uint8 699 +--ro destination-mp 700 | +--ro (mp-address)? 701 | | +--:(mac-address) 702 | | | +--ro mac-address? yang:mac-address 703 | | +--:(ipv4-address) 704 | | | +--ro ipv4-address? inet:ipv4-address 705 | | +--:(ipv6-address) 706 | | +--ro ipv6-address? inet:ipv6-address 707 | +--ro (MEP-ID)? 708 | | +--:(MEP-ID-int) 709 | | | +--ro MEP-ID-int? int32 710 | | +--:(MEP-ID-tlv) 711 | | +--ro MEP-ID-type? int16 712 | | +--ro MEP-ID-len? int16 713 | | +--ro MEP-ID-value? binary 714 | +--ro MEP-ID-format? identityref 715 +--ro tx-packt-count? oam-counter32 716 +--ro rx-packet-count? oam-counter32 717 +--ro min-delay? oam-counter32 718 +--ro average-delay? oam-counter32 719 +--ro max-delay? oam-counter32 720 notifications: 721 +---n defect-condition-notification 722 +--ro technology identityref 723 +--ro MD-name-string MD-name-string 724 +--ro MA-name-string? MA-name-string 725 +--ro mep-name? MEP-name 726 +--ro defect-type? identityref 727 +--ro generating-mepid 728 | +--ro (MEP-ID)? 729 | | +--:(MEP-ID-int) 730 | | | +--ro MEP-ID-int? int32 731 | | +--:(MEP-ID-tlv) 732 | | +--ro MEP-ID-type? int16 733 | | +--ro MEP-ID-len? int16 734 | | +--ro MEP-ID-value? binary 735 | +--ro MEP-ID-format? identityref 736 +--ro (error)? 737 +--:(error-null) 738 | +--ro error-null? empty 739 +--:(error-code) 740 +--ro error-code? int3 741 +--ro error-code? int32 743 data hierarchy of OAM 745 5. OAM YANG Module 747 file "ietf-gen-oam.yang" 749 module ietf-gen-oam { 750 namespace "urn:ietf:params:xml:ns:yang:ietf-gen-oam"; 751 prefix goam; 753 import ietf-interfaces { 754 prefix if; 755 } 756 import ietf-yang-types { 757 prefix yang; 758 } 759 import ietf-inet-types { 760 prefix inet; 761 } 762 organization "IETF LIME Working Group"; 763 contact 764 "Tissa Senevirathne tsenevir@cisco.com"; 765 description 766 "This YANG module defines the generic configuration, 767 statistics and rpc for OAM to be used within IETF in 768 a protocol indpendent manner. Functional level 769 abstraction is indendent with YANG modeling. It is 770 assumed that each protocol maps corresponding 771 abstracts to its native format. 772 Each protocol may extend the YANG model defined 773 here to include protocol specific extensions"; 775 revision 2015-04-09 { 776 description 777 "Initial revision. - 04 version"; 778 reference "draft-tissa-lime-oam"; 779 } 781 /* features */ 782 feature connectivity-verification { 783 description 784 "This feature indicates that the server supports 785 executing connectivity verification OAM command and 786 returning a response. Servers that do not advertise 787 this feature will not support executing 788 connectivity verification command or rpc model for 789 connectivity verification command."; 790 } 792 /* Identities */ 794 identity technology-types { 795 description 796 "this is the base identy of technology types which are 797 vpls, nvo3, TRILL, ipv4, ipv6, mpls, etc"; 798 } 800 identity ipv4 { 801 base technology-types; 802 description 803 "technology of ipv4"; 804 } 806 identity ipv6 { 807 base technology-types; 808 description 809 "technology of ipv6"; 810 } 812 identity command-sub-type { 813 description 814 "defines different rpc command subtypes, e.g rfc792 IP 815 ping, rfc4379 LSP ping, rfc6905 trill OAM, this is 816 optional for most cases"; 817 } 819 identity icmp-rfc792 { 820 base command-sub-type; 821 description 822 "Defines the command subtypes for ICMP ping"; 823 reference "RFC 792"; 824 } 826 identity name-format { 827 description 828 "This defines the name format, IEEE 8021Q CFM defines varying 829 styles of names. It is expected name format as an identity ref 830 to be extended with new types."; 831 } 833 identity name-format-null { 834 base name-format; 835 description 836 "defines name format as null"; 837 } 839 identity identifier-format { 840 description 841 "identifier-format identity can be augmented to define other 842 format identifiers used in MEPD-ID etc"; 843 } 845 identity identifier-format-integer { 846 base identifier-format; 847 description 848 "defines identifier-format to be integer"; 849 } 851 identity defect-types { 852 description 853 "defines different defect types, e.g. remote rdi, 854 mis-connection defect, loss of continuity"; 855 } 856 identity remote-rdi { 857 base defect-types; 858 description 859 " Indicates the aggregate health of the remote MEPs. "; 860 } 862 identity remote-mep-error{ 863 base defect-types; 864 description 865 " Indicates that one or more of the remote MEPs is 866 reporting a failure "; 867 } 868 identity invalue-oam-error{ 869 base defect-types; 870 description 871 "Indicates that one or more invalid OAM messages has been 872 received and that 3.5 times that OAM message transmission 873 interval has not yet expired. 874 "; 875 } 876 identity cross-connect-error{ 877 base defect-types; 878 description 879 " Indicates that one or more cross-connect oam messages has been 880 received and that 3.5 times that OAM message transmission 881 interval has not yet expired. 882 "; 883 } 885 /* typedefs */ 886 typedef MEP-direction { 887 type enumeration { 888 enum "Up" { 889 value 0; 890 description 891 "Indicates when OAM frames are transmitted towards and 892 received from the bridging/routing function."; 893 } 894 enum "Down" { 895 value 1; 896 description 897 "Indicates when OAM frames are transmitted towards and 898 received from the wire."; 899 } 900 } 901 description 902 "MEP direction."; 903 } 904 typedef MEP-name { 905 type string; 906 description 907 "Generic administrative name for a MEP"; 908 } 910 typedef Interval { 911 type uint32; 912 units "milliseconds"; 913 default "1000"; 914 description 915 "Interval between packets in milliseconds. 916 0 means no packets are sent."; 917 } 919 typedef ecmp-choices { 920 type enumeration { 921 enum "ecmp-use-platform-hash" { 922 value 0; 923 description 924 "Use Platform hashing."; 925 } 926 enum "ecmp-use-round-robin" { 927 value 1; 928 description 929 "Use round robin hashing."; 930 } 931 } 932 description 933 "Equal cost multi Path Choices"; 934 } 936 typedef MD-name-string { 937 type string; 938 default ""; 939 description 940 "Generic administrative name for an MD"; 941 } 943 typedef MA-name-string { 944 type string; 945 default ""; 946 description 947 "Generic administrative name for an MA"; 948 } 950 typedef oam-counter32 { 951 type yang:zero-based-counter32; 952 description 953 "defines 32 bit counter for OAM"; 954 } 956 typedef MD-level { 957 type uint32 { 958 range "0..255"; 959 } 960 description 961 "Maintenance Domain level. The level may be restricted in 962 certain protocols (eg to 0-7)"; 963 } 965 /* groupings */ 967 grouping topology { 968 choice topology { 969 case topo-null { 970 description 971 "this is a placeholder when no topology is needed"; 972 leaf topo-null { 973 type empty; 974 description 975 "there is no topology define, it will be defined 976 in technology specific model."; 977 } 978 } 979 description 980 "Topology choices"; 981 } 982 description 983 "Topology"; 984 } 986 grouping error-message { 987 choice error { 988 case error-null { 989 description 990 "this is a placeholder when no error status is needed"; 991 leaf error-null { 992 type empty; 993 description 994 "there is no error define, it will be defined in 995 technology specific model."; 996 } 997 } 998 case error-code { 999 description 1000 "this is a placeholder to display error code."; 1001 leaf error-code { 1002 type int32; 1003 description 1004 "error code is integer value specific to technology."; 1005 } 1006 } 1007 description 1008 "Error Message choices."; 1009 } 1010 description 1011 "Error Message."; 1012 } 1014 grouping mp-address { 1015 choice mp-address { 1016 case mac-address { 1017 leaf mac-address { 1018 type yang:mac-address; 1019 description 1020 "MAC Address"; 1021 } 1022 description 1023 "MAC Address based MP Addressing."; 1024 } 1025 case ipv4-address { 1026 leaf ipv4-address { 1027 type inet:ipv4-address; 1028 description 1029 "Ipv4 Address"; 1030 } 1031 description 1032 "Ip Address based MP Addressing."; 1033 } 1034 case ipv6-address { 1035 leaf ipv6-address { 1036 type inet:ipv6-address; 1037 description 1038 "Ipv6 Address"; 1039 } 1040 description 1041 "ipv6 Address based MP Addressing."; 1042 } 1043 description 1044 "MP Addressing."; 1045 } 1046 description 1047 "MP Address"; 1049 } 1051 grouping maintenance-domain-id { 1052 description 1053 "Grouping containing leaves sufficient to identify an MD"; 1054 leaf technology { 1055 type identityref { 1056 base technology-types; 1057 } 1058 mandatory true; 1060 description 1061 "Defines the technology"; 1062 } 1063 leaf MD-name-string { 1064 type MD-name-string; 1065 mandatory true; 1066 description 1067 "Defines the generic administrative maintenance domain name"; 1068 } 1069 } 1071 grouping MD-name { 1072 leaf MD-name-format { 1073 type identityref { 1074 base name-format; 1075 } 1076 description 1077 "Name format."; 1078 } 1079 choice MD-name { 1080 case MD-name-null { 1081 leaf MD-name-null { 1082 when "../../../MD-name-format = name-format-null" { 1083 description 1084 "MD name format is equal to null format."; 1085 } 1086 type empty; 1087 description 1088 "MD name Null."; 1089 } 1090 } 1091 description 1092 "MD name."; 1093 } 1094 description 1095 "MD name"; 1096 } 1097 grouping ma-identifier { 1098 description 1099 "Grouping containing leaves sufficient to identify an MA"; 1100 leaf MA-name-string { 1101 type MA-name-string; 1102 description 1103 "MA name string."; 1104 } 1105 } 1107 grouping MA-name { 1108 description 1109 "MA name"; 1110 leaf MA-name-format { 1111 type identityref { 1112 base name-format; 1113 } 1114 description 1115 "Ma name format"; 1116 } 1117 choice MA-name { 1118 case MA-name-null { 1119 leaf MA-name-null { 1120 when "../../../MA-name-format = name-format-null" { 1121 description 1122 "MA"; 1123 } 1124 type empty; 1125 description 1126 "empty"; 1127 } 1128 } 1129 description 1130 "MA name"; 1131 } 1132 } 1134 grouping MEP-ID { 1135 choice MEP-ID { 1136 default "MEP-ID-int"; 1137 case MEP-ID-int { 1138 leaf MEP-ID-int { 1139 type int32; 1140 description 1141 "MEP ID in integer format"; 1142 } 1143 } 1144 case MEP-ID-tlv { 1145 leaf MEP-ID-type { 1146 type int16; 1147 description 1148 "Type of MEP-ID"; 1149 } 1150 leaf MEP-ID-len { 1151 type int16; 1152 description 1153 "Length of MEP-ID value"; 1154 } 1155 leaf MEP-ID-value { 1156 type binary { 1157 length "12..255"; 1158 } 1159 description 1160 "Value please refer RFC6428."; 1161 } 1162 } 1163 description 1164 "MEP-ID"; 1165 } 1166 leaf MEP-ID-format { 1167 type identityref { 1168 base identifier-format; 1169 } 1170 description 1171 "MEP ID format."; 1172 } 1173 description 1174 "MEP-ID"; 1175 } 1177 grouping MEP { 1178 description 1179 "Defines elements within the MEP"; 1180 leaf mep-name { 1181 type MEP-name; 1182 mandatory true; 1183 description 1184 "Generic administrative name of the MEP"; 1185 } 1186 uses MEP-ID; 1188 uses mp-address; 1189 uses connectivity-context; 1190 leaf Interface { 1191 type if:interface-ref; 1192 description 1193 "Interface name as defined by ietf-interfaces"; 1194 } 1195 uses topology; 1196 } 1198 grouping session-type { 1199 description 1200 "This object indicates the current session 1201 definition."; 1202 leaf session-type-enum { 1203 type enumeration { 1204 enum proactive { 1205 description 1206 "The current session is proactive"; 1207 } 1208 enum on-demand { 1209 description 1210 "The current session is on-demand."; 1211 } 1212 } 1213 description 1214 "session type enum"; 1215 } 1216 } 1218 grouping monitor-stats { 1219 leaf tx-packt-count { 1220 type oam-counter32; 1221 description 1222 "Transmitted Packet count"; 1223 } 1224 leaf rx-packet-count { 1225 type oam-counter32; 1226 description 1227 "Received packet count"; 1228 } 1229 leaf min-delay { 1230 type oam-counter32; 1231 units milliseconds; 1232 description 1233 "Delay is specified in milliseconds"; 1234 } 1235 leaf average-delay { 1236 type oam-counter32; 1237 units millisecond; 1238 description 1239 "average delay in milliseconds"; 1240 } 1241 leaf max-delay { 1242 type oam-counter32; 1243 units millisecond; 1244 description 1245 "Maximum delay in milliseconds"; 1246 } 1247 description 1248 "Monitor Statistics"; 1249 } 1251 grouping MIP { 1252 description 1253 "defines MIP"; 1254 leaf interface { 1255 type if:interface-ref; 1256 description 1257 "Interface"; 1258 } 1259 } 1261 grouping related-oam-layer { 1262 leaf offset { 1263 type int32 { 1264 range "-255..255"; 1265 } 1266 description 1267 "defines offset (in MD levels) to a related OAM layer 1268 +1 is the layer immediately above 1269 -1 is the layer immediately below"; 1270 } 1271 uses maintenance-domain-id; 1272 uses ma-identifier; 1273 description 1274 "related OAM layer"; 1275 } 1277 grouping interface-status { 1278 description 1279 "collection of interface related status"; 1280 leaf admin-status { 1281 type leafref { 1282 path "/if:interfaces-state/if:interface/if:admin-status"; 1283 } 1284 config false; 1285 description 1286 "oper status from ietf-interface module"; 1287 } 1288 leaf oper-status { 1289 type leafref { 1290 path "/if:interfaces-state/if:interface/if:oper-status"; 1291 } 1292 config false; 1293 description 1294 "oper status from ietf-interface module"; 1295 } 1296 } 1298 grouping connectivity-context { 1299 description 1300 "Grouping defining the connectivity context for an MA; for 1301 example, a VRF for IP, or an LSP for MPLS. This will be 1302 augmented by each protocol who use this component"; 1303 choice connectivity-context { 1304 default "context-null"; 1305 case context-null { 1306 description 1307 "this is a place holder when no context is needed"; 1308 leaf context-null { 1309 type empty; 1310 description 1311 "there is no context define"; 1312 } 1313 } 1314 description 1315 "connectivity context"; 1316 } 1317 } 1319 grouping priority { 1320 description 1321 "Priority used in transmitted packets; for example, in the 1322 TOS/DSCP field in IP or the Traffic Class field in MPLS"; 1323 leaf priority { 1324 type uint8; 1325 description 1326 "priority"; 1327 } 1328 } 1330 grouping flow-entropy { 1331 description 1332 "defines the grouping statement for flow-entropy"; 1333 choice flow-entropy { 1334 default "flow-entropy-null"; 1335 case flow-entropy-null { 1336 description 1337 "this is a place holder when no flow entropy is needed"; 1338 leaf flow-entropy-null { 1339 type empty; 1340 description 1341 "there is no flow entropy defined"; 1342 } 1343 } 1344 description 1345 "Flow entropy"; 1346 } 1347 } 1349 grouping measurement-timing-group { 1350 description 1351 "This grouping includes objects used for 1352 proactive and on-demand 1353 scheduling of PM measurement sessions."; 1355 container start-time { 1356 description 1357 "This container defines the session start time."; 1358 choice start-time { 1359 description 1360 "Measurement sessions tart time can be immediate, relative, or 1361 absolute."; 1362 container immediate { 1363 presence "Start the measurement session immediately."; 1364 description 1365 "Start Time of probe immediately."; 1366 } 1367 leaf absolute { 1368 type yang:date-and-time; 1369 description 1370 "This objects specifies the scheduled start time 1371 to perform the on-demand monitoring operations."; 1372 } 1373 } 1374 } 1376 container stop-time { 1377 description 1378 "This container defines the session stop time."; 1379 choice stop-time { 1380 description 1381 "Measurement session stop time can be none, or absolute."; 1382 container none { 1383 presence "Never end the measurement session."; 1384 description 1385 "Stop time is never to end."; 1387 } 1389 leaf absolute { 1390 type yang:date-and-time; 1391 description 1392 "This objects specifies the scheduled stop time 1393 to perform the on-demand monitoring operations."; 1394 } 1395 } 1396 } 1397 } 1399 container domains { 1400 description 1401 "Contains configuration related data. Within the container 1402 is list of fault domains. Wihin each domian has List of MA."; 1403 list domain { 1404 key "technology MD-name-string"; 1405 ordered-by system; 1406 description 1407 "Define the list of Domains within the IETF-OAM"; 1408 uses maintenance-domain-id; 1409 uses MD-name; 1410 leaf md-level { 1411 type MD-level; 1412 description 1413 "Defines the MD-Level"; 1414 } 1415 container MAs { 1416 description 1417 "This container defines MA, within that have multiple MA 1418 and within MA have MEP, MIP"; 1419 list MA { 1420 key "MA-name-string"; 1421 ordered-by system; 1422 uses ma-identifier; 1423 uses MA-name; 1424 uses connectivity-context; 1425 leaf mep-direction { 1426 type MEP-direction; 1427 mandatory true; 1428 description 1429 "Direction for MEPs in this MA"; 1430 } 1431 leaf interval { 1432 type Interval; 1433 default "0"; 1434 description 1435 "Defines default Keepalive/CC Interval. May be 1436 overridden for specific sessions if supported by the 1437 protocol."; 1438 } 1439 leaf loss-threshold { 1440 type uint32; 1441 default "3"; 1442 description 1443 "number of consecutive Keepalive/CC messages missed 1444 before declaring loss of continuity fault. This is 1445 monitored per each remote MEP session"; 1446 } 1447 leaf ttl { 1448 type uint8; 1449 default "255"; 1450 description 1451 "Time to Live"; 1452 } 1453 uses flow-entropy { 1454 description 1455 "Default flow entropy in this MA, which may be 1456 overridden for particular MEPs, sessions or 1457 operations"; 1458 } 1459 uses priority { 1460 description 1461 "Default priority for this MA, which may be overridden 1462 for particular MEPs, sessions or operations."; 1463 } 1464 list MEP { 1465 key "mep-name"; 1466 ordered-by system; 1467 description 1468 "contain list of MEPS"; 1469 uses MEP; 1470 uses interface-status { 1471 description 1472 "status of associated interface"; 1473 } 1474 uses flow-entropy; 1475 uses priority; 1476 list session { 1477 key "session-cookie"; 1478 ordered-by user; 1479 description 1480 "Monitoring session to/from a particular remote MEP. 1482 Depending on the protocol, this could represent CC 1483 messages received from a single remote MEP (if the 1484 protocol uses multicast CCs) or a target to which 1485 unicast echo request CCs are sent and from which 1486 responses are received (if the protocol uses a 1487 unicast request/response mechanism)."; 1488 leaf session-cookie { 1489 type uint32; 1490 description 1491 "Cookie to identify different sessions, when there 1492 are multiple remote MEPs or multiple sessions to 1493 the same remote MEP."; 1494 } 1495 leaf ttl { 1496 type uint8; 1497 default "255"; 1498 description 1499 "Time to Live."; 1500 } 1501 leaf interval { 1502 type Interval; 1503 description 1504 "Transmission interval for CC packets for this 1505 session."; 1506 } 1507 leaf enable { 1508 type boolean; 1509 default "false"; 1510 description 1511 "enable or disable a monitor session"; 1512 } 1513 leaf ecmp-choice { 1514 type ecmp-choices; 1515 description 1516 "0 means use the specified interface 1517 1 means use round robin"; 1518 } 1519 leaf source-mep { 1520 type MEP-name; 1521 description 1522 "Source MEP for this session, if applicable"; 1523 } 1524 container destination-mep { 1525 uses MEP-ID; 1526 description 1527 "Destination MEP"; 1528 } 1529 container destination-mep-address { 1530 uses mp-address; 1531 description 1532 "Destination MEP Address"; 1533 } 1534 uses connectivity-context; 1535 uses flow-entropy; 1536 uses priority; 1537 list outgoing-interface { 1538 key "interface"; 1539 leaf interface { 1540 type if:interface-ref; 1541 description 1542 "Outgoing Interface"; 1543 } 1544 description 1545 "outgoing interfaces"; 1546 } 1547 } 1548 } 1549 list MIP { 1550 key "interface"; 1551 uses MIP; 1552 description 1553 "Maintenance Intermediate Point"; 1554 } 1555 list related-oam-layer { 1556 key "offset"; 1557 description 1558 "List of OAM layers above and below that are related to 1559 current MA. This allow users to easily navigate up and 1560 down to efficiently troubleshoot a connectivity 1561 issue"; 1562 uses related-oam-layer; 1563 } 1564 description 1565 "Maintenance Association list"; 1566 } 1567 } 1568 } 1569 } 1571 notification defect-condition-notification { 1572 description 1573 "When defect condition is met this notificiation is sent"; 1574 uses maintenance-domain-id { 1575 description 1576 "defines the MD (Maintenance Domain) identifier, which is the 1577 Generic MD-name-string and the technology."; 1579 } 1580 uses ma-identifier; 1581 leaf mep-name { 1582 type MEP-name; 1583 description 1584 "Indicate which MEP is seeing the error"; 1585 } 1586 leaf defect-type { 1587 type identityref { 1588 base defect-types; 1589 } 1590 description 1591 "The currently active defects on the specific MEP."; 1592 } 1593 container generating-mepid { 1594 uses MEP-ID; 1595 description 1596 "Who is generating the error (if known) if 1597 unknown make it 0."; 1598 } 1599 uses error-message { 1600 description 1601 "Error message to indicate more details."; 1602 } 1603 } 1604 rpc continuity-check { 1605 description 1606 "Generates continuity-check as per RFC7276 Table 4."; 1607 input { 1608 uses maintenance-domain-id { 1609 description 1610 "defines the MD (Maintenance Domain) identifier, which is 1611 the generic 1612 MD-name-string and the technology."; 1613 } 1614 uses ma-identifier { 1615 description 1616 "identfies the Maintenance association"; 1617 } 1618 uses flow-entropy; 1619 uses priority; 1620 leaf ttl { 1621 type uint8; 1622 default "255"; 1623 description 1624 "Time to Live"; 1625 } 1626 uses session-type; 1627 leaf ecmp-choice { 1628 type ecmp-choices; 1629 description 1630 "0 means use the specified interface 1631 1 means use round robin"; 1632 } 1633 leaf sub-type { 1634 type identityref { 1635 base command-sub-type; 1636 } 1637 description 1638 "defines different command types"; 1639 } 1640 list outgoing-interfaces { 1641 key "interface"; 1642 leaf interface { 1643 type if:interface-ref; 1644 description 1645 "outgoing interface"; 1646 } 1647 description 1648 "outgoing Interfaces"; 1649 } 1650 leaf source-mep { 1651 type MEP-name; 1652 description 1653 "Source MEP"; 1654 } 1655 container destination-mp { 1656 uses mp-address; 1657 uses MEP-ID { 1658 description "Only applicable if the destination is a MEP"; 1659 } 1660 description 1661 "Destination MEP"; 1662 } 1663 leaf count { 1664 type uint32; 1665 default "3"; 1666 description 1668 "Number of ping echo request message to send"; 1669 } 1670 leaf interval { 1671 type Interval; 1672 description 1673 "Interval between echo requests"; 1675 } 1676 leaf packet-size { 1677 type uint32 { 1678 range "64..10000"; 1679 } 1680 default "64"; 1681 description 1682 "Size of ping echo request packets, in octets"; 1683 } 1684 } 1685 output { 1686 uses monitor-stats { 1687 description 1688 "Stats of continuity check."; 1689 } 1690 } 1691 } 1693 rpc continuity-verification { 1694 if-feature connectivity-verification; 1695 description 1696 "Generates continuity-verification as per RFC7276 Table 4."; 1697 input { 1698 uses maintenance-domain-id { 1699 description 1700 "defines the MD (Maintenance Domain) identifier, which is 1701 the generic 1702 MD-name-string and the technology."; 1703 } 1704 uses ma-identifier { 1705 description 1706 "identfies the Maintenance association"; 1707 } 1708 uses flow-entropy; 1709 uses priority; 1710 leaf ttl { 1711 type uint8; 1712 default "255"; 1713 description 1714 "Time to Live"; 1715 } 1716 uses session-type; 1717 leaf ecmp-choice { 1718 type ecmp-choices; 1719 description 1720 "0 means use the specified interface 1721 1 means use round robin"; 1722 } 1723 leaf sub-type { 1724 type identityref { 1725 base command-sub-type; 1726 } 1727 description 1728 "defines different command types"; 1729 } 1730 list outgoing-interfaces { 1731 key "interface"; 1732 leaf interface { 1733 type if:interface-ref; 1734 description 1735 "outgoing interface"; 1736 } 1737 description 1738 "outgoing Interfaces"; 1739 } 1740 leaf source-mep { 1741 type MEP-name; 1742 description 1743 "Source MEP"; 1744 } 1745 container destination-mp { 1746 uses mp-address; 1747 uses MEP-ID { 1748 description "Only applicable if the destination is a MEP"; 1749 } 1750 description 1751 "Destination MEP"; 1752 } 1753 leaf count { 1754 type uint32; 1755 default "3"; 1756 description 1757 "Number of ping echo request message to send"; 1758 } 1759 leaf interval { 1760 type Interval; 1761 description 1762 "Interval between echo requests"; 1763 } 1764 leaf packet-size { 1765 type uint32 { 1766 range "64..10000"; 1767 } 1768 default "64"; 1769 description 1770 "Size of ping echo request packets, in octets"; 1772 } 1773 } 1774 output { 1775 uses monitor-stats { 1776 description 1777 "Stats of continuity check."; 1778 } 1779 } 1780 } 1781 rpc path-discovery { 1782 description 1783 "Generates Trace-route or Path Trace and return response. 1784 Referencing RFC7276 for common Toolset name, for IP it's 1785 Traceroute, for MPLS OAM it's Traceroute mode, for 1786 MPLS-TP OAM it's Route Tracing, for Pseudowire OAM it's 1787 LSP Ping, and for TRILL OAM It's Path Tracing tool. 1788 Starts with TTL 1789 of one and increment by one at each hop. Untill destination 1790 reached or TTL reach max valune"; 1791 input { 1792 uses maintenance-domain-id { 1793 description 1794 "defines the MD (Maintenance Domain) identifier, which is 1795 the generic MD-name-string and the technology."; 1796 } 1797 uses ma-identifier { 1798 description 1799 "identfies the Maintenance association"; 1800 } 1801 uses flow-entropy; 1802 uses priority; 1803 leaf ttl { 1804 type uint8; 1805 default "255"; 1806 description 1807 "Time to Live"; 1808 } 1809 uses session-type; 1810 leaf command-sub-type { 1811 type identityref { 1813 base command-sub-type; 1814 } 1815 description 1816 "defines different command types"; 1817 } 1818 leaf ecmp-choice { 1819 type ecmp-choices; 1820 description 1821 "0 means use the specified interface 1822 1 means use round robin"; 1823 } 1824 list outgoing-interfaces { 1825 key "interface"; 1826 leaf interface { 1827 type if:interface-ref; 1828 description 1829 "Interface."; 1830 } 1831 description 1832 "Outgoing interface list."; 1833 } 1834 leaf source-mep { 1835 type MEP-name; 1836 description 1837 "Source MEP"; 1838 } 1839 container destination-mp { 1840 uses mp-address; 1841 uses MEP-ID { 1842 description "Only applicable if the destination is a MEP"; 1843 } 1844 description 1845 "Destination MEP"; 1846 } 1847 leaf count { 1848 type uint32; 1849 default "1"; 1850 description 1851 "Number of traceroute probes to send. In protocols where a 1852 separate message is sent at each TTL, this is the number 1853 of packets to send at each TTL."; 1854 } 1855 leaf interval { 1856 type Interval; 1857 description 1858 "Interval between echo requests"; 1859 } 1860 } 1861 output { 1862 list response { 1863 key "response-index"; 1864 leaf response-index { 1865 type uint8; 1866 description 1867 "Arbitrary index for the response. In protocols that 1868 guarantee there is only a single response at each TTL 1869 (eg IP Traceroute), the TTL can be used as the response 1870 index."; 1871 } 1872 leaf ttl { 1873 type uint8; 1874 description 1875 "Time to Live"; 1876 } 1877 description 1878 "Time to Live"; 1879 container destination-mp { 1880 description "MP from which the response has been received"; 1881 uses mp-address; 1882 uses MEP-ID { 1883 description 1884 "Only applicable if the destination is a MEP"; 1885 } 1886 } 1887 uses monitor-stats { 1888 description 1889 "If count is 1, there is a single delay value reported."; 1890 } 1891 } 1892 description 1893 "List of response."; 1894 } 1895 } 1896 } 1898 YANG module of OAM 1900 1902 6. Base Mode 1904 The Base Mode defines default configuration that MUST be present in 1905 the devices that comply with this document. Base Mode allows users 1906 to have "zero-touch" experience. Several parameters require 1907 technology specific definition. 1909 6.1. MEP Address 1911 In the Base Mode of operation, the MEP Address is by default the IP 1912 address of the interface on which the MEP is located. 1914 6.2. MEP ID for Base Mode 1916 In the Base Mode of operation, each device creates a single UP MEP 1917 associated with a virtual OAM port with no physical layer (NULL PHY). 1918 The MEPID associated with this MEP is zero (0). The choice of MEP-ID 1919 zero is explained below. 1921 MEPID is 2 octet field by default. It is never used on the wire 1922 except when using CCM. Ping, traceroute and session monitoring does 1923 not use the MEPID on its message header. It is important to have 1924 method that can derive MEP ID of base mode in an automatic manner 1925 with no user intervention. IP address cannot be directly used for 1926 this purpose as the MEP ID is much smaller field. For Base Mode of 1927 operation we propose to use MEP ID zero (0) as the default MEP-ID. 1929 CCM packet use MEP-ID on the payload. CCM MUST NOT be used in the 1930 Base Mode. Hence CCM MUST be disabled on the Maintenance Association 1931 of the Base Mode. 1933 If CCM is required, users MUST configure a separate Maintenance 1934 association and assign unique value for the corresponding MEP IDs. 1936 [IEEE802.1Q] CFM defines MEP ID as an unsigned integer in the range 1 1937 to 8191. In this document we propose to extend the range to 0 to 1938 65535. Value 0 is reserved for MEP ID of Base Mode operation and 1939 MUST NOT be used for other purposes. 1941 6.3. Maintenance Domain 1943 Default MD-LEVEL is set to 3. 1945 6.4. Maintenance Association 1947 MAID [IEEE802.1Q] has a flexible format and includes two parts: 1948 Maintenance Domain Name and Short MA name. In the Based Mode of 1949 operation, the value of the Maintenance Domain Name must be the 1950 character string "GenericBaseMode" (excluding the quotes "). In Base 1951 Mode operation Short MA Name format is set to 2-octet integer format 1952 (value 3 in Short MA Format field [IEEE802.1Q]) and Short MA name set 1953 to 65532 (0xFFFC). 1955 7. Note 1957 This section will be removed or subject to change in the future if 1958 any agreement is reached. As per investigation of RFC7276 for 1959 performance Monitoring for Loss and Delay are defined for MPLS 1960 OAM(RFC6374[RFC6374]), OWAMP (RFC4656[RFC4656]) and TWAMP 1961 (RFC5357[RFC5357]) and TRILL OAM (RFC7456[RFC7456]). In case of 1962 Performance Monitoring Statistics are common between these 1963 technologies thus generic Yang model for Performance will be worked 1964 out through separate draft with Augmentation of Generic LIME model. 1965 In case of Other Function, it's technology specific and thus should 1966 be dealt in technology specific Yang model instead of Generic Model. 1968 8. Security Considerations 1970 The YANG module defined in this memo is designed to be accessed via 1971 the NETCONF protocol [RFC6241] [RFC6241]. The lowest NETCONF layer 1972 is the secure transport layer and the mandatory-to-implement secure 1973 transport is SSH [RFC6242] [RFC6242]. The NETCONF access control 1974 model [RFC6536] [RFC6536] provides the means to restrict access for 1975 particular NETCONF users to a pre-configured subset of all available 1976 NETCONF protocol operations and content. 1978 There are a number of data nodes defined in the YANG module which are 1979 writable/creatable/deletable (i.e., config true, which is the 1980 default). These data nodes may be considered sensitive or vulnerable 1981 in some network environments. Write operations (e.g., ) 1982 to these data nodes without proper protection can have a negative 1983 effect on network operations. 1985 The vulnerable "config true" subtrees and data nodes are the 1986 following: 1988 /goam:domains/goam:domain/ 1990 /goam:domains/goam:domain/goam:MAs/goam:MA/ 1992 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 1994 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/ 1996 Unauthorized access to any of these lists can adversely affect OAM 1997 management system handling of end-to-end OAM and coordination of OAM 1998 within underlying network layers This may lead to inconsistent 1999 configuration, reporting, and presentation for the OAM mechanisms 2000 used to manage the network. 2002 9. IANA Considerations 2004 This document registers a URI in the IETF XML registry [RFC3688] 2005 [RFC3688]. Following the format in RFC 3688, the following 2006 registration is requested to be made: 2008 URI: urn:ietf:params:xml:ns:yang:ietf-gen-oam 2010 Registrant Contact: The IESG. 2012 XML: N/A, the requested URI is an XML namespace. 2014 This document registers a YANG module in the YANG Module Names 2015 registry [RFC6020]. 2017 name: ietf-gen-oam namespace: urn:ietf:params:xml:ns:yang:ietf-gen-oam 2018 prefix: goam reference: RFC XXXX 2020 10. Acknowledgments 2022 Giles Heron came up with the idea of developing a YANG model as a way 2023 of creating a unified OAM API set (interface), work in this document 2024 is largely an inspiration of that. Alexander Clemm provided many 2025 valuable tips, comments and remarks that helped to refine the YANG 2026 model presented in this document. 2028 Carlos Pignataro, David Ball,Mahesh Jethanandani,Benoit 2029 Claise,Ladislav Lhotka,GUBALLA JENS,Yuji Tochio,Gregory Mirsky, Huub 2030 van Helvoort, Tom Taylor, Dapeng Liu participated and contributed to 2031 this document. 2033 11. References 2035 11.1. Normative References 2037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2038 Requirement Levels", BCP 14, RFC 2119, 2039 DOI 10.17487/RFC2119, March 1997, 2040 . 2042 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2043 DOI 10.17487/RFC3688, January 2004, 2044 . 2046 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2047 the Network Configuration Protocol (NETCONF)", RFC 6020, 2048 DOI 10.17487/RFC6020, October 2010, 2049 . 2051 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2052 and A. Bierman, Ed., "Network Configuration Protocol 2053 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2054 . 2056 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2057 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2058 . 2060 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2061 Protocol (NETCONF) Access Control Model", RFC 6536, 2062 DOI 10.17487/RFC6536, March 2012, 2063 . 2065 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 2066 September 1981. 2068 11.2. Informative References 2070 [IEEE802.1Q] 2071 "Media Access Control (MAC) Bridges and Virtual Bridged 2072 Local Area Networks", IEEE Std 802.1Q-2011, August 2011. 2074 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 2075 Label Switched (MPLS) Data Plane Failures", RFC 4379, 2076 DOI 10.17487/RFC4379, February 2006, 2077 . 2079 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2080 Control Message Protocol (ICMPv6) for the Internet 2081 Protocol Version 6 (IPv6) Specification", RFC 4443, 2082 DOI 10.17487/RFC4443, March 2006, 2083 . 2085 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2086 Zekauskas, "A One-way Active Measurement Protocol 2087 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 2088 . 2090 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2091 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2092 RFC 5357, DOI 10.17487/RFC5357, October 2008, 2093 . 2095 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 2096 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 2097 Acronym in the IETF", BCP 161, RFC 6291, 2098 DOI 10.17487/RFC6291, June 2011, 2099 . 2101 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 2102 Ghanwani, "Routing Bridges (RBridges): Base Protocol 2103 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 2104 . 2106 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 2107 Administration, and Maintenance Framework for MPLS-Based 2108 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 2109 September 2011, . 2111 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 2112 Measurement for MPLS Networks", RFC 6374, 2113 DOI 10.17487/RFC6374, September 2011, 2114 . 2116 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 2117 3rd, "Transparent Interconnection of Lots of Links (TRILL) 2118 Operations, Administration, and Maintenance (OAM) 2119 Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, 2120 . 2122 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2123 Weingarten, "An Overview of Operations, Administration, 2124 and Maintenance (OAM) Tools", RFC 7276, 2125 DOI 10.17487/RFC7276, June 2014, 2126 . 2128 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 2129 3rd, D., Aldrin, S., and Y. Li, "Transparent 2130 Interconnection of Lots of Links (TRILL): Fault 2131 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 2132 . 2134 [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and 2135 D. Eastlake 3rd, "Loss and Delay Measurement in 2136 Transparent Interconnection of Lots of Links (TRILL)", 2137 RFC 7456, DOI 10.17487/RFC7456, March 2015, 2138 . 2140 [Y.1731] "OAM functions and mechanisms for Ethernet based 2141 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 2143 Authors' Addresses 2144 Tissa Senevirathne 2145 CISCO Systems 2146 375 East Tasman Drive. 2147 San Jose, CA 95134 2148 USA 2150 Phone: 408-853-2291 2151 Email: tsenevir@cisco.com 2153 Norman Finn 2154 CISCO Systems 2155 510 McCarthy Blvd 2156 Milpitas, CA 95035 2157 USA 2159 Email: nfinn@cisco.com 2161 Deepak Kumar (editor) 2162 CISCO Systems 2163 510 McCarthy Blvd 2164 Milpitas, CA 95035 2165 USA 2167 Email: dekumar@cisco.com 2169 Samer Salam 2170 CISCO Systems 2171 595 Burrard St. Suite 2123 2172 Vancouver, BC V7X 1J1 2173 Canada 2175 Email: ssalam@cisco.com 2177 Qin Wu (editor) 2178 Huawei 2179 101 Software Avenue, Yuhua District 2180 Nanjing, Jiangsu 210012 2181 China 2183 Email: bill.wu@huawei.com 2184 Michael Wang 2185 Huawei Technologies,Co.,Ltd 2186 101 Software Avenue, Yuhua District 2187 Nanjing 210012 2188 China 2190 Email: wangzitao@huawei.com