idnits 2.17.1 draft-tissa-nvo3-yang-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 252 has weird spacing: '... rw for c...' == Line 253 has weird spacing: '... ro for n...' == Line 361 has weird spacing: '...terface if:...' -- The document date (June 10, 2014) is 3608 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: 'NV03OAMFM' is mentioned on line 87, but not defined == Unused Reference: 'RFC2234' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFCabab' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'Y1731' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'TRLOAMFRM' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC6325' is defined on line 883, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'GENYANGOAM' Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NVO3 Tissa Senevirathne 2 Internet Draft Norman Finn 3 Intended status: Standards Track Deepak Kumar 4 Samer Salam 5 Carlos Pignataro 6 Cisco 8 June 10, 2014 9 Expires: December 2014 11 YANG Data Model for NVO3 Operations, Administration, and Maintenance 12 (OAM) 13 draft-tissa-nvo3-yang-oam-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on December 10, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 This document presents the YANG Data model for NVO3 OAM. The YANG 56 Model presented in this document extends the Generic YANG model for 57 OAM with NVO3 technology specifics. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Conventions used in this document..............................3 63 2.1. Terminology...............................................3 64 3. Architecture of OAM YANG Model and Relationship to NVO3 OAM....3 65 4. NVO3 extensions to Generic YANG Model..........................4 66 4.1. MEP address...............................................5 67 4.2. Identity technology-sub-type..............................5 68 4.3. Flow-entropy..............................................5 69 4.4. Context-id................................................5 70 4.5. rpc definitions...........................................6 71 5. OAM Data Hierarchy.............................................6 72 6. OAM YANG module...............................................12 73 7. Base Mode for NVO3 OAM........................................20 74 8. Security Considerations.......................................20 75 9. IANA Considerations...........................................20 76 10. References...................................................21 77 10.1. Normative References....................................21 78 10.2. Informative References..................................21 79 11. Acknowledgments..............................................22 81 1. Introduction 83 This document presents the YANG Data model for NVO3 OAM. The YANG 84 Model presented in this document extends the Generic YANG model for 85 OAM defined in [GENYANGOAM]. 87 Fault Management for NVO3 is defined in [NV03OAMFM]. NVO3 Fault 88 Management utilizes the [8021Q] CFM model and extends CFM with 89 technology specifics. Those technology specific extensions are flow- 90 entropy for multipath support, MEP addressing beyond MAC addresses 91 and so on. The extensions are explained in detail in [NVO3OAMFM]. In 92 this document we extend the YANG model defined in [GENYANGOAM] to 93 include NVO3 OAM. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC-2119 [RFC2119]. 101 In this document, these words will appear with that interpretation 102 only when in ALL CAPS. Lower case uses of these words are not to be 103 interpreted as carrying RFC-2119 significance. 105 2.1. Terminology 107 This document leverages the terminology defined in [GENYANGOAM]. 109 3. Architecture of OAM YANG Model and Relationship to NVO3 OAM 111 Generic OAM YANG model acts as the basis for other OAM YANG models. 112 This allows users to traverse between OAM tools of different 113 technologies at ease through a uniform API set. This is also referred 114 to as nested OAM workflow. The following Figure depicts the 115 relationship of NVO3 OAM YANG model to the Generic YANG Model. 117 Within NVO3 there are different overlay types such as VxLAN, NVGRE 118 and so on. All of the NVO3 overlay variations inherit some set of 119 NVO3 specific definitions such as VNI, VAP etc. To avoid repetition, 120 OAM YANG model is designed such that technology sub-types can augment 121 the technology specific YANG model. 123 +-+-+-+-+-+ 124 | Gen | 125 |OAM YANG | 126 +-+-+-+-+-+ 127 | 128 O 129 | 130 +--------------------------------------------------+ 131 | | | 132 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 133 | TRILL | | NVO3 | . . .| foo | 134 |OAM YANG | |OAM YANG | |OAM YANG | 135 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 136 | | | 137 | | | 138 | +-+-+-+-+-+-+-+-+-+ | 139 | | | | 140 | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 141 | | sub-tech| |sub-tech | |sub-tech | 142 | | VxLAN | | NVGRE | |bar | 143 | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 144 | | | | 145 +----------------------------------------------------+ 146 | Uniform API | 147 +----------------------------------------------------+ 149 Figure 1 Relationship of NVO3 OAM YANG model 150 to generic YANG model 152 4. NVO3 extensions to Generic YANG Model 154 The Technology parameter is defined in the [GENYANGOAM] as an 155 identity. This allows easy extension of the YANG model by other 156 technologies. Technology specific extensions are applied only when 157 the technology is set to the specific type. "nvo3" is defined as an 158 identity that augments the base technology-types identity. 160 identity nvo3 { 161 base goam:technology-types; 162 description 163 "nvo3 type"; 164 } 166 Figure 2 NVO3 identity type. 168 4.1. MEP address 170 In NVO3, the MEP address is either the IPv4 or IPV6 address. In 171 [GENYANGOAM] MEP address is defined as an IP address and same 172 definition can be used for NVO3 with no further modification. 174 4.2. Identity technology-sub-type 176 In NVO3, different overlay types such as VxLAN, NVGRE can be 177 employed. "technology-sub-type" further identifies the overlay type 178 within the NVO3. Technology sub-type is defined as an identity type. 179 This allows different overlay types to augment NVO3 OAM YANG model to 180 include overlay specific extensions without redefining common NVO3 181 definitions. 183 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { 184 leaf technology-sub-type { 185 type identityref { 186 base technology-sub-type; 187 } 188 } 189 } 191 4.3. Flow-entropy 193 In NVO3, flow-entropy depends on the sub technology such as VXLAN. 194 Technology sub-type is used to extend the YANG model to specific 195 usage. 197 augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:flow- 198 entropy" { 199 case flow-entropy-vxlan { 200 leaf flags-vxlan { 201 type flags-vxlan; 202 } 203 leaf flow-entropy-vxlan { 204 type flow-entropy-vxlan; 205 } 206 } 207 } 208 4.4. Context-id 210 In NVO3 context-id is 24 bit VNI. [GENYANGOAM] defines a placeholder 211 for context-id. This allows other technologies to easily augment that 212 to include technology specific extensions. The snippet below depicts 213 an example of augmenting context-id to include VNI. 215 augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:context-id" 216 { 217 case context-id-nvo3 { 218 leaf vni { 219 type vni; 220 } 221 } 222 } 224 4.5. rpc definitions 226 The rpc model facilitates issuing commands to a NETCONF server (in 227 this case to the device that need to execute the OAM command) and 228 obtaining a response. Grouping statement command-ext-nvo3, defines 229 the input extensions for nvo3. 231 End-Station-Locator rpc command, defined in NVO3 YANG model, is NVO3 232 specific and allows locating an end-station within the NVO3 233 deployment. 235 5. OAM Data Hierarchy 237 The complete data hierarchy related to the OAM YANG model is 238 presented below. The following notations are used within the data 239 tree and carry the meaning as below. 241 Each node is printed as: 243 245 is one of: 246 + for current 247 x for deprecated 248 o for obsolete 250 is one of: 252 rw for configuration data 253 ro for non-configuration data 254 -x for rpcs 255 -n for notifications 257 is the name of the node 259 If the node is augmented into the tree from another module, its 260 name is printed as :. 262 is one of: 264 ? for an optional leaf or choice 265 ! for a presence container 266 * for a leaf-list or list 267 [] for a list's keys 269 is the name of the type for leafs and leaf-lists 270 module: nvo3-oam 271 augment /goam:domains/goam:domain/goam:MAs/goam:MA: 272 +--rw technology-sub-type? identityref 273 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:context-id: 274 +--:(context-id-nvo3) 275 +--rw vni? vni 276 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:flow-entropy: 277 +--:(flow-entropy-vxlan) 278 +--rw flags-vxlan? flags-vxlan 279 +--rw flow-entropy-vxlan? flow-entropy-vxlan 280 augment 281 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:flow- 282 entropy: 283 +--:(flow-entropy-vxlan) 284 +--rw flags-vxlan? flags-vxlan 285 +--rw flow-entropy-vxlan? flow-entropy-vxlan 286 augment 287 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:context-id: 288 +--:(context-id-nvo3) 289 +--rw vni? vni 290 augment 291 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam 292 :context-id: 293 +--:(context-id-nvo3) 294 +--rw vni? vni 295 augment 296 /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam 297 :flow-entropy: 298 +--:(flow-entropy-vxlan) 299 +--rw flags-vxlan? flags-vxlan 300 +--rw flow-entropy-vxlan? flow-entropy-vxlan 301 augment /goam:ping/goam:input: 302 +--ro (context-id-nvo3)? 303 | +--:(vni) 304 | +--ro vni? vni 305 +--ro (out-of-band)? 306 +--:(ipv4-address) 307 | +--ro ipv4-address? inet:ipv4-address 308 +--:(ipv6-address) 309 +--ro ipv6-address? inet:ipv6-address 310 augment /goam:ping/goam:input: 311 +--ro technology-sub-type? identityref 312 augment /goam:ping/goam:input: 313 +--:(flow-entropy-vxlan) 314 +--ro flags-vxlan? flags-vxlan 315 +--ro flow-entropy-vxlan? flow-entropy-vxlan 317 augment /goam:trace-route/goam:input: 318 +--ro (context-id-nvo3)? 319 | +--:(vni) 320 | +--ro vni? vni 321 +--ro (out-of-band)? 322 +--:(ipv4-address) 323 | +--ro ipv4-address? inet:ipv4-address 324 +--:(ipv6-address) 325 +--ro ipv6-address? inet:ipv6-address 326 augment /goam:trace-route/goam:input: 327 +--ro technology-sub-type? identityref 328 augment /goam:trace-route/goam:input: 329 +--:(flow-entropy-vxlan) 330 +--ro flags-vxlan? flags-vxlan 331 +--ro flow-entropy-vxlan? flow-entropy-vxlan 332 rpcs: 333 +---x mtv 334 | +--ro input 335 | | +--ro technology identityref 336 | | +--ro md-name-format MD-name-format 337 | | +--ro md-name? binary 338 | | +--ro md-level int32 339 | | +--ro ma-name-format MA-name-format 340 | | +--ro ma-name binary 341 | | +--ro technology-sub-type? identityref 342 | | +--ro (context-id-nvo3)? 343 | | | +--:(vni) 344 | | | +--ro vni? vni 345 | | +--ro (out-of-band)? 346 | | | +--:(ipv4-address) 347 | | | | +--ro ipv4-address? inet:ipv4-address 348 | | | +--:(ipv6-address) 349 | | | +--ro ipv6-address? inet:ipv6-address 350 | | +--ro max-hop-count? uint8 351 | | +--ro command-sub-type? identityref 352 | | +--ro (flow-entropy)? 353 | | | +--:(flow-entropy-null) 354 | | | | +--ro flow-entropy-null? empty 355 | | | +--:(flow-entropy-vxlan) 356 | | | +--ro flow-entropy-vxlan? flow-entropy-vxlan 357 | | | +--ro flags-vxlan? flags-vxlan 358 | | +--ro scope* inet:ip-address 359 | | +--ro ecmp-choice? goam:ecmp-choices 360 | | +--ro outgoing-interfaces* [interface] 361 | | | +--ro interface if:interface-ref 362 | | +--ro source-mep 363 | | | +--ro (mep-address)? 364 | | | | +--:(mac-address) 365 | | | | | +--ro mac-address? yang:mac-address 366 | | | | +--:(ipv4-address) 367 | | | | | +--ro ipv4-address? inet:ipv4-address 368 | | | | +--:(ipv6-address) 369 | | | | +--ro ipv6-address? inet:ipv6-address 370 | | | +--ro mep-id? goam:MEP-id 371 | | +--ro destination-mep 372 | | +--ro (mep-address)? 373 | | | +--:(mac-address) 374 | | | | +--ro mac-address? yang:mac-address 375 | | | +--:(ipv4-address) 376 | | | | +--ro ipv4-address? inet:ipv4-address 377 | | | +--:(ipv6-address) 378 | | | +--ro ipv6-address? inet:ipv6-address 379 | | +--ro mep-id? goam:MEP-id 380 | +--ro output 381 | +--ro response* [mep-address mep-id] 382 | +--ro hop-count? uint8 383 | +--ro mep-id goam:MEP-id 384 | +--ro mep-address inet:ip-address 385 | +--ro next-hop-device* inet:ip-address 386 | +--ro upstream-device? inet:ip-address 387 | +--ro multicast-receiver-count? uint32 388 | +--ro tx-packt-count? oam-counter32 389 | +--ro rx-packet-count? oam-counter32 390 | +--ro min-delay? oam-counter32 391 | +--ro average-delay? oam-counter32 392 | +--ro max-delay? oam-counter32 393 +---x End-station-locator 394 +--ro input 395 | +--ro technology identityref 396 | +--ro md-name-format MD-name-format 397 | +--ro md-name? binary 398 | +--ro md-level int32 399 | +--ro ma-name-format MA-name-format 400 | +--ro ma-name binary 401 | +--ro (context-id-nvo3)? 402 | | +--:(vni) 403 | | +--ro vni? vni 404 | +--ro (out-of-band)? 405 | | +--:(ipv4-address) 406 | | | +--ro ipv4-address? inet:ipv4-address 407 | | +--:(ipv6-address) 408 | | +--ro ipv6-address? inet:ipv6-address 409 | +--ro source-mep 410 | | +--ro (mep-address)? 411 | | | +--:(mac-address) 412 | | | | +--ro mac-address? yang:mac-address 413 | | | +--:(ipv4-address) 414 | | | | +--ro ipv4-address? inet:ipv4-address 415 | | | +--:(ipv6-address) 416 | | | +--ro ipv6-address? inet:ipv6-address 417 | | +--ro mep-id? goam:MEP-id 418 | +--ro end-station-address? End-station-address 419 +--ro output 420 +--ro devices* 421 +--ro mep-id? goam:MEP-id 422 +--ro mep-address? inet:ip-address 423 +--ro mep-name? string 425 Figure 3 Data hierarchy of NVO3 OAM 427 6. OAM YANG module 429 file "xxx.yang" 430 module nvo3-oam { 431 namespace "urn:cisco:params:xml:ns:yang:nvo3-oam"; 432 prefix nvo3-oam; 434 import gen-oam { 435 prefix goam; 436 } 437 import ietf-inet-types { 438 prefix inet; 439 } 440 import ietf-interfaces { 441 prefix if; 442 } 443 import ietf-yang-types { 444 prefix yang; 445 } 447 revision 2014-04-24 { 448 description 449 "Initial revision."; 450 } 452 identity nvo3 { 453 base goam:technology-types; 454 description 455 "nvo3 type"; 456 } 458 identity nvo3-mtv { 459 base goam:command-sub-type; 460 } 462 identity nvo3-trace-route { 463 base goam:command-sub-type; 464 } 466 identity nvo3-ping { 467 base goam:command-sub-type; 468 } 470 identity technology-sub-type { 471 description 472 "certain implementations such as nvo3 can have 473 different encap types such as vxlan, nvgre and so on. 475 Instead of defining seperate models for each such encap 476 we define technology sub type. Technology subtype 477 is associated at MA level"; 478 } 480 identity technology-sub-type-vxlan { 481 base technology-sub-type; 482 description 483 "technology subtype is vxlan"; 484 } 486 grouping command-ext-nvo3 { 487 description 488 "group the rpc command extensions for nvo3"; 489 choice context-id-nvo3 { 490 case vni { 491 leaf vni { 492 type vni; 493 } 494 } 495 } 496 choice out-of-band { 497 case ipv4-address { 498 leaf ipv4-address { 499 type inet:ipv4-address; 500 } 501 } 502 case ipv6-address { 503 leaf ipv6-address { 504 type inet:ipv6-address; 505 } 506 } 507 description 508 "presence of this node indicate out of band request needed"; 509 } 510 } 512 typedef flow-entropy-vxlan { 513 type inet:port-number; 514 } 516 typedef vni { 517 type uint32; 518 } 520 typedef flags-vxlan { 521 type bits { 522 bit oam { 523 position 0; 524 } 525 bit r1 { 526 position 1; 527 } 528 bit r2 { 529 position 2; 530 } 531 bit r3 { 532 position 3; 533 } 534 bit r4 { 535 position 4; 536 } 537 bit r5 { 538 position 5; 539 } 540 bit r6 { 541 position 6; 542 } 543 bit r7 { 544 position 7; 545 } 546 } 547 } 549 typedef End-station-address { 550 type union { 551 type yang:mac-address; 552 type inet:ipv4-address; 553 type inet:ipv6-address; 554 } 555 description 556 "Defines addresses of different End stations, MAC, IPv4 or 557 IPv6"; 558 } 560 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { 561 leaf technology-sub-type { 562 type identityref { 563 base technology-sub-type; 564 } 565 } 566 } 567 augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:context- 568 id" { 569 case context-id-nvo3 { 570 leaf vni { 571 type vni; 572 } 573 } 574 } 575 augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:flow- 576 entropy" { 577 case flow-entropy-vxlan { 578 leaf flags-vxlan { 579 type flags-vxlan; 580 } 581 leaf flow-entropy-vxlan { 582 type flow-entropy-vxlan; 583 } 584 } 585 } 586 augment 587 "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:flow- 588 entropy" { 589 case flow-entropy-vxlan { 590 leaf flags-vxlan { 591 type flags-vxlan; 592 } 593 leaf flow-entropy-vxlan { 594 type flow-entropy-vxlan; 595 } 596 } 597 } 598 augment 599 "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:context-id" 600 { 601 case context-id-nvo3 { 602 leaf vni { 603 type vni; 604 } 605 } 606 } 607 augment 608 "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goa 609 m:context-id" { 610 case context-id-nvo3 { 611 leaf vni { 612 type vni; 613 } 614 } 615 } 616 augment 617 "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goa 618 m:flow-entropy" { 619 case flow-entropy-vxlan { 620 leaf flags-vxlan { 621 type flags-vxlan; 622 } 623 leaf flow-entropy-vxlan { 624 type flow-entropy-vxlan; 625 } 626 } 627 } 628 augment "/goam:ping/goam:input" { 629 uses command-ext-nvo3; 630 } 631 augment "/goam:ping/goam:input" { 632 leaf technology-sub-type { 633 type identityref { 634 base technology-sub-type; 635 } 636 } 637 } 638 augment "/goam:ping/goam:input" { 639 case flow-entropy-vxlan { 640 leaf flags-vxlan { 641 type flags-vxlan; 642 } 643 leaf flow-entropy-vxlan { 644 type flow-entropy-vxlan; 645 } 646 } 647 } 648 augment "/goam:trace-route/goam:input" { 649 uses command-ext-nvo3; 650 } 651 augment "/goam:trace-route/goam:input" { 652 leaf technology-sub-type { 653 type identityref { 654 base technology-sub-type; 655 } 656 } 657 } 658 augment "/goam:trace-route/goam:input" { 659 case flow-entropy-vxlan { 660 leaf flags-vxlan { 661 type flags-vxlan; 662 } 663 leaf flow-entropy-vxlan { 664 type flow-entropy-vxlan; 665 } 666 } 667 } 668 rpc mtv { 669 description 670 "Generates Trace-route and return response. Starts with TTL 671 of one and increment by one at each hop. Untill destination 672 reached or TTL reach max valune"; 673 input { 674 uses goam:maintenance-domain { 675 description 676 "Specifies the MA-domain"; 677 } 678 uses goam:ma-identifier { 679 description 680 "identfies the Maintenance association"; 681 } 682 leaf technology-sub-type { 683 type identityref { 684 base technology-sub-type; 685 } 686 } 687 uses command-ext-nvo3 { 688 description 689 "defines extensions needed for nvo3 690 We are using this structure so mtv command is in line 691 with ping and trace-route"; 692 } 693 leaf max-hop-count { 694 type uint8; 695 default "255"; 696 description 697 "Defines maximum value of hop count"; 698 } 699 leaf command-sub-type { 700 type identityref { 701 base goam:command-sub-type; 702 } 703 description 704 "defines different command types"; 705 } 706 choice flow-entropy { 707 case flow-entropy-null { 708 leaf flow-entropy-null { 709 type empty; 711 } 712 } 713 case flow-entropy-vxlan { 714 leaf flow-entropy-vxlan { 715 type flow-entropy-vxlan; 716 } 717 leaf flags-vxlan { 718 type flags-vxlan; 719 } 720 } 721 } 722 leaf-list scope { 723 type inet:ip-address; 724 } 725 leaf ecmp-choice { 726 type goam:ecmp-choices; 727 description 728 "0 means use platform defined path selection 729 1 means use round robin"; 730 } 731 list outgoing-interfaces { 732 key "interface"; 733 leaf interface { 734 type if:interface-ref; 735 } 736 } 737 container source-mep { 738 uses goam:mep-address; 739 leaf mep-id { 740 type goam:MEP-id; 741 } 742 } 743 container destination-mep { 744 uses goam:mep-address; 745 leaf mep-id { 746 type goam:MEP-id; 747 } 748 } 749 } 750 output { 751 list response { 752 key "mep-address mep-id"; 753 leaf hop-count { 754 type uint8; 755 } 756 leaf mep-id { 757 type goam:MEP-id; 759 } 760 leaf mep-address { 761 type inet:ip-address; 762 } 763 leaf-list next-hop-device { 764 type inet:ip-address; 765 description 766 "list of downstream devices. This is not specifically 767 sorted it is a leaf list"; 768 } 769 leaf upstream-device { 770 type inet:ip-address; 771 } 772 leaf multicast-receiver-count { 773 type uint32; 774 description 775 "number of ports that are interested in this multicast 776 stream"; 777 } 778 uses goam:monitor-stats; 779 } 780 } 781 } 782 rpc End-station-locator { 783 description 784 "Allows to discover where the end station is located."; 785 input { 786 uses goam:maintenance-domain { 787 description 788 "Specifies the MA-domain"; 789 } 790 uses goam:ma-identifier { 791 description 792 "identfies the Maintenance association"; 793 } 794 uses command-ext-nvo3; 795 container source-mep { 796 uses goam:mep-address; 797 leaf mep-id { 798 type goam:MEP-id; 799 } 800 } 801 leaf end-station-address { 802 type End-station-address; 803 description 804 "End station address can be MAC address, IPv4 or IPv6 805 address."; 806 } 807 } 808 output { 809 list devices { 810 leaf mep-id { 811 type goam:MEP-id; 812 } 813 leaf mep-address { 814 type inet:ip-address; 815 } 816 leaf mep-name { 817 type string; 818 description 819 "End-station locator response MAY return the textual name 820 of MEP that owns the end-station. 821 If textual name is not available word Unknown SHOULD 822 be returned"; 823 } 824 } 825 } 826 } 827 } 829 831 7. Base Mode for NVO3 OAM 833 Base Mode defines default configuration that MUST be present in the 834 devices that comply with this document. Base Mode allows users to 835 have zero-touch experience. Details of NVO3 Base Mode for OAM are 836 defined in [NVO3OAMFM]. 838 8. Security Considerations 840 TBD 842 9. IANA Considerations 844 This document registers the following namespace URI in the IETF XML 845 registry. 847 URI:TBD 849 10. References 851 10.1. Normative References 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, March 1997. 856 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 857 Syntax Specifications: ABNF", RFC 2234, Internet Mail 858 Consortium and Demon Internet Ltd., November 1997. 860 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 861 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 862 2011. 864 [GENYANGOAM] Senevirathne, T., et.al., "YANG Data Model for 865 Operations, Administration and Maintenance (OAM)", Work in 866 Progress, March, 2014. 868 10.2. Informative References 870 [RFCabab] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 871 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 872 1573-1583. 874 [Y1731] ITU, "OAM functions and mechanisms for Ethernet based 875 networks", ITU-T G.8013/Y.1731, July, 2011. 877 [TRLOAMFRM] Salam, S., et.al., "TRILL OAM Framework", draft-ietf- 878 trill-oam-framework, Work in Progress, November, 2012. 880 [RFC6291] Andersson, L., et.al., "Guidelines for the use of the "OAM" 881 Acronym in the IETF" RFC 6291, June 2011. 883 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 884 Protocol Specification", RFC 6325, July 2011. 886 [NVO3OAMFM] Senevirathne, T., et.al., "NVO3 Fault Management", Work 887 in Progress, February, 2014. 889 11. Acknowledgments 891 Giles Heron came up with the idea of developing a YANG model as a way 892 of creating a unified OAM API set (interface), work in this document 893 is largely an inspiration of that. Alexander Clemm provided many 894 valuable tips, comments and remarks that helped to refine the YANG 895 model presented in this document. 897 This document was prepared using 2-Word-v2.0.template.dot. 899 Authors' Addresses 901 Tissa Senevirathne 902 CISCO Systems 903 375 East Tasman Drive. 904 San Jose, CA 95134 905 USA. 907 Phone: 408-853-2291 908 Email: tsenevir@cisco.com 910 Norman Finn 911 CISCO Systems 912 510 McCarthy Blvd 913 Milpitas, CA 95035. 915 Email: nfinn@cisco.com 917 Deepak Kumar 918 CISCO Systems 919 510 McCarthy Blvd 920 Milpitas, CA 95035. 922 Email: dekumar@cisco.com 924 Samer Salam 925 CISCO Systems 926 595 Burrard St. Suite 2123 927 Vancouver, BC V7X 1J1, Canada 929 Email: ssalam@cisco.com 931 Carlos Pignataro 932 Cisco Systems, Inc. 933 7200-12 Kit Creek Road 934 Research Triangle Park, NC 27709 936 EMail: cpignata@cisco.com