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