idnits 2.17.1 draft-tissa-netmod-oam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 267 has weird spacing: '...-format int...' == Line 366 has weird spacing: '...terface lea...' == Line 422 has weird spacing: '...terface if:...' == Line 442 has weird spacing: '...terface if:...' -- The document date (March 29, 2014) is 3671 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: 'RFC6371' is mentioned on line 143, but not defined == Missing Reference: 'TRILLOAM' is mentioned on line 95, but not defined == Missing Reference: 'MA-domain-name' is mentioned on line 265, but not defined == Unused Reference: 'RFC2234' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'RFCabab' is defined on line 1420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '8021Q' Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETMOD Tissa Senevirathne 2 Internet Draft Norman Finn 3 Intended status: Standards Track Deepak Kumar 4 Samer Salam 5 Cisco 6 March 29, 2014 7 Expires: September 2014 9 YANG Data Model for Operations Administration and Maintenance (OAM) 10 draft-tissa-netmod-oam-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on September 31, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 This document presents YANG Data model for OAM. It provides protocol 53 and technology independent abstraction of key OAM concepts required 54 for OAM. These abstractions span OAM configuration and operational 55 data; they promote uniformity between OAM technologies and support 56 nested OAM work flows (i.e. drilling down to OAM at different layers) 57 through a unified interface. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Conventions used in this document..............................3 63 2.1. Terminology...............................................3 64 3. Overview of the OAM Model......................................4 65 3.1. Maintenance Domain (MD) configuration.....................4 66 3.2. Maintenance Association (MA) configuration................5 67 3.3. Maintenance Endpoint (MEP) configuration..................6 68 3.4. rpc definitions...........................................6 69 4. OAM data hierarchy.............................................7 70 5. OAM YANG module...............................................13 71 6. Security Considerations.......................................32 72 7. IANA Considerations...........................................32 73 8. References....................................................32 74 8.1. Normative References.....................................32 75 8.2. Informative References...................................33 76 9. Acknowledgments...............................................33 78 1. Introduction 80 Operations, Administration and Maintenance (OAM) are important aspect 81 of networking and allow operators to: 83 1. Configure networks 85 2. Monitor networks 87 3. Troubleshoot failures (Fault verification and isolation). 89 Ping and Traceroute are well known fault verification tools in IP 90 world. Over the years different technologies have developed similar 91 tools for similar purposes. 93 [8021Q] Connectivity Fault Management is a well-established OAM 94 standard that is widely adopted. ITUT [Y1731], MEF, MPLS-TP 95 [RFC6371], TRILL [TRILLOAM] all define OAM methods based on [8021Q] 96 CFM. 98 Given the wide spread adoption of the underlying OAM concepts defined 99 in [8021Q] CFM it is a reasonable choice to develop the unified OAM 100 framework based on those concepts. In this document we take the 101 [8021Q] CFM model and extend it to a technology independent framework 102 and build the corresponding YANG model accordingly. 104 The unification of OAM, according to the proposal of this document, 105 occurs at the management layer. Encapsulations and state machines may 106 differ according to each protocol. A user who wishes to issues a Ping 107 command or a Traceroute or initiate a session monitoring can do so in 108 the same manner regardless of the underlying protocol or technology. 110 As an example, consider a scenario where an IP ping to device B from 111 Device A failed. Between device A and B there are IEEE 802.1 bridges 112 a,b and c. Let's assume a,b and c are using [8021Q] CFM. A user upon 113 detecting the IP layer ping failure, may desire to drop down to the 114 Ethernet layer and issue the corresponding fault verification (LBM) 115 and fault isolation (LTM) tools, using the same API. This ability to 116 go up and down to different layers for troubleshooting is also known 117 as "nested OAM" and is a very powerful concept that leads to 118 efficient network troubleshooting and maintenance workflows. The OAM 119 YANG model presented in this document facilitates that without 120 needing changes to the underlying protocols. 122 2. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC-2119 [RFC2119]. 128 In this document, these words will appear with that interpretation 129 only when in ALL CAPS. Lower case uses of these words are not to be 130 interpreted as carrying RFC-2119 significance. 132 2.1. Terminology 134 CCM - Continuity Check Message [8021Q] 136 ECMP - Equal Cost Multipath 138 LBM - Loopback Message [8021Q] 139 MP - Maintenance Point [8021Q] 141 MEP - Maintenance End Point [TRLOAMFRM] [8021Q] [RFC6371] 143 MIP - Maintenance Intermediate Point [TRLOAMFRM] [8021Q] [RFC6371] 145 MA - Maintenance Association [8021Q] [TRLOAMFRM] 147 MD - Maintenance Domain [8021Q] 149 MTV - Multi-destination Tree Verification Message 151 OAM - Operations, Administration, and Maintenance [RFC6291] 153 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 155 3. Overview of the OAM Model 157 In this document we adopt [8021Q] CFM model and structure it such 158 that it can be adapted to different technologies. 160 At the top of the Model is the Maintenance Domain. Each Maintenance 161 Domain is associated with a Maintenance Name and a Domain Level. 163 Under each Maintenance Domain there is one or more Maintenance 164 Association (MA). In IP the MA can be per IP Subnet, in NVO3 this can 165 be per VNI and for TRILL this can be per Fine-Grained Label or for 166 VPLS this can be per VPLS instance. 168 Under each MA, there can be two or more MEP (Maintenance End Points). 169 MEPs are addressed by their respective technology specific addressing 170 identifiers. The YANG model presented here provides flexibility to 171 accommodate different addressing schemes. 173 In a parallel vertical, presented are the commands. Those, in YANG 174 terms, are the rpc commands. These rpc commands provide uniform APIs 175 for ping, traceroute and their equivalents as well as other OAM 176 commands. 178 3.1. Maintenance Domain (MD) configuration 180 The container "domains" is the top level container within the ietf- 181 oam module. Within the container "domains", separate list is 182 maintained per MD. The MD list uses the key MD-name for indexing. 184 module: ietf-oam 185 +--rw domains 186 | +--rw domain* [md-name] 187 | +--rw technology identityref 188 | +--rw md-name-format MD-name-format 189 | +--rw md-name binary 190 | +--rw md-level int32 192 . 193 . 195 Figure 1 Snippet of data hierarchy related to OAM domains 197 3.2. Maintenance Association (MA) configuration 199 Within a given Maintenance Domain there can be one or more 200 Maintenance Associations (MA). MAs are represented as a list and 201 indexed by the MA-name. 203 module: ietf-oam 204 +--rw domains 205 | +--rw domain* [md-name] 206 | +--rw technology identityref 207 | +--rw md-name-format MD-name-format 208 | +--rw md-name binary 209 | +--rw md-level int32 210 | +--rw MAs! 211 | +--rw MA* [ma-name] 212 | +--rw ma-name-format MA-name-format 213 | +--rw ma-name binary 214 . 215 . 217 Figure 2 Snippet of data hierarchy related to Maintenance 218 Associations (MA). 220 3.3. Maintenance Endpoint (MEP) configuration 222 Within a given Maintenance Association (MA), there can be one or more 223 Maintenance End Points (MEP). MEPs are represented as a list within 224 the data hierarchy and indexed by the key MEP-id. 226 module: ietf-oam 227 +--rw domains 228 | +--rw domain* [md-name] 229 | +--rw technology identityref 230 | +--rw md-name-format MD-name-format 231 | +--rw md-name binary 232 | +--rw md-level int32 233 | +--rw MAs! 234 | +--rw MA* [ma-name] 235 | +--rw ma-name-format MA-name-format 236 | +--rw ma-name binary 238 . 239 . 240 | +--rw MEP* [mep-id] 241 | | +--rw mep-id MEP-id 242 | | +--rw mep-name? string 243 | | +--rw mep-direction MEP-direction 244 | | +--rw context-id? uint32 245 . 246 . 248 Figure 3 Snippet of data hierarchy related to Maintenance Endpoint 249 (MEP). 251 3.4. rpc definitions 253 The rpc model facilitates issuing commands to a NETCONF server (in 254 this case to the device that need to execute the OAM command) and 255 obtaining a response. rpc model defined here abstracts OAM specific 256 commands in a technology independent manner. 258 There are several rpc commands defined for the purpose of OAM. In 259 this section we present a snippet of the ping command for 260 illustration purposes. Please refer to Section 4 for the complete 261 data hierarchy and Section 5 for the YANG model. 263 module: ietf-oam 264 +--rw domains 265 | +--rw Domain* [MA-domain-name] 266 | +--rw technology technology 267 | +--rw MA-domain-name-format int32 268 | +--rw MA-domain-name binary 269 | +--rw MD-level int32 271 . 272 . 274 rpcs: 275 +---x ping 276 | +--ro input 277 | | +--ro technology identityref 278 | | +--ro md-name-format MD-name-format 279 | | +--ro md-name? binary 280 | | +--ro md-level int32 281 | | +--ro ma-name-format MA-name-format 282 | | +--ro ma-name binary 283 | | +--ro source-mep-id? MEP-id 284 | | +--ro destination-mepid? MEP-id 285 | | +--ro ttl? uint8 286 | | +--ro flow-entropy? binary 287 | | +--ro ecmp-choice? ecmp-choices 288 | | +--ro outgoing-interfaces* [interface] 289 | | +--ro interface if:interface-ref 290 | +--ro output 291 | +--ro tx-packt-count? yang:zero-based-counter32 292 | +--ro rx-packet-count? yang:zero-based-counter32 293 | +--ro min-delay? yang:zero-based-counter32 294 | +--ro average-delay? yang:zero-based-counter32 295 | +--ro max-delay? yang:zero-based-counter32 297 Figure 4 Snippet of data hierarchy related to rpc call Ping 299 4. OAM data hierarchy 301 The complete data hierarchy related to the OAM YANG model is 302 presented below. The following notations are used within the data 303 tree and carry the meaning as below. 305 Each node is printed as: 307 309 is one of: 310 + for current 311 x for deprecated 312 o for obsolete 314 is one of: 316 rw for configuration data 317 ro for non-configuration data 318 -x for rpcs 319 -n for notifications 321 is the name of the node 323 If the node is augmented into the tree from another module, its 324 name is printed as :. 326 is one of: 328 ? for an optional leaf or choice 329 ! for a presence container 330 * for a leaf-list or list 331 [] for a list's keys 333 is the name of the type for leafs and leaf-lists 334 module: ietf-oam 335 +--rw domains 336 | +--rw domain* [md-name] 337 | +--rw technology identityref 338 | +--rw md-name-format MD-name-format 339 | +--rw md-name binary 340 | +--rw md-level int32 341 | +--rw MAs! 342 | +--rw MA* [ma-name] 343 | +--rw ma-name-format MA-name-format 344 | +--rw ma-name binary 345 | +--rw ccm-Interval? CCM-Interval 346 | +--rw ccm-loss-threshold? uint32 347 | +--rw ccm-ttl? uint8 348 | +--rw MEP* [mep-id] 349 | | +--rw mep-id MEP-id 350 | | +--rw mep-name? string 351 | | +--rw mep-direction MEP-direction 352 | | +--rw context-id? uint32 353 | | +--rw ccm-Tx-enable? boolean 354 | | +--rw flow-entropy? binary 355 | | +--rw mep-address MEP-address 356 | | +--rw Interface? if:interface-ref 357 | | +--rw session* [user-cookie destination-mepid] 358 | | +--rw user-cookie uint32 359 | | +--rw destination-mepid MEP-id 360 | | +--rw ttl? uint8 361 | | +--rw interval? uint32 362 | | +--rw enable? boolean 363 | | +--rw flow-entropy? binary 364 | | +--rw ecmp-choice? ecmp-choices 365 | | +--rw outgoing-interface* [interface] 366 | | +--rw interface leafref 367 | +--rw remote-MEP* [mep-id] 368 | +--rw mep-id uint32 369 | +--rw mep-name? string 370 | +--rw ccm-rx-error-count? oam-counter32 371 +--ro domain-status 372 +--ro Domain* [md-name] 373 +--ro technology identityref 374 +--ro md-name-format MD-name-format 375 +--ro md-name binary 376 +--ro md-level int32 377 +--ro MAs! 378 +--ro ccm-rdi-indicator? boolean 379 +--ro ccm-xcon-count? oam-counter32 380 +--ro ccm-xcon-Indicator? boolean 381 +--ro MA* [ma-name] 382 +--ro ma-name-format MA-name-format 383 +--ro ma-name binary 384 +--ro MEP* [mep-id] 385 | +--ro ccm-rdi-indicator? boolean 386 | +--ro ccm-xcon-count? oam-counter32 387 | +--ro ccm-xcon-Indicator? boolean 388 | +--ro mep-id MEP-id 389 | +--ro mep-name? string 390 | +--ro interface-oper-status? leafref 391 | +--ro interface-admin-status? leafref 392 | +--ro session* [user-cookie destination-mepid] 393 | +--ro user-cookie uint32 394 | +--ro destination-mepid MEP-id 395 | +--ro session-id? uint16 396 | +--ro tx-packt-count? oam-counter32 397 | +--ro rx-packet-count? oam-counter32 398 | +--ro min-delay? oam-counter32 399 | +--ro average-delay? oam-counter32 400 | +--ro max-delay? oam-counter32 401 +--ro remote-MEP* [mep-id] 402 +--ro mep-id uint32 403 +--ro mep-name? string 404 +--ro ccm-rdi-indicator? boolean 405 +--ro ccm-xcon-count? oam-counter32 406 +--ro ccm-xcon-Indicator? boolean 407 rpcs: 408 +---x ping 409 | +--ro input 410 | | +--ro technology identityref 411 | | +--ro md-name-format MD-name-format 412 | | +--ro md-name? binary 413 | | +--ro md-level int32 414 | | +--ro ma-name-format MA-name-format 415 | | +--ro ma-name binary 416 | | +--ro source-mep-id? MEP-id 417 | | +--ro destination-mepid? MEP-id 418 | | +--ro ttl? uint8 419 | | +--ro flow-entropy? binary 420 | | +--ro ecmp-choice? ecmp-choices 421 | | +--ro outgoing-interfaces* [interface] 422 | | +--ro interface if:interface-ref 423 | +--ro output 424 | +--ro tx-packt-count? oam-counter32 425 | +--ro rx-packet-count? oam-counter32 426 | +--ro min-delay? oam-counter32 427 | +--ro average-delay? oam-counter32 428 | +--ro max-delay? oam-counter32 429 +---x trace-route 430 | +--ro input 431 | | +--ro technology identityref 432 | | +--ro md-name-format MD-name-format 433 | | +--ro md-name? binary 434 | | +--ro md-level int32 435 | | +--ro ma-name-format MA-name-format 436 | | +--ro ma-name binary 437 | | +--ro source-mepid? MEP-id 438 | | +--ro destination-mepid? MEP-id 439 | | +--ro flow-entropy? binary 440 | | +--ro ecmp-choice? ecmp-choices 441 | | +--ro outgoing-interfaces* [interface] 442 | | +--ro interface if:interface-ref 443 | +--ro output 444 | +--ro response* [ttl] 445 | +--ro ttl uint8 446 | +--ro remote-mepid? MEP-id 447 | +--ro tx-packt-count? oam-counter32 448 | +--ro rx-packet-count? oam-counter32 449 | +--ro min-delay? oam-counter32 450 | +--ro average-delay? oam-counter32 451 | +--ro max-delay? oam-counter32 452 +---x End-station-locator 453 +--ro input 454 | +--ro technology identityref 455 | +--ro md-name-format MD-name-format 456 | +--ro md-name? binary 457 | +--ro md-level int32 458 | +--ro ma-name-format MA-name-format 459 | +--ro ma-name binary 460 | +--ro source-mepid? MEP-id 461 | +--ro end-station-address? End-station-address 462 | +--ro context-identifier? Context-identifier 463 +--ro output 464 +--ro devices* [mep-id] 465 +--ro mep-id MEP-id 466 +--ro mep-name? string 467 notifications: 468 +---n CCM-RDI-notification 469 +--ro mep-id? MEP-id 470 +--ro remote-mepid? MEP-id 471 +--ro error-message? String 473 Figure 5 data hierarchy of OAM 475 5. OAM YANG module 477 file "xxx.yang" 479 module ietf-oam { 480 yang-version 1; 482 namespace "urn:cisco:params:xml:ns:yang:ietf-oam"; 483 // name space urn later to be replaced with IANA 484 // assigned URI 486 prefix ietf-oam; 488 import ietf-inet-types { 489 prefix inet; 490 } 491 import ietf-interfaces { 492 prefix if; 493 } 494 import ietf-yang-types { 495 prefix yang; 496 } 498 organization "IETF NETMOD (NETCONF Data Modeling ) Working Group"; 499 contact 500 "Tissa Senevirathne tsenevir@cisco.com"; 501 description 502 "This YANG module defines the generic configuration, 503 statistics and rpc for OAM to be used within IETF in 504 a protocol indpendent manner. Functional level 505 abstraction is indendent with YANG modeling. It is 506 assumed that each protocol maps corresponding 507 abstracts to its native format."; 509 revision 2014-03-28 { 510 description 511 "Initial revision."; 512 reference "draft-tissa-netmod-oam"; 513 } 515 /* 516 * identity definitions, 517 */ 519 identity technology-types { 520 description 521 "this is the base identy of technology types which are 522 vpls, nvo3, TRILL, ipv4, ipv6, mpls"; 523 } 525 identity vpls { 526 base technology-types; 527 description 528 "vpls technology type"; 529 } 531 identity nvo3 { 532 base technology-types; 533 description 534 "nvo3 type"; 535 } 537 identity trill { 538 base technology-types; 539 description 540 "trill type"; 541 } 543 identity ipv4 { 544 base technology-types; 545 description 546 "technology of ipv4"; 547 } 549 identity ipv6 { 550 base technology-types; 551 description 552 "technology of ipv6"; 553 } 555 /* 556 * typedef definitions 557 */ 559 typedef MEP-direction { 560 type enumeration { 561 enum "Up" { 562 value 0; 563 } 564 enum "Down" { 565 value 1; 566 } 567 } 568 } 569 typedef vlan { 570 type uint16 { 571 range "1..4094"; 572 } 573 } 575 typedef vni { 576 type uint32; 577 } 579 typedef vpls-id { 580 type uint32; 581 } 583 typedef TRILL-nickname { 584 type uint16 { 585 range "1..65531"; 586 } 587 } 589 typedef MEP-address { 590 type union { 591 type TRILL-nickname; 592 type inet:ipv4-address; 593 type inet:ipv6-address; 594 } 595 description 596 "Defines addresses of different MEP types. IPv4, IPv6, 597 RBridge nickname"; 598 } 600 typedef End-station-address { 601 type union { 602 type yang:mac-address; 603 type inet:ipv4-address; 604 type inet:ipv6-address; 605 } 606 description 607 "Defines addresses of different End stations, MAC, IPv4 or 608 IPv6"; 609 } 611 typedef MEP-id { 612 type uint32 { 613 range "1..8191"; 614 } 615 description 616 "Defines type for MEPIDm range is 1..8191"; 617 } 619 typedef Context-identifier { 620 type union { 621 type vlan; 622 type vni; 623 type vpls-id; 624 type uint32; 625 } 626 description 627 "defines context identifier types VLAN, VNI, VPLS instence 628 etc.."; 629 } 631 typedef CCM-Interval { 632 default "interval-1min"; 633 type enumeration { 634 enum "interval-invalid" { 635 value 0; 636 } 637 enum "interval-300hz" { 638 value 1; 639 } 640 enum "interval-10ms" { 641 value 2; 642 } 643 enum "interval-100ms" { 644 value 3; 645 } 646 enum "interval-1s" { 647 value 4; 648 } 649 enum "interval-10s" { 650 value 5; 651 } 652 enum "interval-1min" { 653 value 6; 654 } 655 enum "interval-10min" { 656 value 7; 657 } 658 } 659 reference 660 "802.2Q Rev5 or 802.ag, all of the above 661 are standard enumeration from the 802.1Q"; 663 description 664 "IntervalInvalid - value 0 665 Interval300Hz - Value 1 666 Intervale10ms - value 2 667 Interval100ms - value3 668 Interval1s - value 4 669 Interval10s - value 5 670 Interval1min - value 6 671 Interval10min - value 7"; 672 } 674 typedef ecmp-choices { 675 type enumeration { 676 enum "ecmp-use-platform-hash" { 677 value 0; 678 } 679 enum "ecmp-use-round-robin" { 680 value 1; 681 } 682 } 683 } 685 typedef MD-name-format { 686 type enumeration { 687 enum "ieee-reserved" { 688 value 0; 689 } 690 enum "none" { 691 value 1; 692 } 693 enum "dns-like-name" { 694 value 2; 695 } 696 enum "mac-address-and-uint" { 697 value 3; 698 reference "802.1Q Rev5"; 699 description 700 "Domain name 3 specifies domain name is mac-address + 2 701 octets."; 702 } 703 } 704 reference "802.1Q"; 705 description 706 "defines the domain name format"; 707 } 709 typedef MA-name-format { 710 type enumeration { 711 enum "ieee-reserved" { 712 value 0; 713 } 714 enum "primary-vid" { 715 value 1; 716 } 717 enum "char-string" { 718 value 2; 719 } 720 enum "unsigned-int16" { 721 value 3; 722 } 723 enum "rfc2865-vpnid" { 724 value 4; 725 } 726 } 727 reference "802.1Q"; 728 description 729 "Defines Format of MA-names"; 730 } 732 typedef flow-entropy { 733 type binary { 734 length "96"; 735 } 736 } 738 typedef oam-counter32 { 739 type yang:zero-based-counter32; 740 description 741 "defines 32 bit counter for OAM"; 742 } 744 /* 745 * grouping definitions 746 */ 748 grouping maintenance-domain { 749 status current; 750 description 751 "Defines the MA-domain group"; 752 reference "802.1Q Rev5"; 753 leaf technology { 754 mandatory true; 755 status current; 756 type identityref { 757 base technology-types; 758 } 759 description 760 "Defines the technology"; 761 } 762 leaf md-name-format { 763 mandatory true; 764 status current; 765 description 766 "Defines the maintenance domain name"; 767 type MD-name-format; 768 reference "802.1Q Rev5"; 769 } 770 leaf md-name { 771 status current; 772 description 773 "Defines the MA-Domain name. This is a binary (octet) string 774 of 43 bytes"; 775 type binary { 776 length "1..43"; 777 } 778 reference "802.1Q Rev5"; 779 } 780 leaf md-level { 781 mandatory true; 782 status current; 783 description 784 "Defines the MD-Level"; 785 type int32 { 786 range "0..7"; 787 } 788 reference "802.1Q Rev5 or 802.1ag"; 789 } 790 } 792 grouping ma-identifier { 793 description 794 "ma-identifier defines MAID parameters as defined in 8021Q"; 795 reference "IEEE 802.1Q Rev5"; 796 leaf ma-name-format { 797 mandatory true; 798 status current; 799 description 800 "This defines the MA name format 1 is no format, 801 2 - dnslikename, 3- macaddress 4-CharString"; 802 type MA-name-format; 803 reference "IEEE 802.1Q Rev 5"; 805 } 806 leaf ma-name { 807 mandatory true; 808 description 809 "Define the MA-Name according to the specified format. 810 This is 43 byte string."; 811 type binary { 812 length "1..45"; 813 } 814 reference "802.1Q Rve 5 or 8021ag Clause 21.6.5"; 815 } 816 } 818 grouping MEP { 819 status current; 820 description 821 "Defines elements withing the MEP"; 822 reference "802.1Q Rev5"; 823 leaf mep-id { 824 mandatory true; 825 status current; 826 description 827 "Assigm MEPID in the range of 1..8191"; 828 type MEP-id { 829 range "1..8191"; 830 } 831 reference "802.1Q Rev5"; 832 } 833 leaf mep-name { 834 type string; 835 description 836 "Defines textual name for MEP. This is not specified in IEEE 837 but 838 defined in IETF OAM for ease of use"; 839 } 840 leaf mep-direction { 841 type MEP-direction; 842 mandatory true; 843 } 844 leaf context-id { 845 type uint32; 846 description 847 "This contain VLAN-ID, VNI-ID, VPLS-ID on which MEP is 848 applied"; 849 } 850 leaf ccm-Tx-enable { 851 type boolean; 852 default "false"; 853 } 854 leaf flow-entropy { 855 type binary { 856 length "96"; 857 } 858 } 859 leaf mep-address { 860 type MEP-address; 861 mandatory true; 862 } 863 leaf Interface { 864 type if:interface-ref; 865 description 866 "Interface name as defined by ietf-interfaces"; 867 } 868 } 870 grouping CCM-defect-stats { 871 description 872 "Contains all of the CCM related defect stats"; 874 leaf ccm-rdi-indicator { 875 config false; 876 type boolean; 877 description 878 "True indicate one or more of the MEP have seen RDI 879 flag set from remote MEP"; 880 } 882 leaf ccm-xcon-count { 883 config false; 884 type oam-counter32; 885 description 886 "Number of times cross connect errors are seen"; 887 } 888 leaf ccm-xcon-Indicator { 889 config false; 890 type boolean; 891 description 892 "There is currently cross connect error seen since last 893 clearing of the variable"; 894 } 895 } 897 grouping monitor-stats { 898 leaf tx-packt-count { 899 type oam-counter32; 900 description 901 "Transmitted Packet count"; 902 } 903 leaf rx-packet-count { 904 type oam-counter32; 905 description 906 "Received packet count"; 907 } 908 leaf min-delay { 909 units "milliseconds"; 910 type oam-counter32; 911 description 912 "Delay is specified in milliseconds"; 913 } 914 leaf average-delay { 915 units "milliseconds"; 916 type oam-counter32; 917 description 918 "average delay in milliseconds"; 919 } 920 leaf max-delay { 921 type oam-counter32; 922 units "millisecond"; 923 } 924 } 926 /* 927 * below config data definitions 928 */ 930 container domains { 931 status current; 932 config true; 933 description 934 "Contains configuration related data. Within the container 935 is list of fault domains. Wihin each domian has List of MA."; 936 list domain { 937 uses maintenance-domain { 938 status current; 939 } 940 key "md-name"; 941 ordered-by system; 942 status current; 943 config true; 944 description 945 "Define the list of Domains within the IETF-OAM"; 946 container MAs { 947 presence 948 "Indicates creation of MA within the Domain 949 There can be more than one MA within a specified domain"; 951 status current; 952 config true; 953 description 954 "This container defines MA, within that have multiple MA 955 and within MA have MEP, MIP"; 957 list MA { 958 ordered-by system; 959 status current; 960 config true; 961 key "ma-name"; 962 uses ma-identifier; 963 leaf ccm-Interval { 964 status current; 965 description 966 "Defines CCM Interval 0- Means disable 967 1 - CCM are sent 3 1/3 ms 968 2 - CCM are sent every 10 ms 969 3- CCM are sent every 100 ms 970 4- CCM are sent every 1 s 971 5 - CCM are sent every 10 s 972 6 - CCM are sent every 1 minute 973 7- CCM are sent every 10 mins"; 974 type CCM-Interval; 975 reference "802.1Q Rev5 and 802.1ag"; 976 } 977 leaf ccm-loss-threshold { 978 default "3"; 979 type uint32; 980 description 981 "number of consecutive CCM messages missed before 982 declaring RDI fault. This is monitored per each 983 remote MEP"; 984 } 985 leaf ccm-ttl { 986 type uint8; 987 default "255"; 988 } 989 list MEP { 990 key "mep-id"; 991 ordered-by system; 992 status current; 993 config true; 994 description 995 "contain list of MEPS"; 996 uses MEP { 997 status current; 998 } 999 list session { 1000 key "user-cookie destination-mepid"; 1001 ordered-by user; 1002 config true; 1003 description 1004 "per session basis create the monitoring"; 1005 leaf user-cookie { 1006 config true; 1007 type uint32; 1008 description 1009 "user need to specify some cookie to identify 1010 multiple sessions between to MEPs"; 1011 } 1012 leaf destination-mepid { 1013 type MEP-id; 1014 config true; 1015 } 1016 leaf ttl { 1017 config true; 1018 type uint8; 1019 default "255"; 1020 } 1021 leaf interval { 1022 units "milliseconds"; 1023 default "1000"; 1024 type uint32; 1025 description 1026 "In milli seconds. 0 means continous"; 1027 } 1028 leaf enable { 1029 default "false"; 1030 config true; 1031 type boolean; 1032 description 1033 "enable or disable a monitor session"; 1034 } 1035 leaf flow-entropy { 1036 type binary { 1037 length "96"; 1038 } 1039 } 1040 leaf ecmp-choice { 1041 config true; 1042 type ecmp-choices; 1043 description 1044 "0 means use the specified interface 1045 1 means use round robin"; 1046 } 1047 list outgoing-interface { 1048 config true; 1049 key "interface"; 1050 leaf interface { 1051 type leafref { 1052 path "/if:interfaces/if:interface/if:name"; 1053 } 1054 config true; 1055 } 1056 } 1057 } 1058 } 1059 list remote-MEP { 1060 key "mep-id"; 1061 ordered-by system; 1062 status current; 1063 config true; 1064 description 1065 "list all of the remote MEP within the MA"; 1066 leaf mep-id { 1067 mandatory true; 1068 status current; 1069 description 1070 "Assigm MEPID in the range of 1..8191"; 1071 config true; 1072 type uint32; 1073 reference "802.1Q Rev5"; 1074 } 1075 leaf mep-name { 1076 type string; 1077 description 1078 "Defines textual name for MEP. This is not 1079 specified in IEEE but defined in IETF OAM 1080 for ease of use"; 1081 } 1082 leaf ccm-rx-error-count { 1083 type oam-counter32; 1084 description 1085 "counts number of CCM packets that was 1086 expected but not received"; 1087 } 1088 } 1090 } 1091 } 1092 } 1093 } // end of container domain that defines config data 1095 /* 1096 * read only data definitions below 1097 */ 1098 container domain-status { 1099 config false; 1100 description 1101 "This container carries status and statistics"; 1102 list Domain { 1103 uses maintenance-domain { 1104 status current; 1105 } 1106 key "md-name"; 1107 ordered-by system; 1108 status current; 1109 description 1110 "Define the list of Domains within the IETF-OAM"; 1111 container MAs { 1112 presence 1113 "Indicates creation of MA within the Domain 1114 There can be more than one MA within a specified domain"; 1115 status current; 1116 description 1117 "This container defines MA, within that have 1118 multiple MA and within MA have MEP, MIP"; 1120 uses CCM-defect-stats; 1121 list MA { 1122 ordered-by system; 1123 status current; 1124 uses ma-identifier; 1125 key "ma-name"; 1126 list MEP { 1127 key "mep-id"; 1128 ordered-by system; 1129 status current; 1130 description 1131 "contain list of MEPS"; 1132 uses CCM-defect-stats; 1133 leaf mep-id { 1134 type MEP-id; 1135 } 1136 leaf mep-name { 1137 type string; 1138 description 1139 "Defines textual name for MEP. This is not 1140 specified in IEEE but 1141 defined in IETF OAM for ease of use"; 1142 } 1143 leaf interface-oper-status { 1144 type leafref { 1145 path 1146 "/if:interfaces-state/if:interface/if:oper-status"; 1147 } 1148 } 1149 leaf interface-admin-status { 1150 type leafref { 1151 path 1152 "/if:interfaces-state/if:interface/if:oper-status"; 1153 } 1154 } 1155 list session { 1156 key "user-cookie destination-mepid"; 1157 ordered-by user; 1158 description 1159 ""; 1160 leaf user-cookie { 1161 type uint32; 1162 } 1163 leaf destination-mepid { 1164 type MEP-id; 1165 } 1166 leaf session-id { 1167 type uint16; 1168 description 1169 "This is system generated key to uniquely identify 1170 the session. May be useful for isolation of system 1171 specific problems or further trouble shooting"; 1172 } 1173 uses monitor-stats; 1174 } 1175 } 1176 list remote-MEP { 1177 key "mep-id"; 1178 ordered-by system; 1179 status current; 1180 description 1181 "list all of the remote MEP within the MA"; 1182 leaf mep-id { 1183 mandatory true; 1184 status current; 1185 description 1186 "Assigm MEPID in the range of 1..8191"; 1187 type uint32; 1188 reference "802.1Q Rev5"; 1189 } 1190 leaf mep-name { 1191 type string; 1192 description 1193 "Defines textual name for MEP. This is not specified 1194 in IEEE but 1195 defined in IETF OAM for ease of use"; 1196 } 1197 uses CCM-defect-stats { 1198 description 1199 "indicates CCM defects received from this 1200 remote MEP (end point)"; 1201 } 1202 } 1203 } 1204 } 1205 } 1206 } // end of domain-status 1208 /* 1209 * below is definition of notifications 1210 */ 1212 notification CCM-RDI-notification { 1213 description 1214 "When RDI is received this notificiation is sent"; 1215 leaf mep-id { 1216 type MEP-id; 1217 description 1218 "Indicate which MEP is seeing the error"; 1219 } 1220 leaf remote-mepid { 1221 type MEP-id; 1222 description 1223 "Who is seeing the error (if known) if unknown make it 0."; 1224 } 1225 leaf error-message { 1226 type string { 1227 length "0..255"; 1228 } 1229 description 1230 "Error message to indicate more details."; 1232 } 1233 } // end of notification 1235 /* 1236 * below is definitions of rpc commands 1237 */ 1239 rpc ping { 1240 description 1241 "Generates Ping and return response"; 1242 input { 1243 uses maintenance-domain { 1244 description 1245 "Specifies the MA-domain"; 1246 } 1247 uses ma-identifier { 1248 description 1249 "identfies the Maintenance association"; 1250 } 1251 leaf source-mep-id { 1252 type MEP-id; 1253 } 1254 leaf destination-mepid { 1255 type MEP-id; 1256 } 1257 leaf ttl { 1258 type uint8; 1259 default "255"; 1260 } 1261 leaf flow-entropy { 1262 type binary { 1263 length "96"; 1264 } 1265 } 1266 leaf ecmp-choice { 1267 type ecmp-choices; 1268 description 1269 "0 means use the specified interface 1270 1 means use round robin"; 1271 } 1272 list outgoing-interfaces { 1273 key "interface"; 1274 leaf interface { 1275 type if:interface-ref; 1276 } 1277 } 1278 } 1279 output { 1280 uses monitor-stats { 1281 description 1282 "Stats of Ping is same as that of monitor sessions"; 1283 } 1284 } 1285 } // end of rpc command ping 1287 rpc trace-route { 1288 description 1289 "Generates Trace-route and return response. Starts with TTL 1290 of one and increment by one at each hop. Untill destination 1291 reached or TTL reach max valune"; 1292 input { 1293 uses maintenance-domain { 1294 description 1295 "Specifies the MA-domain"; 1296 } 1297 uses ma-identifier { 1298 description 1299 "identfies the Maintenance association"; 1300 } 1301 leaf source-mepid { 1302 type MEP-id; 1303 } 1304 leaf destination-mepid { 1305 type MEP-id; 1306 } 1307 leaf flow-entropy { 1308 type binary { 1309 length "96"; 1310 } 1311 } 1312 leaf ecmp-choice { 1313 type ecmp-choices; 1314 description 1315 "0 means use the specified interface 1316 1 ECMP selection according to the platform ECMP selection 1317 algorithm"; 1318 } 1319 list outgoing-interfaces { 1320 key "interface"; 1321 leaf interface { 1322 type if:interface-ref; 1323 } 1324 } 1325 } 1326 output { 1327 list response { 1328 key "ttl"; 1329 leaf ttl { 1330 type uint8; 1331 } 1332 leaf remote-mepid { 1333 type MEP-id; 1334 } 1335 uses monitor-stats; 1336 } 1337 } 1338 } // end of rpc command traceroute 1340 rpc End-station-locator { 1341 description 1342 "Allows to discover where the end station is located."; 1343 input { 1344 uses maintenance-domain { 1345 description 1346 "Specifies the MA-domain"; 1347 } 1348 uses ma-identifier { 1349 description 1350 "identfies the Maintenance association"; 1351 } 1352 leaf source-mepid { 1353 type MEP-id; 1354 } 1355 leaf end-station-address { 1356 type End-station-address; 1357 description 1358 "End station address can be MAC address, IPv4 or IPv6 1359 address."; 1360 } 1361 leaf context-identifier { 1362 type Context-identifier; 1363 description 1364 "This can be either vni, vlan , vpls or any other 1365 applicable 1366 conext"; 1367 } 1368 } 1369 output { 1370 list devices { 1371 key "mep-id"; 1372 leaf mep-id { 1373 type MEP-id; 1374 } 1375 leaf mep-name { 1376 type string; 1377 description 1378 "End-station locator response MAY return the textual name 1379 of MEP that owns the end-station. 1380 If textual name is not available word Unknown SHOULD 1381 be returned"; 1382 } 1383 } 1384 } 1385 } // end rpc end-station-locator 1386 }// end ietf-oam module 1388 1390 Figure 6 YANG module of OAM 1392 6. Security Considerations 1394 TBD 1396 7. IANA Considerations 1398 This document registers the following namespace URI in the IETF XML 1399 registry. 1401 URI:TBD 1403 8. References 1405 8.1. Normative References 1407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1408 Requirement Levels", BCP 14, RFC 2119, March 1997. 1410 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1411 Syntax Specifications: ABNF", RFC 2234, Internet Mail 1412 Consortium and Demon Internet Ltd., November 1997. 1414 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 1415 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 1416 2011. 1418 8.2. Informative References 1420 [RFCabab] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 1421 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1422 1573-1583. 1424 [Y1731] ITU, "OAM functions and mechanisms for Ethernet based 1425 networks", ITU-T G.8013/Y.1731, July, 2011. 1427 [TRLOAMFRM] Salam, S., et.al., "TRILL OAM Framework", draft-ietf- 1428 trill-oam-framework, Work in Progress, November, 2012. 1430 [RFC6291] Andersson, L., et.al., "Guidelines for the use of the "OAM" 1431 Acronym in the IETF" RFC 6291, June 2011. 1433 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 1434 Protocol Specification", RFC 6325, July 2011. 1436 9. Acknowledgments 1438 Giles Heron came up with the idea of developing a YANG model as a way 1439 of creating a unified OAM API set (interface), work in this document 1440 is largely an inspiration of that. Alexander Clemm provided many 1441 valuable tips, comments and remarks that helped to refine the YANG 1442 model presented in this document. 1444 This document was prepared using 2-Word-v2.0.template.dot. 1446 Authors' Addresses 1448 Tissa Senevirathne 1449 CISCO Systems 1450 375 East Tasman Drive. 1451 San Jose, CA 95134 1452 USA. 1454 Phone: 408-853-2291 1455 Email: tsenevir@cisco.com 1457 Norman Finn 1458 CISCO Systems 1459 510 McCarthy Blvd 1460 Milpitas, CA 95035. 1462 Email: nfinn@cisco.com 1464 Deepak Kumar 1465 CISCO Systems 1466 510 McCarthy Blvd 1467 Milpitas, CA 95035. 1469 Email: dekumar@cisco.com 1471 Samer Salam 1472 CISCO Systems 1473 595 Burrard St. Suite 2123 1474 Vancouver, BC V7X 1J1, Canada 1476 Email: ssalam@cisco.com