idnits 2.17.1 draft-tissa-lime-yang-oam-model-03.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 395 has weird spacing: '...terface if:...' == Line 438 has weird spacing: '... rw for c...' == Line 439 has weird spacing: '... ro for n...' == Line 535 has weird spacing: '...terface lea...' == Line 537 has weird spacing: '...terface if:...' == (2 more instances...) -- The document date (November 10, 2014) is 3447 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 467, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '8021Q' -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 LIME Tissa Senevirathne 2 Internet Draft Norman Finn 3 Intended status: Standards Track Deepak Kumar 4 Samer Salam 5 Cisco 7 Qin Wu 8 HuaWei 10 November 10, 2014 11 Expires: May 2015 13 Generic YANG Data Model for Operations, Administration, and 14 Maintenance (OAM) 15 draft-tissa-lime-yang-oam-model-03.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on May 10, 2009. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 This document presents base YANG Data model for OAM. It provides a 58 protocol-independent and technology-independent abstraction of key 59 OAM constructs. Based model presented here can be extended to include 60 technology specific details. Leading to uniformity between OAM 61 technologies and support nested OAM workflows (i.e., performing OAM 62 functions at different layers through a unified interface). 64 Table of Contents 66 1. Introduction...................................................3 67 2. Conventions used in this document..............................4 68 2.1. Terminology...............................................4 69 3. Architecture of Generic YANG Model for OAM.....................5 70 4. Overview of the OAM Model......................................6 71 4.1. Maintenance Domain (MD) configuration.....................7 72 4.2. Maintenance Association (MA) configuration................8 73 4.3. Maintenance Endpoint (MEP) configuration..................9 74 4.4. rpc definitions...........................................9 75 5. OAM data hierarchy............................................12 76 6. OAM YANG module...............................................18 77 7. Base Mode for IP..............................................34 78 7.1. MEP Address..............................................34 79 7.2. MEP ID for Base Mode.....................................34 80 7.3. Maintenance Domain.......................................35 81 7.4. Maintenance Association..................................35 82 8. Security Considerations.......................................35 83 9. IANA Considerations...........................................35 84 10. References...................................................36 85 10.1. Normative References....................................36 86 10.2. Informative References..................................36 87 11. Acknowledgments..............................................37 88 12. Contributors.................................................37 90 1. Introduction 92 Operations, Administration, and Maintenance (OAM) are important 93 networking functions that allow operators to: 95 1. Monitor networks (Connectivity Verification, Continuity Check) 97 2. Troubleshoot failures (Fault verification and isolation). 99 3. Measure Performance 101 An overview of OAM tools is presented at [OAMOVW]. 103 Ping and Traceroute [RFC792], [RFC4443] are well-known fault 104 verification and isolation tools, respectively, for IP networks. Over 105 the years different technologies have developed similar tools for 106 similar purposes. 108 [8021Q] Connectivity Fault Management is a well-established OAM 109 standard that is widely adopted for Ethernet networks. ITU-T [Y1731], 110 MEF Service OAM, MPLS-TP [RFC6371], TRILL [TRILLOAMFM] all define OAM 111 methods based on manageability frame work of [8021Q] CFM. 113 Given the wide adoption of the underlying OAM concepts defined in 114 [8021Q] CFM, it is a reasonable choice to develop the unified 115 management framework based on those concepts. In this document, we 116 take the [8021Q] CFM model and extend it to a technology independent 117 framework and build the corresponding YANG model accordingly. The 118 YANG model presented in this document is the base model and supports 119 IP Ping and Traceroute. The generic OAM YANG model is designed such 120 that it can be extended to cover various technologies. Technology 121 dependent nodes and RPC commands are defined in technology specific 122 YANG models, which use and extend the base model defined here. As an 123 example, VXLAN uses source UDP port number for flow entropy, while 124 MPLS [RFC4379] uses IP addresses or the label stack for flow entropy 125 in the hashing for multipath selection. To capture this variation, 126 corresponding YANG models would define the applicable structures as 127 augmentation to the generic base model presented here. This 128 accomplishes three purposes: first it keeps each YANG model smaller 129 and manageable. Second, it allows independent development of 130 corresponding YANG models. Third, implementations can limit support 131 to only the applicable set of YANG models. (e.g. TRILL RBridge may 132 only need to implement Generic OAM model and the TRILL YANG model). 134 All implementations that follow the YANG framework presented in this 135 document MUST implement the generic OAM YANG model presented here. 137 The YANG data model presented in this document occurs at the 138 management layer. Encapsulations and state machines may differ 139 according to each OAM protocol. A user who wishes to issues a Ping 140 command or a Traceroute or initiate a performance monitoring session 141 can do so in the same manner regardless of the underlying protocol or 142 technology or specific vendor implementation. 144 As an example, consider a scenario where an IP ping from device A to 145 Device B failed. Between device A and B there are IEEE 802.1 bridges 146 a,b and c. Let's assume a,b and c are using [8021Q] CFM. A user upon 147 detecting the IP layer ping failures may decide to drill down to the 148 Ethernet layer and issue the corresponding fault verification (LBM) 149 and fault isolation (LTM) tools, using the same API. This ability to 150 go up and down to different layers for troubleshooting is referred to 151 as "nested OAM workflow" and is a useful concept that leads to 152 efficient network troubleshooting and maintenance. The OAM YANG model 153 presented in this document facilitates that without needing changes 154 to the underlying protocols. 156 2. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC-2119 [RFC2119]. 162 In this document, these words will appear with that interpretation 163 only when in ALL CAPS. Lower case uses of these words are not to be 164 interpreted as carrying RFC-2119 significance. 166 2.1. Terminology 168 CCM - Continuity Check Message [8021Q] 170 ECMP - Equal Cost Multipath 172 LBM - Loopback Message [8021Q] 174 MP - Maintenance Point [8021Q] 176 MEP - Maintenance End Point [RFC7174] [8021Q] [RFC6371] 178 MIP - Maintenance Intermediate Point [RFC7174] [8021Q] [RFC6371] 180 MA - Maintenance Association [8021Q] [RFC7174] 182 MD - Maintenance Domain [8021Q] 183 MTV - Multi-destination Tree Verification Message 185 OAM - Operations, Administration, and Maintenance [RFC6291] 187 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 189 3. Architecture of Generic YANG Model for OAM 191 In this document we define a generic YANG model for OAM. The YANG 192 model defined here is generic such that other technologies can extend 193 it for technology specific needs. The Generic OAM YANG model acts as 194 the root for other OAM YANG models. This allows users to traverse 195 between OAM of different technologies at ease through a uniform API 196 set. This is also provides a nested OAM workflow. Figure 1 depicts 197 the relationship of different OAM YANG models to the Generic OAM YANG 198 Model. Some technologies may have different sub-technologies. As an 199 example, consider Network Virtualization Overlays. These could employ 200 either vXLAN or NVGRE as encapsulation. The Generic OAM YANG model 201 provides a framework where technology-specific YANG models can 202 inherit constructs from the base YANG models without needing to 203 redefine them within the sub-technology. 205 Figure 1 depicts relationship of different YANG modules. 207 +-+-+-+-+-+ 208 | gen | 209 |OAM YANG | 210 +-+-+-+-+-+ 211 | 212 O 213 | 214 +---------------------------------------------------------+ 215 | | | | | 216 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 217 | TRILL | | NVO3 | | MPLS | | IP | . . .| foo | 218 |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | 219 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 220 | | | | | 221 | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ 222 | | NVO3 | | MPLS | | . . .| foo | 223 | |sub tech | |sub tech | | |sub tech | 224 | +-+-+-+-+-+ +-+-+-+-+-+ | +-+-+-+-+-+ 225 | | | | | 226 | | | | | 227 +------------------------------------------------------------+ 228 | Uniform API | 229 +------------------------------------------------------------+ 231 Figure 1 Relationship of OAM YANG model to generic (base) YANG model 233 4. Overview of the OAM Model 235 In this document we adopt the concepts of the [8021Q] CFM model and 236 structure it such that it can be adapted to different technologies. 238 At the top of the Model is the Maintenance Domain. Each Maintenance 239 Domain is associated with a Maintenance Name and a Domain Level. 241 Under each Maintenance Domain there is one or more Maintenance 242 Association (MA). In IP, the MA can be per IP Subnet, in NVO3 this 243 can be per VNI and for TRILL this can be per Fine-Grained Label or 244 for VPLS this can be per VPLS instance. 246 Under each MA, there can be two or more MEPs (Maintenance End 247 Points). MEPs are addressed by their respective technology specific 248 address identifiers. The YANG model presented here provides 249 flexibility to accommodate different addressing schemes. 251 In a parallel vertical, presented are the commands. Those, in YANG 252 terms, are the rpc commands. These rpc commands provide uniform APIs 253 for ping, traceroute and their equivalents as well as other OAM 254 commands. 256 [8021Q] CFM framework requires explicit configuration of OAM entities 257 prior to using any of the OAM tools. Users of Ping and Traceroute 258 tools within IP devices are expecting ability to use OAM tools with 259 no explicit configuration. In order to facilitate zero-touch 260 experience, this document defines a default mode of OAM. The default 261 mode of OAM is referred to as the Base Mode and specifies default 262 values for each of the [8021Q] CFM parameters, such as Maintenance 263 Domain Level, Name of the Maintenance Association and Addresses of 264 MEP and so on. The default values of these depend on the technology. 265 Base Mode for TRILL is defined in [TRILLOAMFM]. Section 7. of this 266 document specifies the Base mode for IP devices. Base mode for other 267 technologies such as NVO3, MPLS and future extensions will be defined 268 in their corresponding documents. 270 It is important to note that, no specific enhancements are needed in 271 the YANG model to support Base Mode. Implementations that comply with 272 this document, by default implement the data nodes of the applicable 273 technology. Data nodes of the Base Mode are read-only nodes. 275 4.1. Maintenance Domain (MD) configuration 277 The container "domains" is the top level container within the gen-oam 278 module. Within the container "domains", separate list is maintained 279 per MD. The MD list uses the key MD-name-string for indexing. MD- 280 name-string is a leaf and derived from type string. Additional name 281 formats as defined in [8021Q] or other standards can be included by 282 association of the MD-name-format with an identity-ref. MD-name- 283 format indicates the format of the augmented MD-names. MD-name is 284 presented as choice/case construct. Thus, it is easily augmentable by 285 derivative work. 287 module: gen-oam-db 288 +--rw domains 289 +--rw domain* [technology MD-name-string] 290 +--rw technology identityref 291 +--rw MD-name-string MD-name-string 292 +--rw MD-name-format? identityref 293 +--rw (MD-name)? 294 | +--:(MD-name-null) 295 | +--rw MD-name-null? empty 296 +--rw md-level MD-level . 297 . 299 Figure 1 Snippet of data hierarchy related to OAM domains 301 4.2. Maintenance Association (MA) configuration 303 Within a given Maintenance Domain there can be one or more 304 Maintenance Associations (MA). MAs are represented as a list and 305 indexed by the MA-name-string. Similar to MD-name defined previously, 306 additional name formats can be added by augmenting the name-format 307 identity-ref and adding applicable case statements to MA-name. 309 module: ietf-oam 310 +--rw domains 311 +--rw domain* [technology MD-name-string] 312 . 313 . 314 +--rw MAs 315 +--rw MA* [MA-name-string] 316 +--rw MA-name-string MA-name-string 317 +--rw MA-name-format? identityref 318 +--rw (MA-name)? 319 | +--:(MA-name-null) 320 | +--rw MA-name-null? empty 322 Figure 2 Snippet of data hierarchy related to Maintenance 323 Associations (MA). 325 4.3. Maintenance Endpoint (MEP) configuration 327 Within a given Maintenance Association (MA), there can be one or more 328 Maintenance End Points (MEP). MEPs are represented as a list within 329 the data hierarchy and indexed by the key MEP-name. 331 module: gen-oam 332 +--rw domains 333 +--rw domain* [technology MD-name-string] 334 +--rw technology identityref 335 . 336 . 337 +--rw MAs 338 +--rw MA* [MA-name-string] 339 +--rw MA-name-string MA-name-string 340 . 341 . 342 +--rw MEP* [mep-name] 343 | +--rw mep-name MEP-name 344 | +--rw (MEP-ID)? 345 | | +--:(MEP-ID-int) 346 | | +--rw MEP-ID-int? int32 347 | +--rw MEP-ID-format? identityref 348 | +--rw (mp-address)? 349 | | +--:(mac-address) 350 | | | +--rw mac-address? yang:mac-address 351 | | +--:(ipv4-address) 352 | | | +--rw ipv4-address? inet:ipv4-address 353 | | +--:(ipv6-address) 354 | | +--rw ipv6-address? inet:ipv6-address 355 . . 356 . . 357 . . 359 Figure 3 Snippet of data hierarchy related to Maintenance Endpoint 360 (MEP). 362 4.4. rpc definitions 364 The rpc model facilitates issuing commands to a NETCONF server (in 365 this case to the device that need to execute the OAM command) and 366 obtain a response. rpc model defined here abstracts OAM specific 367 commands in a technology independent manner. 369 There are several rpc commands defined for the purpose of OAM. In 370 this section we present a snippet of the ping command for 371 illustration purposes. Please refer to Section 4 for the complete 372 data hierarchy and Section 5 for the YANG model. 374 module: ietf-oam 375 +--rw domains 376 +--rw domain* [technology MD-name-string] 377 +--rw technology identityref 379 . 380 . 381 rpcs: 382 +---x ping 383 | +--ro input 384 | | +--ro technology identityref 385 | | +--ro MD-name-string MD-name-string 386 | | +--ro MA-name-string? MA-name-string 387 | | +--ro (flow-entropy)? 388 | | | +--:(flow-entropy-null) 389 | | | +--ro flow-entropy-null? empty 390 | | +--ro priority? uint8 391 | | +--ro ttl? uint8 392 | | +--ro ecmp-choice? ecmp-choices 393 | | +--ro sub-type? identityref 394 | | +--ro outgoing-interfaces* [interface] 395 | | | +--ro interface if:interface-ref 396 | | +--ro source-mep? MEP-name 397 | | +--ro destination-mp 398 | | | +--ro (mp-address)? 399 | | | | +--:(mac-address) 400 | | | | | +--ro mac-address? yang:mac-address 401 | | | | +--:(ipv4-address) 402 | | | | | +--ro ipv4-address? inet:ipv4-address 403 | | | | +--:(ipv6-address) 404 | | | | +--ro ipv6-address? inet:ipv6-address 405 | | | +--ro (MEP-ID)? 406 | | | | +--:(MEP-ID-int) 407 | | | | +--ro MEP-ID-int? int32 408 | | | +--ro MEP-ID-format? identityref 409 | | +--ro count? uint32 410 | | +--ro interval? Interval 411 | | +--ro packet-size? uint32 412 | +--ro output 413 | +--ro tx-packt-count? oam-counter32 414 | +--ro rx-packet-count? oam-counter32 415 | +--ro min-delay? oam-counter32 416 | +--ro average-delay? oam-counter32 417 | +--ro max-delay? oam-counter32 419 Figure 4 Snippet of data hierarchy related to rpc call Ping 421 5. OAM data hierarchy 423 The complete data hierarchy related to the OAM YANG model is 424 presented below. The following notations are used within the data 425 tree and carry the meaning as below. 427 Each node is printed as: 429 431 is one of: 432 + for current 433 x for deprecated 434 o for obsolete 436 is one of: 438 rw for configuration data 439 ro for non-configuration data 440 -x for rpcs 441 -n for notifications 443 is the name of the node 445 If the node is augmented into the tree from another module, its 446 name is printed as :. 448 is one of: 450 ? for an optional leaf or choice 451 ! for a presence container 452 * for a leaf-list or list 453 [] for a list's keys 455 is the name of the type for leafs and leaf-lists 456 module: gen-oam 457 +--rw domains 458 +--rw domain* [technology MD-name-string] 459 +--rw technology identityref 460 +--rw MD-name-string MD-name-string 461 +--rw MD-name-format? identityref 462 +--rw (MD-name)? 463 | +--:(MD-name-null) 464 | +--rw MD-name-null? empty 465 +--rw md-level MD-level 466 +--rw MAs 467 +--rw MA* [MA-name-string] 468 +--rw MA-name-string MA-name-string 469 +--rw MA-name-format? identityref 470 +--rw (MA-name)? 471 | +--:(MA-name-null) 472 | +--rw MA-name-null? empty 473 +--rw (connectivity-context)? 474 | +--:(context-null) 475 | +--rw context-null? empty 476 +--rw mep-direction MEP-direction 477 +--rw interval? Interval 478 +--rw loss-threshold? uint32 479 +--rw ttl? uint8 480 +--rw (flow-entropy)? 481 | +--:(flow-entropy-null) 482 | +--rw flow-entropy-null? empty 483 +--rw priority? uint8 484 +--rw MEP* [mep-name] 485 | +--rw mep-name MEP-name 486 | +--rw (MEP-ID)? 487 | | +--:(MEP-ID-int) 488 | | +--rw MEP-ID-int? int32 489 | +--rw MEP-ID-format? identityref 490 | +--rw (mp-address)? 491 | | +--:(mac-address) 492 | | | +--rw mac-address? yang:mac-address 493 | | +--:(ipv4-address) 494 | | | +--rw ipv4-address? inet:ipv4-address 495 | | +--:(ipv6-address) 496 | | +--rw ipv6-address? inet:ipv6-address 497 | +--rw (connectivity-context)? 498 | | +--:(context-null) 499 | | +--rw context-null? empty 500 | +--rw Interface? if:interface-ref 501 | +--ro admin-status? leafref 502 | +--ro oper-status? leafref 503 | +--rw (flow-entropy)? 504 | | +--:(flow-entropy-null) 505 | | +--rw flow-entropy-null? empty 506 | +--rw priority? uint8 507 | +--rw session* [session-cookie] 508 | +--rw session-cookie uint32 509 | +--rw ttl? uint8 510 | +--rw interval? Interval 511 | +--rw enable? boolean 512 | +--rw ecmp-choice? ecmp-choices 513 | +--rw source-mep? MEP-name 514 | +--rw destination-mep 515 | | +--rw (MEP-ID)? 516 | | | +--:(MEP-ID-int) 517 | | | +--rw MEP-ID-int? int32 518 | | +--rw MEP-ID-format? identityref 519 | +--rw destination-mep-address 520 | | +--rw (mp-address)? 521 | | +--:(mac-address) 522 | | | +--rw mac-address? yang:mac-address 523 | | +--:(ipv4-address) 524 | | | +--rw ipv4-address? inet:ipv4-address 525 | | +--:(ipv6-address) 526 | | +--rw ipv6-address? inet:ipv6-address 527 | +--rw (connectivity-context)? 528 | | +--:(context-null) 529 | | +--rw context-null? empty 530 | +--rw (flow-entropy)? 531 | | +--:(flow-entropy-null) 532 | | +--rw flow-entropy-null? empty 533 | +--rw priority? uint8 534 | +--rw outgoing-interface* [interface] 535 | +--rw interface leafref 536 +--rw MIP* [interface] 537 | +--rw interface if:interface-ref 538 +--rw related-oam-layer* [offset] 539 +--rw offset int32 540 +--rw technology identityref 541 +--rw MD-name-string MD-name-string 542 +--rw MA-name-string? MA-name-string 543 rpcs: 544 +---x ping 545 | +--ro input 546 | | +--ro technology identityref 547 | | +--ro MD-name-string MD-name-string 548 | | +--ro MA-name-string? MA-name-string 549 | | +--ro (flow-entropy)? 550 | | | +--:(flow-entropy-null) 551 | | | +--ro flow-entropy-null? empty 552 | | +--ro priority? uint8 553 | | +--ro ttl? uint8 554 | | +--ro ecmp-choice? ecmp-choices 555 | | +--ro sub-type? identityref 556 | | +--ro outgoing-interfaces* [interface] 557 | | | +--ro interface if:interface-ref 558 | | +--ro source-mep? MEP-name 559 | | +--ro destination-mp 560 | | | +--ro (mp-address)? 561 | | | | +--:(mac-address) 562 | | | | | +--ro mac-address? yang:mac-address 563 | | | | +--:(ipv4-address) 564 | | | | | +--ro ipv4-address? inet:ipv4-address 565 | | | | +--:(ipv6-address) 566 | | | | +--ro ipv6-address? inet:ipv6-address 567 | | | +--ro (MEP-ID)? 568 | | | | +--:(MEP-ID-int) 569 | | | | +--ro MEP-ID-int? int32 570 | | | +--ro MEP-ID-format? identityref 571 | | +--ro count? uint32 572 | | +--ro interval? Interval 573 | | +--ro packet-size? uint32 574 | +--ro output 575 | +--ro tx-packt-count? oam-counter32 576 | +--ro rx-packet-count? oam-counter32 577 | +--ro min-delay? oam-counter32 578 | +--ro average-delay? oam-counter32 579 | +--ro max-delay? oam-counter32 580 +---x trace-route 581 +--ro input 582 | +--ro technology identityref 583 | +--ro MD-name-string MD-name-string 584 | +--ro MA-name-string? MA-name-string 585 | +--ro (flow-entropy)? 586 | | +--:(flow-entropy-null) 587 | | +--ro flow-entropy-null? empty 588 | +--ro priority? uint8 589 | +--ro ttl? uint8 590 | +--ro command-sub-type? identityref 591 | +--ro ecmp-choice? ecmp-choices 592 | +--ro outgoing-interfaces* [interface] 593 | | +--ro interface if:interface-ref 594 | +--ro source-mep? MEP-name 595 | +--ro destination-mp 596 | | +--ro (mp-address)? 597 | | | +--:(mac-address) 598 | | | | +--ro mac-address? yang:mac-address 599 | | | +--:(ipv4-address) 600 | | | | +--ro ipv4-address? inet:ipv4-address 601 | | | +--:(ipv6-address) 602 | | | +--ro ipv6-address? inet:ipv6-address 603 | | +--ro (MEP-ID)? 604 | | | +--:(MEP-ID-int) 605 | | | +--ro MEP-ID-int? int32 606 | | +--ro MEP-ID-format? identityref 607 | +--ro count? uint32 608 | +--ro interval? Interval 609 +--ro output 610 +--ro response* [response-index] 611 +--ro response-index uint8 612 +--ro ttl? uint8 613 +--ro destination-mp 614 | +--ro (mp-address)? 615 | | +--:(mac-address) 616 | | | +--ro mac-address? yang:mac-address 617 | | +--:(ipv4-address) 618 | | | +--ro ipv4-address? inet:ipv4-address 619 | | +--:(ipv6-address) 620 | | +--ro ipv6-address? inet:ipv6-address 621 | +--ro (MEP-ID)? 622 | | +--:(MEP-ID-int) 623 | | +--ro MEP-ID-int? int32 624 | +--ro MEP-ID-format? identityref 625 +--ro tx-packt-count? oam-counter32 626 +--ro rx-packet-count? oam-counter32 627 +--ro min-delay? oam-counter32 628 +--ro average-delay? oam-counter32 629 +--ro max-delay? oam-counter32 630 notifications: 631 +---n RDI-notification 632 +--ro technology identityref 633 +--ro MD-name-string MD-name-string 634 +--ro MA-name-string? MA-name-string 635 +--ro mep-name? MEP-name 636 +--ro remote-mepid 637 | +--ro (MEP-ID)? 638 | | +--:(MEP-ID-int) 639 | | +--ro MEP-ID-int? int32 640 | +--ro MEP-ID-format? identityref 641 +--ro error-message? string 642 Figure 5 data hierarchy of OAM 644 6. OAM YANG module 646 file "xxx.yang" 647 module gen-oam { 648 namespace "urn:ietf:params:xml:ns:yang:gen-oam"; 649 prefix goam; 651 import ietf-interfaces { 652 prefix if; 653 } 654 import ietf-yang-types { 655 prefix yang; 656 } 657 import ietf-inet-types { 658 prefix inet; 659 } 661 organization "IETF LIME Working Group"; 662 contact 663 "Tissa Senevirathne tsenevir@cisco.com"; 664 description 665 "This YANG module defines the generic configuration, 666 statistics and rpc for OAM to be used within IETF in 667 a protocol indpendent manner. Functional level 668 abstraction is indendent with YANG modeling. It is 669 assumed that each protocol maps corresponding 670 abstracts to its native format. 671 Each protocoal may extend the YANG model defined 672 here to include protocol specific extensions"; 674 revision 2014-10-17 { 675 description 676 "Initial revision. - 02 version"; 677 reference "draft-tissa-lime-oam"; 678 } 680 identity technology-types { 681 description 682 "this is the base identy of technology types which are 683 vpls, nvo3, TRILL, ipv4, ipv6, mpls, etc"; 684 } 686 identity ipv4 { 687 base technology-types; 688 description 689 "technology of ipv4"; 690 } 691 identity ipv6 { 692 base technology-types; 693 description 694 "technology of ipv6"; 695 } 697 identity command-sub-type { 698 description 699 "defines different rpc command subtypes, e.g rfc792 ping 700 vs udp ping, this is optional for most cases"; 701 } 703 identity icmp-rfc792 { 704 base command-sub-type; 705 description 706 "Defines the command subtypes for ICMP ping"; 707 reference "RFC 792"; 708 } 710 identity name-format { 711 description 712 "This defines the name format, IEEE 8021Q CFM defines varying 713 styles of names. It is expected name format as an identity ref 714 to be extended with new types."; 715 } 717 identity name-format-null { 718 base name-format; 719 description 720 "defines name format as null"; 721 } 723 identity identifier-format { 724 description 725 "identifier-format identity can be augmented to define other 726 format identifiers used in MEPD-ID etc"; 727 } 729 identity identifier-format-integer { 730 base identifier-format; 731 description 732 "defines identifier-format to be integer"; 733 } 735 typedef MEP-direction { 736 type enumeration { 737 enum "Up" { 738 value 0; 739 } 740 enum "Down" { 741 value 1; 742 } 743 } 744 } 746 typedef MEP-name { 747 type string; 748 description 749 "Generic administrative name for a MEP"; 750 } 752 typedef Interval { 753 type uint32; 754 units "milliseconds"; 755 default "1000"; 756 description 757 "Interval between packets in milliseconds. 758 0 means no packets are sent."; 759 } 761 typedef ecmp-choices { 762 type enumeration { 763 enum "ecmp-use-platform-hash" { 764 value 0; 765 } 766 enum "ecmp-use-round-robin" { 767 value 1; 768 } 769 } 770 } 772 typedef MD-name-string { 773 default ""; 774 type string; 775 description 776 "Generic administrative name for an MD"; 777 } 779 typedef MA-name-string { 780 default ""; 781 type string; 782 description 783 "Generic administrative name for an MA"; 785 } 787 typedef oam-counter32 { 788 type yang:zero-based-counter32; 789 description 790 "defines 32 bit counter for OAM"; 791 } 793 typedef MD-level { 794 type uint32 { 795 range "0..255"; 796 } 797 description 798 "Maintenance Domain level. The level may be restricted in 799 certain protocols (eg to 0-7)"; 800 } 802 grouping mp-address { 803 choice mp-address { 804 case mac-address { 805 leaf mac-address { 806 type yang:mac-address; 807 } 808 } 809 case ipv4-address { 810 leaf ipv4-address { 811 type inet:ipv4-address; 812 } 813 } 814 case ipv6-address { 815 leaf ipv6-address { 816 type inet:ipv6-address; 817 } 818 } 819 } 820 } 822 grouping maintenance-domain-id { 823 status current; 824 description 825 "Grouping containing leaves sufficient to identify an MD"; 826 leaf technology { 827 status current; 828 type identityref { 829 base technology-types; 830 } 831 mandatory true; 832 description 833 "Defines the technology"; 834 } 835 leaf MD-name-string { 836 status current; 837 description 838 "Defines the generic administrative maintenance domain name"; 839 type MD-name-string; 840 mandatory true; 841 } 842 } 844 grouping MD-name { 845 leaf MD-name-format { 846 type identityref { 847 base name-format; 848 } 849 } 850 choice MD-name { 851 case MD-name-null { 852 leaf MD-name-null { 853 when "../../../MD-name-format = name-format-null"; 854 type empty; 855 } 856 } 858 } 860 } 862 grouping ma-identifier { 863 description 864 "Grouping containing leaves sufficient to identify an MA"; 865 leaf MA-name-string { 866 type MA-name-string; 867 } 868 } 870 grouping MA-name { 871 leaf MA-name-format { 872 type identityref { 873 base name-format; 874 } 875 } 876 choice MA-name { 877 case MA-name-null { 878 leaf MA-name-null { 879 when "../../../MA-name-format = name-format-null"; 880 type empty; 881 } 882 } 884 } 886 } 888 grouping MEP-ID { 889 choice MEP-ID { 890 default "MEP-ID-int"; 891 case MEP-ID-int { 892 leaf MEP-ID-int { 893 type int32; 894 } 895 } 897 } 898 leaf MEP-ID-format { 899 type identityref { 900 base identifier-format; 901 } 903 } 904 } 906 grouping MEP { 907 status current; 908 description 909 "Defines elements within the MEP"; 910 leaf mep-name { 911 mandatory true; 912 type MEP-name; 913 status current; 914 description 915 "Generic administrative name of the MEP"; 916 } 917 uses MEP-ID; 919 uses mp-address; 920 uses connectivity-context; 921 leaf Interface { 922 type if:interface-ref; 923 description 924 "Interface name as defined by ietf-interfaces"; 925 } 927 } 929 grouping monitor-stats { 930 leaf tx-packt-count { 931 type oam-counter32; 932 description 933 "Transmitted Packet count"; 934 } 935 leaf rx-packet-count { 936 type oam-counter32; 937 description 938 "Received packet count"; 939 } 940 leaf min-delay { 941 units "milliseconds"; 942 type oam-counter32; 943 description 944 "Delay is specified in milliseconds"; 945 } 946 leaf average-delay { 947 units "milliseconds"; 948 type oam-counter32; 949 description 950 "average delay in milliseconds"; 951 } 952 leaf max-delay { 953 type oam-counter32; 954 units "millisecond"; 955 } 956 } 958 grouping MIP { 959 description 960 "defines MIP"; 961 leaf interface { 962 type if:interface-ref; 963 } 964 } 966 grouping related-oam-layer { 967 leaf offset { 968 type int32 { 969 range "-255..255"; 970 } 971 description 972 "defines offset (in MD levels) to a related OAM layer 973 +1 is the layer immediately above 974 -1 is the layer immediately below"; 975 } 976 uses maintenance-domain-id; 977 uses ma-identifier; 978 } 980 grouping interface-status { 981 description 982 "collection of interface related status"; 983 leaf admin-status { 984 config false; 985 type leafref { 986 path "/if:interfaces-state/if:interface/if:admin-status"; 987 } 988 description 989 "oper status from ietf-interface module"; 990 } 991 leaf oper-status { 992 config false; 993 type leafref { 994 path "/if:interfaces-state/if:interface/if:oper-status"; 995 } 996 description 997 "oper status from ietf-interface module"; 998 } 999 } 1001 grouping connectivity-context { 1002 description 1003 "Grouping defining the connectivity context for an MA; for 1004 example, a VRF for IP, or an LSP for MPLS. This will be 1005 augmented by each protocol who use this component"; 1006 choice connectivity-context { 1007 default "context-null"; 1008 case context-null { 1009 description 1010 "this is a place holder when no context is needed"; 1011 leaf context-null { 1012 type empty; 1013 description 1014 "there is no context define"; 1015 } 1016 } 1017 } 1018 } 1020 grouping priority { 1021 description 1022 "Priority used in transmitted packets; for example, in the 1023 TOS/DSCP field in IP or the Traffic Class field in MPLS"; 1024 leaf priority { 1025 type uint8; 1026 } 1027 } 1029 grouping flow-entropy { 1030 description 1031 "defines the grouping statement for flow-entropy"; 1032 choice flow-entropy { 1033 default "flow-entropy-null"; 1034 case flow-entropy-null { 1035 description 1036 "this is a place holder when no flow entropy is needed"; 1037 leaf flow-entropy-null { 1038 type empty; 1039 description 1040 "there is no flow entropy defined"; 1041 } 1042 } 1043 } 1044 } 1046 container domains { 1047 status current; 1048 config true; 1049 description 1050 "Contains configuration related data. Within the container 1051 is list of fault domains. Wihin each domian has List of MA."; 1052 list domain { 1053 key "technology MD-name-string"; 1054 ordered-by system; 1055 status current; 1056 config true; 1057 description 1058 "Define the list of Domains within the IETF-OAM"; 1059 uses maintenance-domain-id; 1060 uses MD-name; 1061 leaf md-level { 1062 mandatory true; 1063 status current; 1064 description 1065 "Defines the MD-Level"; 1066 type MD-level; 1067 } 1068 container MAs { 1069 status current; 1070 config true; 1071 description 1072 "This container defines MA, within that have multiple MA 1073 and within MA have MEP, MIP"; 1074 list MA { 1075 ordered-by system; 1076 status current; 1077 config true; 1078 key "MA-name-string"; 1079 uses ma-identifier; 1080 uses MA-name; 1081 uses connectivity-context; 1082 leaf mep-direction { 1083 type MEP-direction; 1084 mandatory true; 1085 description 1086 "Direction for MEPs in this MA"; 1087 } 1088 leaf interval { 1089 default "0"; 1090 description 1091 "Defines default Keepalive/CC Interval. May be 1092 overridden for specific sessions if supported by the 1093 protocol."; 1094 type Interval; 1095 } 1096 leaf loss-threshold { 1097 default "3"; 1098 type uint32; 1099 description 1100 "number of consecutive Keepalive/CC messages missed 1101 before declaring loss of continuity fault. This is 1102 monitored per each remote MEP session"; 1103 } 1104 leaf ttl { 1105 type uint8; 1106 default "255"; 1107 } 1108 uses flow-entropy { 1109 description 1110 "Default flow entropy in this MA, which may be 1111 overridden for particular MEPs, sessions or 1112 operations"; 1113 } 1114 uses priority { 1115 description 1116 "Default priority for this MA, which may be overridden 1117 for particular MEPs, sessions or operations."; 1118 } 1119 list MEP { 1120 key "mep-name"; 1121 ordered-by system; 1122 status current; 1123 config true; 1124 description 1125 "contain list of MEPS"; 1126 uses MEP { 1127 status current; 1128 } 1129 uses interface-status { 1130 description 1131 "status of associated interface"; 1132 } 1133 uses flow-entropy; 1134 uses priority; 1135 list session { 1136 key "session-cookie"; 1137 ordered-by user; 1138 config true; 1139 description 1140 "Monitoring session to/from a particular remote MEP. 1141 Depending on the protocol, this could represent CC 1142 messages received from a single remote MEP (if the 1143 protocol uses multicast CCs) or a target to which 1144 unicast echo request CCs are sent and from which 1145 responses are received (if the protocol uses a 1146 unicast request/response mechanism)."; 1147 leaf session-cookie { 1148 config true; 1149 type uint32; 1150 description 1151 "Cookie to identify different sessions, when there 1152 are multiple remote MEPs or multiple sessions to 1153 the same remote MEP."; 1154 } 1155 leaf ttl { 1156 config true; 1157 type uint8; 1158 default "255"; 1159 } 1160 leaf interval { 1161 type Interval; 1162 description 1163 "Transmission interval for CC packets for this 1164 session."; 1165 } 1166 leaf enable { 1167 default "false"; 1168 config true; 1169 type boolean; 1170 description 1171 "enable or disable a monitor session"; 1172 } 1173 leaf ecmp-choice { 1174 config true; 1175 type ecmp-choices; 1176 description 1177 "0 means use the specified interface 1178 1 means use round robin"; 1179 } 1180 leaf source-mep { 1181 type MEP-name; 1182 description 1183 "Source MEP for this session, if applicable"; 1184 } 1185 container destination-mep { 1186 uses MEP-ID; 1187 } 1188 container destination-mep-address { 1189 uses mp-address; 1190 } 1191 uses connectivity-context; 1192 uses flow-entropy; 1193 uses priority; 1194 list outgoing-interface { 1195 key "interface"; 1196 config true; 1197 leaf interface { 1198 type leafref { 1199 path "/if:interfaces/if:interface/if:name"; 1200 } 1201 config true; 1202 } 1203 } 1204 } 1205 } 1206 list MIP { 1207 key "interface"; 1208 uses MIP; 1210 } 1211 list related-oam-layer { 1212 key "offset"; 1213 description 1214 "List of OAM layers above and below that are related to 1215 current MA. This allow users to easily navigate up and 1216 down to efficiently troubleshoot a connectivity 1217 issue"; 1218 uses related-oam-layer; 1219 } 1220 } 1221 } 1222 } 1223 } 1224 notification RDI-notification { 1225 description 1226 "When RDI is received this notificiation is sent"; 1227 uses maintenance-domain-id { 1228 description 1229 "defines the MD (Maintenance Domain) identifier, which is the 1230 Generic MD-name-string and the technology."; 1231 } 1232 uses ma-identifier; 1233 leaf mep-name { 1234 type MEP-name; 1235 description 1236 "Indicate which MEP is seeing the error"; 1237 } 1238 container remote-mepid { 1239 uses MEP-ID; 1240 description 1241 "Who is seeing the error (if known) if unknown make it 0."; 1242 } 1243 leaf error-message { 1244 type string { 1245 length "0..255"; 1246 } 1247 description 1248 "Error message to indicate more details."; 1249 } 1250 } 1251 rpc ping { 1252 description 1253 "Generates Ping and return response"; 1254 input { 1255 uses maintenance-domain-id { 1256 description 1257 "defines the MD (Maintenance Domain) identifier, which is 1258 the generic 1259 MD-name-string and the technology."; 1260 } 1262 uses ma-identifier { 1263 description 1264 "identfies the Maintenance association"; 1265 } 1266 uses flow-entropy; 1267 uses priority; 1268 leaf ttl { 1269 type uint8; 1270 default "255"; 1271 } 1272 leaf ecmp-choice { 1273 type ecmp-choices; 1274 description 1275 "0 means use the specified interface 1276 1 means use round robin"; 1277 } 1278 leaf sub-type { 1279 type identityref { 1280 base command-sub-type; 1281 } 1282 description 1283 "defines different command types"; 1284 } 1285 list outgoing-interfaces { 1286 key "interface"; 1287 leaf interface { 1288 type if:interface-ref; 1289 } 1290 } 1291 leaf source-mep { 1292 type MEP-name; 1293 } 1294 container destination-mp { 1295 uses mp-address; 1296 uses MEP-ID { 1297 description "Only applicable if the destination is a MEP"; 1298 } 1299 } 1300 leaf count { 1301 type uint32; 1302 default "3"; 1303 description 1304 "Number of ping echo request message to send"; 1305 } 1306 leaf interval { 1307 type Interval; 1308 description 1309 "Interval between echo requests"; 1310 } 1311 leaf packet-size { 1312 type uint32 { 1313 range "64..10000"; 1314 } 1315 default "64"; 1316 description 1317 "Size of ping echo request packets, in octets"; 1318 } 1319 } 1320 output { 1321 uses monitor-stats { 1322 description 1323 "Stats of Ping is same as that of monitor sessions"; 1324 } 1325 } 1326 } 1327 rpc trace-route { 1328 description 1329 "Generates Trace-route and return response. Starts with TTL 1330 of one and increment by one at each hop. Untill destination 1331 reached or TTL reach max valune"; 1332 input { 1333 uses maintenance-domain-id { 1334 description 1335 "defines the MD (Maintenance Domain) identifier, which is 1336 the generic 1337 MD-name-string and the technology."; 1338 } 1339 uses ma-identifier { 1340 description 1341 "identfies the Maintenance association"; 1342 } 1343 uses flow-entropy; 1344 uses priority; 1345 leaf ttl { 1346 type uint8; 1347 default "255"; 1348 } 1349 leaf command-sub-type { 1350 type identityref { 1351 base command-sub-type; 1352 } 1353 description 1354 "defines different command types"; 1355 } 1356 leaf ecmp-choice { 1357 type ecmp-choices; 1358 description 1359 "0 means use the specified interface 1360 1 means use round robin"; 1361 } 1362 list outgoing-interfaces { 1363 key "interface"; 1364 leaf interface { 1365 type if:interface-ref; 1366 } 1367 } 1368 leaf source-mep { 1369 type MEP-name; 1370 } 1371 container destination-mp { 1372 uses mp-address; 1373 uses MEP-ID { 1374 description "Only applicable if the destination is a MEP"; 1375 } 1376 } 1377 leaf count { 1378 type uint32; 1379 default "1"; 1380 description 1381 "Number of traceroute probes to send. In protocols where a 1382 separate message is sent at each TTL, this is the number 1383 of packets to send at each TTL."; 1384 } 1385 leaf interval { 1386 type Interval; 1387 description 1388 "Interval between echo requests"; 1389 } 1390 } 1391 output { 1392 list response { 1393 key "response-index"; 1394 leaf response-index { 1395 description 1396 "Arbitrary index for the response. In protocols that 1397 guarantee there is only a single response at each TTL 1398 (eg IP Traceroute), the TTL can be used as the response 1399 index."; 1400 type uint8; 1401 } 1402 leaf ttl { 1403 type uint8; 1404 } 1405 container destination-mp { 1406 description "MP from which the response has been received"; 1407 uses mp-address; 1408 uses MEP-ID { 1409 description 1410 "Only applicable if the destination is a MEP"; 1411 } 1412 } 1413 uses monitor-stats { 1414 description 1415 "If count is 1, there is a single delay value reported."; 1416 } 1417 } 1418 } 1419 } 1420 } 1421 1423 Figure 6 YANG module of OAM 1425 7. Base Mode for IP 1427 The Base Mode defines default configuration that MUST be present in 1428 the devices that comply with this document. Base Mode allows users to 1429 have "zero-touch" experience. Several parameters require technology 1430 specific definition. 1432 7.1. MEP Address 1434 In the Base Mode of operation, the MEP Address is the IP address of 1435 the interface on which the MEP is located. 1437 7.2. MEP ID for Base Mode 1439 In the Base Mode of operation, each device creates a single UP MEP 1440 associated with a virtual OAM port with no physical layer (NULL PHY). 1441 The MEPID associated with this MEP is zero (0). The choice of MEP-ID 1442 zero is explained below. 1444 MEPID is 2 octet field. It is never used on the wire except when 1445 using CCM. Ping, traceroute and session monitoring does not use the 1446 MEPID on its message header. It is important to have method that can 1447 derive MEP ID of base mode in an automatic manner with no user 1448 intervention. IP address cannot be directly used for this purpose as 1449 the MEP ID is much smaller field. For Base Mode of IP we propose to 1450 use MEP ID zero (0) as the default MEP-ID. 1452 CCM packet use MEP-ID on the paylod. CCM MUST NOT be used in the Base 1453 Mode for IP. Hence CCM MUST be disabled on the Maintenance 1454 Association of the Base Mode. 1456 If CCM is required, users MUST configure a separate Maintenance 1457 association and assign unique value for the corresponding MEP IDs. 1459 [8021Q] CFM defines MEP ID as an unsigned integer in the range 1 to 1460 8191. In this document we propose to extend the range to 0 to 65535. 1461 Value 0 is reserved for MEP ID of Base Mode of IP and MUST NOT be 1462 used for other purposes. 1464 7.3. Maintenance Domain 1466 Default MD-LEVEL is set to 3. 1468 7.4. Maintenance Association 1470 MAID [8021Q] has a flexible format and includes two parts: 1471 Maintenance Domain Name and Short MA name. In the Based Mode of 1472 operation, the value of the Maintenance Domain Name must be the 1473 character string "GenericBaseMode" (excluding the quotes "). In Base 1474 Mode operation Short MA Name format is set to 2-octet integer format 1475 (value 3 in Short MA Format field [8021Q]) and Short MA name set to 1476 65532 (0xFFFC). 1478 8. Security Considerations 1480 TBD 1482 9. IANA Considerations 1484 This document registers the following namespace URI in the IETF XML 1485 registry. 1487 URI:TBD 1489 10. References 1491 10.1. Normative References 1493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1494 Requirement Levels", BCP 14, RFC 2119, March 1997. 1496 [RFC792] Postel, J., "Internet Control Message Protocol", STD 1497 5,RFC 792, September 1981. 1499 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 1500 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 1501 2011. 1503 10.2. Informative References 1505 [Y1731] ITU, "OAM functions and mechanisms for Ethernet based 1506 networks", ITU-T G.8013/Y.1731, July, 2011. 1508 [RFC7174] Salam, S., et.al., "TRILL OAM Framework", RFC7174, May 1509 2014. 1511 [RFC6291] Andersson, L., et.al., "Guidelines for the use of the "OAM" 1512 Acronym in the IETF" RFC 6291, June 2011. 1514 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 1515 Protocol Specification", RFC 6325, July 2011. 1517 [OAMOVW] Mizrahi, T., et.al., "An Overview of Operations, 1518 Administration, and Maintenance (OAM) Tools", draft-ietf- 1519 opsawg-oam-overview-16, Work in Progress, March 2014. 1521 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1522 Control Message Protocol (ICMPv6) for the Internet 1523 Protocol Version 6 (IPv6) Specification", RFC 4443, 1524 March 2006. 1526 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1527 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1528 February 2006. 1530 [RFC6371] Busi, I., et.al., "Operations, Administration, and 1531 Maintenance Framework for MPLS-Based Transport Networks, 1532 RFC 6317, September 2011. 1534 [TRILLOAMFM] Senevirathne, T., et.al., "TRILL OAM Fault Management", 1535 draft-ietf-trill-oam-fm, Work in Progress, May 2014. 1537 11. Acknowledgments 1539 Giles Heron came up with the idea of developing a YANG model as a way 1540 of creating a unified OAM API set (interface), work in this document 1541 is largely an inspiration of that. Alexander Clemm provided many 1542 valuable tips, comments and remarks that helped to refine the YANG 1543 model presented in this document. 1545 Carlos Pignataro, David Ball and others participated and contributed 1546 to this document. 1548 This document was prepared using 2-Word-v2.0.template.dot. 1550 12. Contributors 1552 Tissa Senevirathne, Norman Finn, Samer Salam, Deepak Kumar, Qin Wu, 1553 David Ball. 1555 Authors' Addresses 1557 Tissa Senevirathne 1558 CISCO Systems 1559 375 East Tasman Drive. 1560 San Jose, CA 95134 1561 USA. 1563 Phone: 408-853-2291 1564 Email: tsenevir@cisco.com 1566 Norman Finn 1567 CISCO Systems 1568 510 McCarthy Blvd 1569 Milpitas, CA 95035. 1571 Email: nfinn@cisco.com 1572 Deepak Kumar 1573 CISCO Systems 1574 510 McCarthy Blvd 1575 Milpitas, CA 95035. 1577 Email: dekumar@cisco.com 1579 Samer Salam 1580 CISCO Systems 1581 595 Burrard St. Suite 2123 1582 Vancouver, BC V7X 1J1, Canada 1584 Email: ssalam@cisco.com 1586 Qin Wu 1587 Huawei 1588 101 Software Avenue, Yuhua District 1589 Nanjing, Jiangsu 210012 1591 Email: bill.wu@huawei.com