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