idnits 2.17.1 draft-tissa-netmod-oam-01.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 372 has weird spacing: '...-format int...' == Line 431 has weird spacing: '... rw for c...' == Line 432 has weird spacing: '... ro for n...' == Line 512 has weird spacing: '...terface lea...' == Line 525 has weird spacing: '...terface if:...' == (3 more instances...) -- 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: 'MA-domain-name' is mentioned on line 370, 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 NETMOD 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 Generic Operations, Administration, and 12 Maintenance (OAM) 13 draft-tissa-netmod-oam-01.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 YANG Data model for OAM. It provides a 56 protocol-independent and technology-independent abstraction of key 57 OAM constructs. These abstractions span OAM configuration and 58 operational data; they promote uniformity between OAM technologies 59 and support nested OAM workflows (i.e., performing OAM functions at 60 different layers through a unified interface). 62 Table of Contents 64 1. Introduction...................................................2 65 2. Conventions used in this document..............................4 66 2.1. Terminology...............................................4 67 3. Architecture of OAM YANG Model.................................5 68 4. Overview of the OAM Model......................................6 69 4.1. Maintenance Domain (MD) configuration.....................7 70 4.2. Maintenance Association (MA) configuration................7 71 4.3. Maintenance Endpoint (MEP) configuration..................8 72 4.4. rpc definitions...........................................9 73 5. OAM data hierarchy............................................11 74 6. OAM YANG module...............................................17 75 7. Base Mode for IP..............................................33 76 7.1. MEP Address..............................................33 77 7.2. MEP ID for Base Mode.....................................34 78 7.3. Maintenance Domain.......................................34 79 7.4. Maintenance Association..................................34 80 8. Security Considerations.......................................34 81 9. IANA Considerations...........................................35 82 10. References...................................................35 83 10.1. Normative References....................................35 84 10.2. Informative References..................................35 85 11. Acknowledgments..............................................36 87 1. Introduction 89 Operations, Administration, and Maintenance (OAM) are important 90 networking functions that allow operators to: 92 1. Configure networks 94 2. Monitor networks (Connectivity Verification, Continuity Check) 96 3. Troubleshoot failures (Fault verification and isolation). 98 An overview of OAM tools is presented at [OAMOVW]. 100 Ping and Traceroute [RFC792], [RFC4443] are well-known fault 101 verification and isolation tools, respectively, for IP networks. Over 102 the years different technologies have developed similar tools for 103 similar purposes. 105 [8021Q] Connectivity Fault Management is a well-established OAM 106 standard that is widely adopted for Ethernet networks. ITU-T [Y1731], 107 MEF Service OAM, MPLS-TP [RFC6371], TRILL [TRILLOAMFM] all define OAM 108 methods based on [8021Q] CFM. 110 Given the wide adoption of the underlying OAM concepts defined in 111 [8021Q] CFM, it is a reasonable choice to develop the unified OAM 112 framework based on those concepts. In this document, we take the 113 [8021Q] CFM model and extend it to a technology independent framework 114 and build the corresponding YANG model accordingly. The YANG model 115 presented in this document is the base model and supports IP Ping and 116 Traceroute. The generic OAM YANG model is designed such that it can 117 be extended to cover various technologies. Technology dependent nodes 118 and RPC commands are defined in technology specific YANG models, 119 which use and extend the base model defined here. As an example, 120 VXLAN uses source UDP port number for flow entropy, while MPLS 121 [RFC4379] uses IP addresses or the label stack for flow entropy in 122 the hashing for multipath selection. To capture this variation, 123 corresponding YANG models would define the applicable structures as 124 augmentation to the generic base model presented here. This 125 accomplishes three purposes: first it keeps each YANG model smaller 126 and manageable. Second, it allows independent development of 127 corresponding YANG models. Third, implementations can limit support 128 to only the applicable set of YANG models. (e.g. TRILL RBridge may 129 only need to implement Generic OAM model and the TRILL YANG model). 131 All implementations that follow the YANG framework presented in this 132 document MUST implement the generic OAM YANG model presented here. 134 The unification of OAM, according to the proposal of this document, 135 occurs at the management layer. Encapsulations and state machines may 136 differ according to each protocol. A user who wishes to issues a Ping 137 command or a Traceroute or initiate a performance monitoring session 138 can do so in the same manner regardless of the underlying protocol or 139 technology. 141 As an example, consider a scenario where an IP ping from device A to 142 Device B failed. Between device A and B there are IEEE 802.1 bridges 143 a,b and c. Let's assume a,b and c are using [8021Q] CFM. A user upon 144 detecting the IP layer ping failure, may decide to drill down to the 145 Ethernet layer and issue the corresponding fault verification (LBM) 146 and fault isolation (LTM) tools, using the same API. This ability to 147 go up and down to different layers for troubleshooting is referred to 148 as "nested OAM workflow" and is a useful concept that leads to 149 efficient network troubleshooting and maintenance. The OAM YANG model 150 presented in this document facilitates that without needing changes 151 to the underlying protocols. 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC-2119 [RFC2119]. 159 In this document, these words will appear with that interpretation 160 only when in ALL CAPS. Lower case uses of these words are not to be 161 interpreted as carrying RFC-2119 significance. 163 2.1. Terminology 165 CCM - Continuity Check Message [8021Q] 167 ECMP - Equal Cost Multipath 169 LBM - Loopback Message [8021Q] 171 MP - Maintenance Point [8021Q] 173 MEP - Maintenance End Point [RFC7174] [8021Q] [RFC6371] 175 MIP - Maintenance Intermediate Point [RFC7174] [8021Q] [RFC6371] 177 MA - Maintenance Association [8021Q] [RFC7174] 179 MD - Maintenance Domain [8021Q] 181 MTV - Multi-destination Tree Verification Message 183 OAM - Operations, Administration, and Maintenance [RFC6291] 184 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 186 3. Architecture of OAM YANG Model 188 In this document we define the YANG model for Generic OAM. The YANG 189 model defined here is generic such that other technologies can extend 190 it for technology specific needs. The Generic OAM YANG model acts as 191 the root for other OAM YANG models. This allows users to traverse 192 between OAM of different technologies at ease through a uniform API 193 set. This is also provides a nested OAM workflow. Figure 1 depicts 194 the relationship of different OAM YANG models to the Generic OAM YANG 195 Model. Some technologies may have different sub-technologies. As an 196 example, consider Network Virtualization Overlays. These could employ 197 either vXLAN or NVGRE as encapsulation. The Generic OAM YANG model 198 provides a framework where technology-specific YANG models can 199 inherit constructs from parent YANG models without needing to 200 redefine them within the sub-technology. 202 Figure 1 depicts relationship of different YANG modules. 204 +-+-+-+-+-+ 205 | gen | 206 |OAM YANG | 207 +-+-+-+-+-+ 208 | 209 O 210 | 211 +---------------------------------------------------------+ 212 | | | | | 213 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 214 | TRILL | | NVO3 | | MPLS | | IP | . . .| foo | 215 |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | 216 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 217 | | | | | 218 | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 219 | | NVO3 | | MPLS | | IP | . . .| foo | 220 | |sub tech | |sub tech | |OAM YANG | |sub tec | 221 | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 222 | | | | | 223 | | | | | 224 +------------------------------------------------------------+ 225 | Uniform API | 226 +------------------------------------------------------------+ 228 Figure 1 Relationship of TRILL OAM YANG model to generic YANG model 230 4. Overview of the OAM Model 232 In this document we adopt the concepts of the [8021Q] CFM model and 233 structure it such that it can be adapted to different technologies. 235 At the top of the Model is the Maintenance Domain. Each Maintenance 236 Domain is associated with a Maintenance Name and a Domain Level. 238 Under each Maintenance Domain there is one or more Maintenance 239 Association (MA). In IP, the MA can be per IP Subnet, in NVO3 this 240 can be per VNI and for TRILL this can be per Fine-Grained Label or 241 for VPLS this can be per VPLS instance. 243 Under each MA, there can be two or more MEPs (Maintenance End 244 Points). MEPs are addressed by their respective technology specific 245 address identifiers. The YANG model presented here provides 246 flexibility to accommodate different addressing schemes. 248 In a parallel vertical, presented are the commands. Those, in YANG 249 terms, are the rpc commands. These rpc commands provide uniform APIs 250 for ping, traceroute and their equivalents as well as other OAM 251 commands. 253 [8021Q] CFM framework requires explicit configuration of OAM entities 254 prior to using any of the OAM tools. Users of Ping and Traceroute 255 tools within IP devices are expecting ability to use OAM tools with 256 no explicit configuration. In order to facilitate zero-touch 257 experience, this document defines a default mode of OAM. The default 258 mode of OAM is referred to as the Base Mode and specifies default 259 values for each of the [8021Q] CFM parameters, such as Maintenance 260 Domain Level, Name of the Maintenance Association and Addresses of 261 MEP and so on. The default values of these depend on the technology. 262 Base Mode for TRILL is defined in [TRILLOAMFM]. Section X of this 263 document specifies the Base mode for IP devices. Base mode for other 264 technologies such as NVO3, MPLS and future extensions will be defined 265 in their corresponding documents. 267 It is important to note that, no specific enhancements are needed in 268 the YANG model to support Base Mode. Implementations that comply with 269 this document, by default implement the data nodes of the applicable 270 technology. Data nodes of the Base Mode are read-only nodes. 272 4.1. Maintenance Domain (MD) configuration 274 The container "domains" is the top level container within the ietf- 275 oam module. Within the container "domains", separate list is 276 maintained per MD. The MD list uses the key MD-name for indexing. 278 module: ietf-oam 279 +--rw domains 280 | +--rw domain* [md-name] 281 | +--rw technology identityref 282 | +--rw md-name-format MD-name-format 283 | +--rw md-name binary 284 | +--rw md-level int32 286 . 287 . 289 Figure 1 Snippet of data hierarchy related to OAM domains 291 4.2. Maintenance Association (MA) configuration 293 Within a given Maintenance Domain there can be one or more 294 Maintenance Associations (MA). MAs are represented as a list and 295 indexed by the MA-name. 297 module: ietf-oam 298 +--rw domains 299 | +--rw domain* [md-name] 300 | +--rw technology identityref 301 | +--rw md-name-format MD-name-format 302 | +--rw md-name binary 303 | +--rw md-level int32 304 | +--rw MAs! 305 | +--rw MA* [ma-name] 306 | +--rw ma-name-format MA-name-format 307 | +--rw ma-name binary 308 . 309 . 311 Figure 2 Snippet of data hierarchy related to Maintenance 312 Associations (MA). 314 4.3. Maintenance Endpoint (MEP) configuration 316 Within a given Maintenance Association (MA), there can be one or more 317 Maintenance End Points (MEP). MEPs are represented as a list within 318 the data hierarchy and indexed by the key MEP-id. 320 module: ietf-oam 321 +--rw domains 322 | +--rw domain* [md-name] 323 | +--rw technology identityref 324 | +--rw md-name-format MD-name-format 325 | +--rw md-name binary 326 | +--rw md-level int32 327 | +--rw MAs! 328 | +--rw MA* [ma-name] 329 | +--rw ma-name-format MA-name-format 330 | +--rw ma-name binary 332 . 333 . 335 +--rw MEP* [mep-id] 336 | +--rw mep-id MEP-id 337 | +--rw mep-name? string 338 | +--rw mep-direction MEP-direction 339 | +--rw ccm-Tx-enable? boolean 340 | +--rw (mep-address)? 341 | | +--:(mac-address) 342 | | | +--rw mac-address? yang:mac-address 343 | | +--:(ipv4-address) 344 | | | +--rw ipv4-address? inet:ipv4-address 345 | | +--:(ipv6-address) 346 | | +--rw ipv6-address? inet:ipv6-address 347 | +--rw (context-id)? 348 | | +--:(context-null) 349 . 350 . 351 . 353 Figure 3 Snippet of data hierarchy related to Maintenance Endpoint 354 (MEP). 356 4.4. rpc definitions 358 The rpc model facilitates issuing commands to a NETCONF server (in 359 this case to the device that need to execute the OAM command) and 360 obtain a response. rpc model defined here abstracts OAM specific 361 commands in a technology independent manner. 363 There are several rpc commands defined for the purpose of OAM. In 364 this section we present a snippet of the ping command for 365 illustration purposes. Please refer to Section 4 for the complete 366 data hierarchy and Section 5 for the YANG model. 368 module: ietf-oam 369 +--rw domains 370 | +--rw Domain* [MA-domain-name] 371 | +--rw technology technology 372 | +--rw MA-domain-name-format int32 373 | +--rw MA-domain-name binary 374 | +--rw MD-level int32 376 . 377 . 379 rpcs: 380 +---x ping 381 | +--ro input 382 | | +--ro technology identityref 383 | | +--ro md-name-format MD-name-format 384 | | +--ro md-name? binary 385 | | +--ro md-level int32 386 | | +--ro ma-name-format MA-name-format 387 | | +--ro ma-name binary 388 | | +--ro (context-id)? 389 | | | +--:(context-null) 390 | | | +--ro context-null? empty 391 | | +--ro (flow-entropy)? 392 | | | +--:(flow-entropy-null) 393 | | +--ro ttl? uint8 394 . 395 . 396 | | +--ro source-mep 397 | | | +--ro (mep-address)? 398 . 399 . 400 | | | +--ro mep-id? MEP-id 401 | | +--ro destination-mep 402 | | +--ro (mep-address)? 403 . 404 . 405 | +--ro output 406 | +--ro tx-packt-count? oam-counter32 407 | +--ro rx-packet-count? oam-counter32 408 | +--ro min-delay? oam-counter32 409 | +--ro average-delay? oam-counter32 410 | +--ro max-delay? oam-counter32 412 Figure 4 Snippet of data hierarchy related to rpc call Ping 414 5. OAM data hierarchy 416 The complete data hierarchy related to the OAM YANG model is 417 presented below. The following notations are used within the data 418 tree and carry the meaning as below. 420 Each node is printed as: 422 424 is one of: 425 + for current 426 x for deprecated 427 o for obsolete 429 is one of: 431 rw for configuration data 432 ro for non-configuration data 433 -x for rpcs 434 -n for notifications 436 is the name of the node 438 If the node is augmented into the tree from another module, its 439 name is printed as :. 441 is one of: 443 ? for an optional leaf or choice 444 ! for a presence container 445 * for a leaf-list or list 446 [] for a list's keys 448 is the name of the type for leafs and leaf-lists 449 module: gen-oam 450 +--rw domains 451 +--rw domain* [md-name technology] 452 +--rw technology identityref 453 +--rw md-name-format MD-name-format 454 +--rw md-name binary 455 +--rw md-level int32 456 +--rw MAs! 457 +--rw MA* [ma-name] 458 +--rw ma-name-format MA-name-format 459 +--rw ma-name binary 460 +--rw (context-id)? 461 | +--:(context-null) 462 | +--rw context-null? empty 463 +--rw ccm-Interval? CCM-Interval 464 +--rw ccm-loss-threshold? uint32 465 +--rw ccm-ttl? uint8 466 +--rw (flow-entropy)? 467 | +--:(flow-entropy-null) 468 +--rw MEP* [mep-id] 469 | +--rw mep-id MEP-id 470 | +--rw mep-name? string 471 | +--rw mep-direction MEP-direction 472 | +--rw ccm-Tx-enable? boolean 473 | +--rw (mep-address)? 474 | | +--:(mac-address) 475 | | | +--rw mac-address? yang:mac-address 476 | | +--:(ipv4-address) 477 | | | +--rw ipv4-address? inet:ipv4-address 478 | | +--:(ipv6-address) 479 | | +--rw ipv6-address? inet:ipv6-address 480 | +--rw (context-id)? 481 | | +--:(context-null) 482 | | +--rw context-null? empty 483 | +--rw Interface? if:interface-ref 484 | +--ro admin-status? leafref 485 | +--ro oper-status? leafref 486 | +--rw (flow-entropy)? 487 | | +--:(flow-entropy-null) 488 | +--rw session* [user-cookie destination-mepid] 489 | +--rw user-cookie uint32 490 | +--rw ttl? uint8 491 | +--rw interval? uint32 492 | +--rw enable? boolean 493 | +--rw ecmp-choice? ecmp-choices 494 | +--rw destination-mepid MEP-id 495 | +--rw destination-mep-address 496 | | +--rw (mep-address)? 497 | | +--:(mac-address) 498 | | | +--rw mac-address? yang:mac-address 499 | | +--:(ipv4-address) 500 | | | +--rw ipv4-address? inet:ipv4-address 501 | | +--:(ipv6-address) 502 | | +--rw ipv6-address? inet:ipv6-address 503 | +--ro ccm-rdi-indicator? boolean 504 | +--ro ccm-xcon-count? oam-counter32 505 | +--ro ccm-xcon-Indicator? boolean 506 | +--rw (context-id)? 507 | | +--:(context-null) 508 | | +--rw context-null? empty 509 | +--rw (flow-entropy)? 510 | | +--:(flow-entropy-null) 511 | +--rw outgoing-interface* [interface] 512 | +--rw interface leafref 513 +--rw remote-MEP* [mep-id] 514 | +--rw mep-id uint32 515 | +--rw (mep-address)? 516 | | +--:(mac-address) 517 | | | +--rw mac-address? yang:mac-address 518 | | +--:(ipv4-address) 519 | | | +--rw ipv4-address? inet:ipv4-address 520 | | +--:(ipv6-address) 521 | | +--rw ipv6-address? inet:ipv6-address 522 | +--rw mep-name? string 523 | +--rw ccm-rx-error-count? oam-counter32 524 +--rw MIP* [interface direction] 525 | +--rw interface if:interface-ref 526 | +--rw direction MEP-direction 527 +--ro ccm-rdi-indicator? boolean 528 +--ro ccm-xcon-count? oam-counter32 529 +--ro ccm-xcon-Indicator? boolean 530 +--rw nested-oam-layer* [offset] 531 +--rw offset int8 532 +--rw technology identityref 533 +--rw md-name-format MD-name-format 534 +--rw md-name? binary 535 +--rw md-level int32 536 +--rw ma-name-format MA-name-format 537 +--rw ma-name binary 538 rpcs: 539 +---x ping 540 | +--ro input 541 | | +--ro technology identityref 542 | | +--ro md-name-format MD-name-format 543 | | +--ro md-name? binary 544 | | +--ro md-level int32 545 | | +--ro ma-name-format MA-name-format 546 | | +--ro ma-name binary 547 | | +--ro (context-id)? 548 | | | +--:(context-null) 549 | | | +--ro context-null? empty 550 | | +--ro (flow-entropy)? 551 | | | +--:(flow-entropy-null) 552 | | +--ro ttl? uint8 553 | | +--ro ecmp-choice? ecmp-choices 554 | | +--ro sub-type? identityref 555 | | +--ro outgoing-interfaces* [interface] 556 | | | +--ro interface if:interface-ref 557 | | +--ro source-mep 558 | | | +--ro (mep-address)? 559 | | | | +--:(mac-address) 560 | | | | | +--ro mac-address? yang:mac-address 561 | | | | +--:(ipv4-address) 562 | | | | | +--ro ipv4-address? inet:ipv4-address 563 | | | | +--:(ipv6-address) 564 | | | | +--ro ipv6-address? inet:ipv6-address 565 | | | +--ro mep-id? MEP-id 566 | | +--ro destination-mep 567 | | +--ro (mep-address)? 568 | | | +--:(mac-address) 569 | | | | +--ro mac-address? yang:mac-address 570 | | | +--:(ipv4-address) 571 | | | | +--ro ipv4-address? inet:ipv4-address 572 | | | +--:(ipv6-address) 573 | | | +--ro ipv6-address? inet:ipv6-address 574 | | +--ro mep-id? MEP-id 575 | +--ro output 576 | +--ro tx-packt-count? oam-counter32 577 | +--ro rx-packet-count? oam-counter32 578 | +--ro min-delay? oam-counter32 579 | +--ro average-delay? oam-counter32 580 | +--ro max-delay? oam-counter32 581 +---x trace-route 582 +--ro input 583 | +--ro technology identityref 584 | +--ro md-name-format MD-name-format 585 | +--ro md-name? binary 586 | +--ro md-level int32 587 | +--ro ma-name-format MA-name-format 588 | +--ro ma-name binary 589 | +--ro (context-id)? 590 | | +--:(context-null) 591 | | +--ro context-null? empty 592 | +--ro (flow-entropy)? 593 | | +--:(flow-entropy-null) 594 | +--ro ttl? uint8 595 | +--ro command-sub-type? identityref 596 | +--ro ecmp-choice? ecmp-choices 597 | +--ro outgoing-interfaces* [interface] 598 | | +--ro interface if:interface-ref 599 | +--ro source-mep 600 | | +--ro (mep-address)? 601 | | | +--:(mac-address) 602 | | | | +--ro mac-address? yang:mac-address 603 | | | +--:(ipv4-address) 604 | | | | +--ro ipv4-address? inet:ipv4-address 605 | | | +--:(ipv6-address) 606 | | | +--ro ipv6-address? inet:ipv6-address 607 | | +--ro mep-id? MEP-id 608 | +--ro destination-mep 609 | +--ro (mep-address)? 610 | | +--:(mac-address) 611 | | | +--ro mac-address? yang:mac-address 612 | | +--:(ipv4-address) 613 | | | +--ro ipv4-address? inet:ipv4-address 614 | | +--:(ipv6-address) 615 | | +--ro ipv6-address? inet:ipv6-address 616 | +--ro mep-id? MEP-id 617 +--ro output 618 +--ro response* [ttl] 619 +--ro ttl uint8 620 +--ro destination-mep 621 | +--ro (mep-address)? 622 | | +--:(mac-address) 623 | | | +--ro mac-address? yang:mac-address 624 | | +--:(ipv4-address) 625 | | | +--ro ipv4-address? inet:ipv4-address 626 | | +--:(ipv6-address) 627 | | +--ro ipv6-address? inet:ipv6-address 628 | +--ro mep-id? MEP-id 629 +--ro tx-packt-count? oam-counter32 630 +--ro rx-packet-count? oam-counter32 631 +--ro min-delay? oam-counter32 632 +--ro average-delay? oam-counter32 633 +--ro max-delay? oam-counter32 634 notifications: 635 +---n CCM-RDI-notification 636 +--ro mep-id? MEP-id 637 +--ro remote-mepid? MEP-id 638 +--ro error-message? string 640 Figure 5 data hierarchy of OAM 642 6. OAM YANG module 644 file "xxx.yang" 646 module gen-oam { 647 namespace "urn:cisco:params:xml:ns:yang:gen-oam"; 648 prefix goam; 650 import ietf-interfaces { 651 prefix if; 652 } 653 import ietf-yang-types { 654 prefix yang; 655 } 656 import ietf-inet-types { 657 prefix inet; 658 } 660 organization "IETF NETMOD (NETCONF Data Modeling ) Working Group"; 661 contact 662 "Tissa Senevirathne tsenevir@cisco.com"; 663 description 664 "This YANG module defines the generic configuration, 665 statistics and rpc for OAM to be used within IETF in 666 a protocol indpendent manner. Functional level 667 abstraction is indendent with YANG modeling. It is 668 assumed that each protocol maps corresponding 669 abstracts to its native format. 670 Each protocoal may extend the YANG model defined 671 here to include protocol specific extensions"; 673 revision 2014-04-17 { 674 description 675 "Initial revision. - 02 version"; 676 reference "draft-tissa-netmod-oam"; 677 } 679 identity technology-types { 680 description 681 "this is the base identity of technology types which are 682 vpls, nvo3, TRILL, ipv4, ipv6, mpls"; 683 } 685 identity ipv4 { 686 base technology-types; 687 description 688 "technology of ipv4"; 689 } 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 typedef MEP-direction { 711 type enumeration { 712 enum "Up" { 713 value 0; 714 } 715 enum "Down" { 716 value 1; 717 } 718 } 719 } 721 typedef MEP-id { 722 type uint32 { 723 range "1..8191"; 724 } 725 description 726 "Defines type for MEPIDm range is 1..8191"; 727 } 729 typedef CCM-Interval { 730 default "interval-1min"; 731 type enumeration { 732 enum "interval-invalid" { 733 value 0; 735 } 736 enum "interval-300hz" { 737 value 1; 738 } 739 enum "interval-10ms" { 740 value 2; 741 } 742 enum "interval-100ms" { 743 value 3; 744 } 745 enum "interval-1s" { 746 value 4; 747 } 748 enum "interval-10s" { 749 value 5; 750 } 751 enum "interval-1min" { 752 value 6; 753 } 754 enum "interval-10min" { 755 value 7; 756 } 757 } 758 reference 759 "802.2Q Rev5 or 802.ag, all of the above 760 are standard enumeration from the 802.1Q"; 761 description 762 "IntervalInvalid - value 0 763 Interval300Hz - Value 1 764 Intervale10ms - value 2 765 Interval100ms - value3 766 Interval1s - value 4 767 Interval10s - value 5 768 Interval1min - value 6 769 Interval10min - value 7"; 770 } 772 typedef ecmp-choices { 773 type enumeration { 774 enum "ecmp-use-platform-hash" { 775 value 0; 776 } 777 enum "ecmp-use-round-robin" { 778 value 1; 779 } 780 } 781 } 782 typedef MD-name-format { 783 type enumeration { 784 enum "ieee-reserved" { 785 value 0; 786 } 787 enum "none" { 788 value 1; 789 } 790 enum "dns-like-name" { 791 value 2; 792 } 793 enum "mac-address-and-uint" { 794 value 3; 795 reference "802.1Q Rev5"; 796 description 797 "Domain name 3 specifies domain name is mac-address + 2 798 octets."; 799 } 800 } 801 reference "802.1Q"; 802 description 803 "defines the domain name format"; 804 } 806 typedef MA-name-format { 807 type enumeration { 808 enum "ieee-reserved" { 809 value 0; 810 } 811 enum "primary-vid" { 812 value 1; 813 } 814 enum "char-string" { 815 value 2; 816 } 817 enum "unsigned-int16" { 818 value 3; 819 } 820 enum "rfc2865-vpnid" { 821 value 4; 822 } 823 } 824 reference "802.1Q"; 825 description 826 "Defines Format of MA-names"; 827 } 828 typedef oam-counter32 { 829 type yang:zero-based-counter32; 830 description 831 "defines 32 bit counter for OAM"; 832 } 834 grouping mep-address { 835 choice mep-address { 836 case mac-address { 837 leaf mac-address { 838 type yang:mac-address; 839 } 840 } 841 case ipv4-address { 842 leaf ipv4-address { 843 type inet:ipv4-address; 844 } 845 } 846 case ipv6-address { 847 leaf ipv6-address { 848 type inet:ipv6-address; 849 } 850 } 851 } 852 } 854 grouping maintenance-domain { 855 status current; 856 description 857 "Defines the MA-domain group"; 858 reference "802.1Q Rev5"; 859 leaf technology { 860 mandatory true; 861 status current; 862 type identityref { 863 base technology-types; 864 } 865 description 866 "Defines the technology"; 867 } 868 leaf md-name-format { 869 mandatory true; 870 status current; 871 description 872 "Defines the maintenance domain name"; 873 type MD-name-format; 874 reference "802.1Q Rev5"; 875 } 876 leaf md-name { 877 status current; 878 description 879 "Defines the MA-Domain name. This is a binary (octet) string 880 of 43 bytes"; 881 type binary { 882 length "1..43"; 883 } 884 reference "802.1Q Rev5"; 885 } 886 leaf md-level { 887 mandatory true; 888 status current; 889 description 890 "Defines the MD-Level"; 891 type int32 { 892 range "0..7"; 893 } 894 reference "802.1Q Rev5 or 802.1ag"; 895 } 896 } 898 grouping ma-identifier { 899 description 900 "ma-identifier defines MAID parameters as defined in 8021Q"; 901 reference "IEEE 802.1Q Rev5"; 902 leaf ma-name-format { 903 mandatory true; 904 status current; 905 description 906 "This defines the MA name format 1 is no format, 907 2 - dnslikename, 3- macaddress 4-CharString"; 908 type MA-name-format; 909 reference "IEEE 802.1Q Rev 5"; 910 } 911 leaf ma-name { 912 mandatory true; 913 description 914 "Define the MA-Name according to the specified format. 915 This is 43 byte string."; 916 type binary { 917 length "1..45"; 918 } 919 reference "802.1Q Rve 5 or 8021ag Clause 21.6.5"; 920 } 922 } 924 grouping MEP { 925 status current; 926 description 927 "Defines elements withing the MEP"; 928 reference "802.1Q Rev5"; 929 leaf mep-id { 930 mandatory true; 931 status current; 932 description 933 "Assigm MEPID in the range of 1..8191"; 934 type MEP-id { 935 range "1..8191"; 936 } 937 reference "802.1Q Rev5"; 938 } 939 leaf mep-name { 940 type string; 941 description 942 "Defines textual name for MEP. This is not specified in IEEE 943 but 944 defined in IETF OAM for ease of use"; 945 } 946 leaf mep-direction { 947 type MEP-direction; 948 mandatory true; 949 } 950 leaf ccm-Tx-enable { 951 type boolean; 952 default "false"; 953 } 954 uses mep-address; 955 uses context-id; 956 leaf Interface { 957 type if:interface-ref; 958 description 959 "Interface name as defined by ietf-interfaces"; 960 } 961 } 963 grouping CCM-defect-stats { 964 description 965 "Contains all of the CCM related defect stats"; 966 leaf ccm-rdi-indicator { 967 config false; 968 type boolean; 969 description 970 "True indicate one or more of the MEP have seen RDI 971 flag set from remote MEP"; 972 } 973 leaf ccm-xcon-count { 974 config false; 975 type oam-counter32; 976 description 977 "Number of times cross connect errors are seen"; 978 } 979 leaf ccm-xcon-Indicator { 980 config false; 981 type boolean; 982 description 983 "There is currently cross connect error seen since last 984 clearing of the variable"; 985 } 986 } 988 grouping monitor-stats { 989 leaf tx-packt-count { 990 type oam-counter32; 991 description 992 "Transmitted Packet count"; 993 } 994 leaf rx-packet-count { 995 type oam-counter32; 996 description 997 "Received packet count"; 998 } 999 leaf min-delay { 1000 units "milliseconds"; 1001 type oam-counter32; 1002 description 1003 "Delay is specified in milliseconds"; 1004 } 1005 leaf average-delay { 1006 units "milliseconds"; 1007 type oam-counter32; 1008 description 1009 "average delay in milliseconds"; 1010 } 1011 leaf max-delay { 1012 type oam-counter32; 1013 units "millisecond"; 1014 } 1015 } 1016 grouping MIP { 1017 description 1018 "defines MIP"; 1019 leaf interface { 1020 type if:interface-ref; 1021 } 1022 leaf direction { 1023 type MEP-direction; 1024 } 1025 } 1027 grouping nested-oam-layer { 1028 leaf offset { 1029 type int8 { 1030 range "1..7"; 1031 } 1032 description 1033 "defines nested OAM layer offset 1034 +1 is the layer immediatly above 1035 -1 is the layer immediatly below"; 1036 } 1037 uses maintenance-domain; 1038 uses ma-identifier; 1039 } 1041 grouping interface-status { 1042 description 1043 "collection of interface related status"; 1044 leaf admin-status { 1045 config false; 1046 type leafref { 1047 path "/if:interfaces-state/if:interface/if:admin-status"; 1048 } 1049 description 1050 "oper status from ietf-interface module"; 1051 } 1052 leaf oper-status { 1053 config false; 1054 type leafref { 1055 path "/if:interfaces-state/if:interface/if:oper-status"; 1056 } 1057 description 1058 "oper status from ietf-interface module"; 1059 } 1060 } 1061 grouping context-id { 1062 description 1063 "grouping for context id, this will be augmented 1064 by others who use this component"; 1065 choice context-id { 1066 default "context-null"; 1067 case context-null { 1068 description 1069 "this is a place holder when no context is needed"; 1070 leaf context-null { 1071 type empty; 1072 description 1073 "there is no context define"; 1074 } 1075 } 1076 } 1077 } 1079 grouping flow-entropy { 1080 description 1081 "defines the grouping statement for flow-entropy"; 1082 choice flow-entropy { 1083 case flow-entropy-null; 1084 } 1085 } 1087 container domains { 1088 status current; 1089 config true; 1090 description 1091 "Contains configuration related data. Within the container 1092 is list of fault domains. Wihin each domian has List of MA."; 1093 list domain { 1094 uses maintenance-domain { 1095 status current; 1096 } 1097 key "md-name technology"; 1098 ordered-by system; 1099 status current; 1100 config true; 1101 description 1102 "Define the list of Domains within the IETF-OAM"; 1103 container MAs { 1104 presence 1105 "Indicates creation of MA within the Domain 1106 There can be more than one MA within a specified domain"; 1107 status current; 1108 config true; 1109 description 1110 "This container defines MA, within that have multiple MA 1111 and within MA have MEP, MIP"; 1112 list MA { 1113 ordered-by system; 1114 status current; 1115 config true; 1116 key "ma-name"; 1117 uses ma-identifier; 1118 uses context-id; 1119 leaf ccm-Interval { 1120 default "interval-invalid"; 1121 description 1122 "Defines CCM Interval 0- Means disable 1123 1 - CCM are sent 3 1/3 ms 1124 2 - CCM are sent every 10 ms 1125 3- CCM are sent every 100 ms 1126 4- CCM are sent every 1 s 1127 5 - CCM are sent every 10 s 1128 6 - CCM are sent every 1 minute 1129 7- CCM are sent every 10 mins"; 1130 type CCM-Interval; 1131 reference "802.1Q Rev5 and 802.1ag"; 1132 } 1133 leaf ccm-loss-threshold { 1134 default "3"; 1135 type uint32; 1136 description 1137 "number of consecutive CCM messages missed before 1138 declaring RDI fault. This is monitored per each 1139 remote MEP"; 1140 } 1141 leaf ccm-ttl { 1142 type uint8; 1143 default "255"; 1144 } 1145 uses flow-entropy; 1146 list MEP { 1147 key "mep-id"; 1148 ordered-by system; 1149 status current; 1150 config true; 1151 description 1152 "contain list of MEPS"; 1153 uses MEP { 1154 status current; 1156 } 1157 uses interface-status { 1158 description 1159 "status of associated interface"; 1160 } 1161 uses flow-entropy; 1162 list session { 1163 key "user-cookie destination-mepid"; 1164 ordered-by user; 1165 config true; 1166 description 1167 "per session basis create the monitoring"; 1168 leaf user-cookie { 1169 config true; 1170 type uint32; 1171 description 1172 "user need to specify some cookie to identify 1173 multiple sessions between two MEPs"; 1174 } 1175 leaf ttl { 1176 config true; 1177 type uint8; 1178 default "255"; 1179 } 1180 leaf interval { 1181 units "milliseconds"; 1182 default "1000"; 1183 type uint32; 1184 description 1185 "In milli seconds. 0 means continous"; 1186 } 1187 leaf enable { 1188 default "false"; 1189 config true; 1190 type boolean; 1191 description 1192 "enable or disable a monitor session"; 1193 } 1194 leaf ecmp-choice { 1195 config true; 1196 type ecmp-choices; 1197 description 1198 "0 means use the specified interface 1199 1 means use round robin"; 1200 } 1201 leaf destination-mepid { 1202 type MEP-id; 1204 } 1205 container destination-mep-address { 1206 uses mep-address; 1207 } 1208 uses CCM-defect-stats; 1209 uses context-id; 1210 uses flow-entropy; 1211 list outgoing-interface { 1212 config true; 1213 key "interface"; 1214 leaf interface { 1215 type leafref { 1216 path "/if:interfaces/if:interface/if:name"; 1217 } 1218 config true; 1219 } 1220 } 1221 } 1222 } 1223 list remote-MEP { 1224 key "mep-id"; 1225 ordered-by system; 1226 status current; 1227 config true; 1228 description 1229 "list all of the remote MEP within the MA"; 1230 leaf mep-id { 1231 mandatory true; 1232 status current; 1233 description 1234 "Assigm MEPID in the range of 1..8191"; 1235 config true; 1236 type uint32; 1237 reference "802.1Q Rev5"; 1238 } 1239 uses mep-address; 1240 leaf mep-name { 1241 type string; 1242 description 1243 "Defines textual name for MEP. This is not 1244 specified in IEEE but defined in IETF OAM 1245 for ease of use"; 1246 } 1247 leaf ccm-rx-error-count { 1248 type oam-counter32; 1249 description 1250 "counts number of CCM packets that was 1251 expected but not received"; 1252 } 1253 } 1254 list MIP { 1255 key "interface direction"; 1256 uses MIP; 1257 } 1258 uses CCM-defect-stats { 1259 description 1260 "CCM defect stats capture at MA level 1261 This will contain aggregrate stats from all MEP"; 1262 } 1263 list nested-oam-layer { 1264 key "offset"; 1265 description 1266 "List of OAM layers above and below that are related to 1267 current MA. This allow users to easily navigate up and 1268 down 1269 to effeciently troubleshoot a connectivity issue"; 1270 uses nested-oam-layer; 1271 } 1272 } 1273 } 1274 } 1275 } 1276 notification CCM-RDI-notification { 1277 description 1278 "When RDI is received this notificiation is sent"; 1279 leaf mep-id { 1280 type MEP-id; 1281 description 1282 "Indicate which MEP is seeing the error"; 1283 } 1284 leaf remote-mepid { 1285 type MEP-id; 1286 description 1287 "Who is seeing the error (if known) if unknown make it 0."; 1288 } 1289 leaf error-message { 1290 type string { 1291 length "0..255"; 1292 } 1293 description 1294 "Error message to indicate more details."; 1295 } 1296 } 1297 rpc ping { 1298 description 1299 "Generates Ping and return response"; 1300 input { 1301 uses maintenance-domain { 1302 description 1303 "Specifies the MA-domain"; 1304 } 1305 uses ma-identifier { 1306 description 1307 "identfies the Maintenance association"; 1308 } 1309 uses context-id; 1310 uses flow-entropy; 1311 leaf ttl { 1312 type uint8; 1313 default "255"; 1314 } 1315 leaf ecmp-choice { 1316 type ecmp-choices; 1317 description 1318 "0 means use the specified interface 1319 1 means use round robin"; 1320 } 1321 leaf sub-type { 1322 type identityref { 1323 base command-sub-type; 1324 } 1325 description 1326 "defines different command types"; 1327 } 1328 list outgoing-interfaces { 1329 key "interface"; 1330 leaf interface { 1331 type if:interface-ref; 1332 } 1333 } 1334 container source-mep { 1335 uses mep-address; 1336 leaf mep-id { 1337 type MEP-id; 1338 } 1339 } 1340 container destination-mep { 1341 uses mep-address; 1342 leaf mep-id { 1343 type MEP-id; 1344 } 1346 } 1347 } 1348 output { 1349 uses monitor-stats { 1350 description 1351 "Stats of Ping is same as that of monitor sessions"; 1352 } 1353 } 1354 } 1355 rpc trace-route { 1356 description 1357 "Generates Trace-route and return response. Starts with TTL 1358 of one and increment by one at each hop. Untill destination 1359 reached or TTL reach max valune"; 1360 input { 1361 uses maintenance-domain { 1362 description 1363 "Specifies the MA-domain"; 1364 } 1365 uses ma-identifier { 1366 description 1367 "identfies the Maintenance association"; 1368 } 1369 uses context-id; 1370 uses flow-entropy; 1371 leaf ttl { 1372 type uint8; 1373 default "255"; 1374 } 1375 leaf command-sub-type { 1376 type identityref { 1377 base command-sub-type; 1378 } 1379 description 1380 "defines different command types"; 1381 } 1382 leaf ecmp-choice { 1383 type ecmp-choices; 1384 description 1385 "0 means use the specified interface 1386 1 means use round robin"; 1387 } 1388 list outgoing-interfaces { 1389 key "interface"; 1390 leaf interface { 1391 type if:interface-ref; 1392 } 1394 } 1395 container source-mep { 1396 uses mep-address; 1397 leaf mep-id { 1398 type MEP-id; 1399 } 1400 } 1401 container destination-mep { 1402 uses mep-address; 1403 leaf mep-id { 1404 type MEP-id; 1405 } 1406 } 1407 } 1408 output { 1409 list response { 1410 key "ttl"; 1411 leaf ttl { 1412 type uint8; 1413 } 1414 container destination-mep { 1415 uses mep-address; 1416 leaf mep-id { 1417 type MEP-id; 1418 } 1419 } 1420 uses monitor-stats; 1421 } 1422 } 1423 } 1424 } 1426 1428 Figure 6 YANG module of OAM 1430 7. Base Mode for IP 1432 The Base Mode defines default configuration that MUST be present in 1433 the devices that comply with this document. Base Mode allows users to 1434 have "zero-touch" experience. Several parameters require technology 1435 specific definition. 1437 7.1. MEP Address 1439 In the Base Mode of operation, the MEP Address is the IP address of 1440 the interface on which the MEP is located. 1442 7.2. MEP ID for Base Mode 1444 In the Base Mode of operation, each device creates a single UP MEP 1445 associated with a virtual OAM port with no physical layer (NULL PHY). 1446 The MEPID associated with this MEP is zero (0). The choice of MEP-ID 1447 zero is explained below. 1449 MEPID is 2 octet field. It is never used on the wire except when 1450 using CCM. Ping, traceroute and session monitoring does not use the 1451 MEPID on its message header. It is important to have method that can 1452 derive MEP ID of base mode in an automatic manner with no user 1453 intervention. IP address cannot be directly used for this purpose as 1454 the MEP ID is much smaller field. For Base Mode of IP we propose to 1455 use MEP ID zero (0) as the default MEP-ID. 1457 CCM packet use MEP-ID on the paylod. CCM MUST NOT be used in the Base 1458 Mode for IP. Hence CCM MUST be disabled on the Maintenance 1459 Association of the Base Mode. 1461 If CCM is required, users MUST configure a separate Maintenance 1462 association and assign unique value for the corresponding MEP IDs. 1464 [8021Q] CFM defines MEP ID as an unsigned integer in the range 1 to 1465 8191. In this document we propose to extend the range to 0 to 65535. 1466 Value 0 is reserved for MEP ID of Base Mode of IP and MUST NOT be 1467 used for other purposes. 1469 7.3. Maintenance Domain 1471 Default MD-LEVEL is set to 3. 1473 7.4. Maintenance Association 1475 MAID [8021Q] has a flexible format and includes two parts: 1476 Maintenance Domain Name and Short MA name. In the Based Mode of 1477 operation, the value of the Maintenance Domain Name must be the 1478 character string "GenericBaseMode" (excluding the quotes "). In Base 1479 Mode operation Short MA Name format is set to 2-octet integer format 1480 (value 3 in Short MA Format field [8021Q]) and Short MA name set to 1481 65532 (0xFFFC). 1483 8. Security Considerations 1485 TBD 1487 9. IANA Considerations 1489 This document registers the following namespace URI in the IETF XML 1490 registry. 1492 URI:TBD 1494 10. References 1496 10.1. Normative References 1498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1499 Requirement Levels", BCP 14, RFC 2119, March 1997. 1501 [RFC792] Postel, J., "Internet Control Message Protocol", STD 1502 5,RFC 792, September 1981. 1504 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 1505 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 1506 2011. 1508 10.2. Informative References 1510 [Y1731] ITU, "OAM functions and mechanisms for Ethernet based 1511 networks", ITU-T G.8013/Y.1731, July, 2011. 1513 [RFC7174] Salam, S., et.al., "TRILL OAM Framework", RFC7174, May 1514 2014. 1516 [RFC6291] Andersson, L., et.al., "Guidelines for the use of the "OAM" 1517 Acronym in the IETF" RFC 6291, June 2011. 1519 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 1520 Protocol Specification", RFC 6325, July 2011. 1522 [OAMOVW] Mizrahi, T., et.al., "An Overview of Operations, 1523 Administration, and Maintenance (OAM) Tools", draft-ietf- 1524 opsawg-oam-overview-16, Work in Progress, March 2014. 1526 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1527 Control Message Protocol (ICMPv6) for the Internet 1528 Protocol Version 6 (IPv6) Specification", RFC 4443, 1529 March 2006. 1531 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1532 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1533 February 2006. 1535 [RFC6371] Busi, I., et.al., "Operations, Administration, and 1536 Maintenance Framework for MPLS-Based Transport Networks, 1537 RFC 6317, September 2011. 1539 [TRILLOAMFM] Senevirathne, T., et.al., "TRILL OAM Fault Management", 1540 draft-ietf-trill-oam-fm, Work in Progress, May 2014. 1542 11. Acknowledgments 1544 Giles Heron came up with the idea of developing a YANG model as a way 1545 of creating a unified OAM API set (interface), work in this document 1546 is largely an inspiration of that. Alexander Clemm provided many 1547 valuable tips, comments and remarks that helped to refine the YANG 1548 model presented in this document. 1550 This document was prepared using 2-Word-v2.0.template.dot. 1552 Authors' Addresses 1554 Tissa Senevirathne 1555 CISCO Systems 1556 375 East Tasman Drive. 1557 San Jose, CA 95134 1558 USA. 1560 Phone: 408-853-2291 1561 Email: tsenevir@cisco.com 1563 Norman Finn 1564 CISCO Systems 1565 510 McCarthy Blvd 1566 Milpitas, CA 95035. 1568 Email: nfinn@cisco.com 1570 Deepak Kumar 1571 CISCO Systems 1572 510 McCarthy Blvd 1573 Milpitas, CA 95035. 1575 Email: dekumar@cisco.com 1577 Samer Salam 1578 CISCO Systems 1579 595 Burrard St. Suite 2123 1580 Vancouver, BC V7X 1J1, Canada 1582 Email: ssalam@cisco.com 1584 Carlos Pignataro 1585 Cisco Systems 1586 7200-12 Kit Creek Rd, 1587 Research Triangle Park, NC 27709 1589 Email: cpignata@cisco.com