idnits 2.17.1 draft-irtf-nmrg-autonomic-network-definitions-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2014) is 3559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force M. Behringer 3 Internet-Draft M. Pritikin 4 Intended status: Informational S. Bjarnason 5 Expires: January 29, 2015 A. Clemm 6 Cisco Systems 7 B. Carpenter 8 Univ. of Auckland 9 S. Jiang 10 Huawei Technologies Co., Ltd 11 L. Ciavaglia 12 Alcatel-Lucent 13 July 28, 2014 15 Autonomic Networking - Definitions and Design Goals 16 draft-irtf-nmrg-autonomic-network-definitions-02.txt 18 Abstract 20 Autonomic systems were first described in 2001. The fundamental goal 21 is self-management, including self-configuration, self-optimization, 22 self-healing and self-protection. 24 This document applies the concepts of autonomic systems to a network, 25 and describes the definitions and design goals of Autonomic 26 Networking. The high-level goal for an autonomic function is to have 27 minimal dependencies on human administrators or centralized 28 management systems. This usually implies distribution across network 29 elements. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 29, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction to Autonomic Networking . . . . . . . . . . . . 2 66 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Self-Management . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Co-Existence with Traditional Management . . . . . . . . 5 70 3.3. By Default Secure . . . . . . . . . . . . . . . . . . . . 6 71 3.4. Decentralisation and Distribution . . . . . . . . . . . . 7 72 3.5. Simplification of Autonomic Node Northbound Interfaces . 7 73 3.6. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.7. Autonomic Reporting . . . . . . . . . . . . . . . . . . . 7 75 3.8. Common Autonomic Networking Infrastructure . . . . . . . 8 76 3.9. Independence of Function and Layer . . . . . . . . . . . 8 77 3.10. Full Life Cycle Support . . . . . . . . . . . . . . . . . 9 78 4. Non Design Goals . . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. Eliminate human operators . . . . . . . . . . . . . . . . 9 80 4.2. Eliminate emergency fixes . . . . . . . . . . . . . . . . 9 81 4.3. Eliminate management control and central policy . . . . . 10 82 4.4. Eliminate existing configuration tools . . . . . . . . . 10 83 4.5. Eliminate existing network management systems . . . . . . 10 84 5. An Autonomic Reference Model . . . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 87 8. Informative References . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction to Autonomic Networking 92 Autonomic systems were first described in a manifesto by IBM in 2001 93 [Kephart]. The fundamental concept involves eliminating external 94 systems from a system's control loops and closing of control loops 95 within the autonomic system itself, with the goal of providing the 96 autonomic system with self-management capabilities, including self- 97 configuration, self-optimization, self-healing and self-protection. 99 IP networking was initially designed with similar properties in mind. 100 An IP network should be distributed and redundant to withstand 101 outages in any part of the network. A routing protocol such as OSPF 102 or ISIS exhibits properties of self-management, and can thus be 103 considered autonomic in the definition of this document. 105 However, as IP networking evolved, the ever increasing intelligence 106 of network elements was often not put into protocols to follow this 107 paradigm, but into configuration. This configuration made network 108 elements highly dependent on some process that manages them, either a 109 human, or a network management system. 111 Autonomic Networking aims at putting the intelligence of today's 112 operations back into algorithms at the node level, to minimize 113 dependency on human administrators and central management systems. 114 Some information an autonomic function requires however cannot be 115 discovered; where input from some central intelligence is required, 116 it is provided in a highly abstract, network wide form. 118 Autonomic Computing in general and Autonomic Networking in particular 119 have been the subject of academic study for many years. There is a 120 large literature, including several useful overview papers (e.g., 121 [Jennings], [Movahedi]). In the present document we focus on 122 concepts and definitions that seem sufficiently mature to become the 123 basis for interoperable specifications in the near future. In 124 particular, such specifications will need to co-exist with 125 traditional methods of network configuration and management, rather 126 than realising an exclusively autonomic system with all the 127 properties that would require. 129 There is an important difference between "automatic" and "autonomic". 130 "Automatic" refers to a pre-defined, linear process, such as a 131 script. "Autonomic" is used in the context of self-management. It 132 includes feedback loops between elements as well as northbound. 134 This document provides the definitions and gesign goals for Autonomic 135 Networking. 137 2. Definitions 139 Autonomic: Self-managing (self-configuring, self-protecting, self- 140 healing, self-optimizing); however, allowing high-level guidance by a 141 central entity, through intent. 143 Intent: An abstract, high level policy used to operate the network 144 autonomically. Its scope is an autonomic domain, such as an 145 enterprise network. It does not contain configuration or information 146 for a specific node (see Section 3.2 on how intent co-exists with 147 alternative management paradigms). It may contain information 148 pertaining to nodes with a specific role. 150 Autonomic Domain: A collection of autonomic nodes that instantiate 151 the same intent. 153 Autonomic Function: A feature or function which requires no 154 configuration, and can derive all required information either through 155 self-knowledge, discovery or through intent. 157 Autonomic Service Agent: An agent implemented on an autonomic node 158 which implements an autonomic function, either in part (in the case 159 of a distributed function) or whole. 161 Autonomic Node: A node which employs autonomic functions. It may 162 operate on any layer of the networking stack. Examples are routers, 163 switches, personal computers, call managers, etc. 165 Fully Autonomic Node: A node which employs exclusively autonomic 166 functions. It requires (!) no configuration. Note that 167 configuration can be used to override an autonomic function. See 168 Section 3.2 for more details. 170 Autonomic Network: A network containing autonomic nodes. 172 Fully Autonomic Network: A network consisting of exclusively fully 173 autonomic nodes. 175 3. Design Goals 177 This section explains the high level goals of Autonomic Networking, 178 independent of any specific solutions. 180 3.1. Self-Management 182 The original design goals of autonomic systems as described in 183 [Kephart] also apply to Autonomic Networks. The over-arching goal is 184 self-management, which is comprised of several self-* properties. 185 The most commonly cited are: 187 o Self-configuration: Functions do not require to be configured, but 188 they configure themselves, based on self-knowledge, discovery, and 189 intent. Discovery is the default way for an autonomic function to 190 receive the information it needs to operate. 192 o Self-healing: Autonomic functions adapt on their own to changes in 193 the environment, and heal problems automatically. 195 o Self-optimising: Autonomic functions automatically determine ways 196 to optimise their behaviour. 198 o Self-protection: Autonomic functions automatically secure 199 themselves against potential attacks. 201 Almost any network can be described as "self-managing", as long as 202 the definition of "self" is large enough. For example, a well- 203 defined SDN system, including the controller elements, can be 204 described over all as "autonomic", if the controller provides an 205 interface to the administrator which has the same properties as 206 mentioned above (high level, network-wide, etc). 208 For the work in the IETF and IRTF we define the "self" properties on 209 the node level. It is the design goal to make functions on network 210 nodes self- managing, in other words, minimally dependent on 211 management systems or controllers, as well as human operators. Self- 212 managing functions on a node might need to exchange information with 213 other nodes in order to achieve the required goals. 215 3.2. Co-Existence with Traditional Management 217 For the forseeable future, fully autonomic nodes and network will be 218 the exception; autonomic behaviour will initially be defined function 219 by function. Therefore, co-existence with other network management 220 paradigms has to be considered. Examples are management by command 221 line, SNMP, SDN (with related APIs), netconf, etc. 223 Conflict resolution between autonomic default behaviour and intent on 224 one side, and other methods on the other is therefore required. 225 Generally, autonomic mechanisms define a network wide behaviour, 226 whereas the alternative methods are typically on a node by node 227 basis. Node based management concepts take a higher priority over 228 autonomic methods. This is in line with current examples of 229 autonomic functions, for example routing: A (statically configured) 230 route has priority over the routing algorithm. In short: 232 o lowest priority: autonomic default behaviour 234 o medium priority: autonomic intent 236 o highest priority: node specific network management concepts, such 237 as command line, SNMP, SDN, netconf, etc. (How these concepts are 238 prioritised between themselves is outside scope of this document. 240 The above priorisation essentially results in unlimited power of the 241 human administrator, who can always over-rule autonomic behaviour. 242 This is generally the expectation of network operators today, and 243 remains therefore a design principle here. In critical systems, such 244 as atomic power plants, sometimes the opposite philosophy is used: 245 The expectation is that a well defined algorithm is more trustworthy 246 than a human operator, especially in rare exception cases. 247 Networking generally does not follow this philosophy yet. Warnings 248 however should be issued if node specific overrides may conflict with 249 autonomic behaviour. 251 In other fields, autonomic mechanisms disengage automatically if 252 certain conditions occur: The auto-pilot in a plane switches off if 253 the plane is outside a pre-defined envelope of flight parameters. 254 The assumption is that the algorithms only work correctly if the 255 input values are in expected ranges. Some opinions however suggest 256 that exactly in exceptional conditions is the worst moment to switch 257 of autonomic behaviour, since the pilots have no full understanding 258 of the situation at this point, and may be under high levels of 259 stress. For this reason we suggest here to NOT generally disable 260 autonomic functions if they encounter unexpected conditions, because 261 it is expected that this adds another level of unpredictability in 262 networks, when the situation may already be hard to understand. 264 3.3. By Default Secure 266 All autonomic interactions should be by default secure. This 267 requires that any member of an autonomic domain can assert its 268 membership using a domain identity, for example a certificate issued 269 by a domain certification authority. This domain identity is used 270 for nodes to learn about their neighbouring nodes, to determine the 271 boundaries of the domain, and to cryptographically secure 272 interactions within the domain. Nodes from different domains can 273 also mutually verify their identity and secure interactions as long 274 as they have a common trust anchor. 276 A strong, cryptographically verifiable domain identity is a 277 fundamental cornerstone in autonomic networking. It can be leveraged 278 to secure all communications, and allows thus automatic security 279 without traditional configuration, for example pre-shared keys. 281 Autonomic functions must be able to adapt their behaviour depending 282 on the domain of the node they are interacting with. 284 3.4. Decentralisation and Distribution 286 The goal of Autonomic Networking is to minimise dependencies on 287 central elements; therefore, de-centralisation and distribution are 288 fundamental to the concept. If a problem can be solved in a 289 distributed manner, it should not be centralised. 291 In certain cases it is today operationally preferable to keep a 292 central repository of information, for example a user database on a 293 AAA server. An autonomic network must also be able to use such 294 central systems, in order to be deployable. However, it is possible 295 to distribute such databases as well, and such efforts should be at 296 least considered. 298 3.5. Simplification of Autonomic Node Northbound Interfaces 300 Even in a decentralised solution, certain information flows with 301 central entities are required. Examples are the definition of intent 302 or high level service definitions, as well as network status requests 303 and aggregated reporting. 305 Therefore, also nodes in an autonomic network require a northbound 306 interface. However, the design goal is to maintain this interface as 307 simple and high level as possible. 309 3.6. Abstraction 311 An administrator or autonomic management system interacts with an 312 autonomic network on a high level of abstraction. Intent is defined 313 at a level of abstraction that is much higher than that of typical 314 configuration parameters, for example, "optimize my network for 315 energy efficiency". Intent must not be used to convey low-level 316 commands or concepts, since those are on a different abstraction 317 level. The administrator should not even be exposed to the version 318 of the IP protocol running in the network. 320 Also on the reporting and feedback side an autonomic network 321 abstracts information and provides high-level messages such as "the 322 link between node X and Y is down". 324 3.7. Autonomic Reporting 326 An autonomic network, while minimizing the need for user 327 intervention, still needs to provide users with visibility like in 328 traditional networks. However, in an autonomic network reporting 329 should happen on a network wide basis. Information about the network 330 should be collected and aggregated by the network itself, presented 331 in consolidated fashion to the administrator. 333 The layers of abstraction that are provided via intent need to be 334 supported for reporting functions as well, in order to give users an 335 indication about the effectiveness of their intent. For example, in 336 order to assess how effective the network performs with regards to 337 the intent "optimize my network for energy efficiency", the network 338 should provide aggregate information about the number of ports that 339 were able to be shut down while validating current service levels are 340 on aggregate still met. 342 Autonomic network events should concern the autonomic network as a 343 whole, not individual systems in isolation. For example, the same 344 failure symptom should not be reported from every system that 345 observes it, but only once for the autonomic network as a whole. 346 Ultimately, the autonomic network should support exception based 347 management, in which only events that truly require user attention 348 are actually notified. This requires capabilities that allow systems 349 within the network to compare information and apply special 350 algorithms to determine what should be reported. 352 3.8. Common Autonomic Networking Infrastructure 354 [I-D.irtf-nmrg-an-gap-analysis] points out that there are already a 355 number of fully or partially autonomic functions available today. 356 However, they are largely independent, and each has its own methods 357 and protocols to communicate, discover, define and distribute policy, 358 etc. 360 The goal of the work on autonomic networking in the IETF is therefore 361 not just to create autonomic functions, but to define a common 362 infrastructure that autonomic functions can use. This autonomic 363 networking infrastructure may contain common control and management 364 functions such as messaging, service discovery, negotiation, intent 365 distribution, self-monitoring and diagnostics, etc. A common 366 approach to define and manage intent is also required. 368 Refer to the reference model below: All the components around the 369 "autonomic service agents" should be common components, such that the 370 autonomic service agents do not have to replicate common tasks 371 individually. 373 3.9. Independence of Function and Layer 375 Today's autonomic functions may reside on any layer in the networking 376 stack. For example, layer 2 switching today is already relatively 377 autonomic in many environments; routing functions can be autonomic. 378 "Autonomic" in the context of this framework is a property of a 379 function on a node. This node can be a switch, router, server, or 380 call manager. Autonomic functionality is independent of the function 381 of a node. Even application layer functionality such as unified 382 communications can be autonomic. 384 An Autonomic Network requires an overall control plane for autonomic 385 nodes to communicate. As in general IP networking, IP is the layer 386 that binds all those elements together; autonomic functions in the 387 context of this framework should therefore operate at the IP layer. 388 This concerns neighbour discovery protocols and other autonomic 389 control plane functions. 391 3.10. Full Life Cycle Support 393 An autonomic function does not depend on external input to operate; 394 it needs to understand its current situation and surrounding, and 395 operate according to its current state. Therefore, an autonomic 396 function must understand the full life cycle of the device it runs 397 on, from first manufacturing testing through deployment, testing, 398 troubleshooting, up to decommissioning. 400 The state of the life-cycle of an autonomic node is reflected in a 401 state model. The behaviour of an autonomic function may be different 402 for different deployment states. 404 4. Non Design Goals 406 This section identifies various items which are explicitly not design 407 goals for autonomic networks, which are mentioned to avoid 408 misunderstandings of the general intention. 410 4.1. Eliminate human operators 412 The problem targeted by autonomic networking is the error-prone and 413 hard to scale model of individual configuration of network elements, 414 traditionally by manual commands but today mainly by scripting and/or 415 configuration management databases. This does not, however, imply 416 the elimination of skilled human operators, who will still be needed 417 for oversight, policy management, diagnosis, reaction to help desk 418 tickets, etc. etc. The main impact on operators should be less 419 tedious detailed work and more high-level work. (They should become 420 more like doctors than hospital orderlies.) 422 4.2. Eliminate emergency fixes 424 However good the autonomous mechanisms, sometimes there will be fault 425 conditions etc. that they cannot deal with correctly. At this point 426 skilled operator interventions will be needed to correct or work 427 around the problem. Hopefully this can be done by high-level 428 mechanisms (adapting the policy database in some way) but in some 429 cases direct intervention at device level may be unavoidable. This 430 is obviously the case for hardware failures, even if the autonomic 431 network has bypassed the fault for the time being. Truck rolls will 432 not be eliminated when faulty equipment needs to be replaced. 433 However, this may be less urgent if the autonomic system 434 automatically reconfigures to minimise the operational impact. 436 4.3. Eliminate management control and central policy 438 Senior management might fear loss of control of an autonomic network. 439 In fact this is no more likely than with a traditional network; the 440 emphasis on automatically applying general policy and security rules 441 might even provide more management control. 443 4.4. Eliminate existing configuration tools 445 While autonomic networks will rarely need manual intervention, there 446 is no expectation that traditional top-down configuration tools will 447 vanish immediately. Autonomic techniques will have to co-exist with 448 them, and they will survive for as long as they are useful. 449 Initially they will certainly play a part in confidence-building in 450 the autonomic method, and they will be held in reserve for emergency 451 use for a long time. 453 4.5. Eliminate existing network management systems 455 Existing monitoring and reporting systems will continue to be needed, 456 and as just noted existing configuration mechanisms will not vanish. 457 Therefore, it is to be expected that the existing NMS will be 458 retained in parallel with autonomic mechanisms, and will be adapted 459 as necessary. Some aspects of the autonomic mechanism (e.g. 460 aggregated reporting, exception reporting) should indeed be 461 integrated with the existing NMS as far as possible. 463 5. An Autonomic Reference Model 465 An Autonomic Network consists of Autonomic Nodes. Those nodes 466 communicate with each other through an Autonomic Control Plane which 467 provides a robust and secure communications overlay. The Autonomic 468 Control Plane is self-organizing and autonomic itself. 470 An Autonomic Node contains various elements, such as autonomic 471 service agents which immplement autonomic functions. Figure 1 shows 472 a reference model of an autonomic node. The elements and their 473 interaction are: 475 o Autonomic Service Agents, which implement the autonomic behaviour 476 of a specific service or function. 478 o Self-knowledge: An autonomic node knows its own properties and 479 capabilities 481 o Network Knowledge (Discovery): An autonomic service agent may 482 require various discovery functions in the network, such as 483 service discovery. 485 o Intent: Network wide high level policy. Autonomic Service Agents 486 use an intent interpretation engine to locally instantiate the 487 global intent. This may involve coordination with other Autonomic 488 Nodes. 490 o Feedback Loops: Control elements outside the node may interact 491 with autonomic nodes through feedback loops. 493 o An Autonomic User Agent, providing a front-end to external users 494 (administrators and management applications) through which they 495 can communicate intent, receive reports, and monitor the Autonomic 496 Network. 498 o Autonomic Control Plane: Allows the node to communicate with other 499 autonomic nodes. Autonomic functions such as intent distribution, 500 feedback loops, discovery mechanisms, etc, use the autonomic 501 control plane. The autonomic control plane can run in the global 502 context of each device, or be implemented as a separated overlay 503 network, as described in [I-D.behringer-autonomic-control-plane]. 505 +------------------------------------------------------------+ 506 | +----------+ +--------------+ | 507 | | | | Feedback | | 508 | | Intent | | Loops | | 509 | +----------+ +--------------+ | 510 | ^ ^ | 511 | Autonomic User Agent | 512 | V V | 513 | +-----------+ +------------+ +------------+ | 514 | | Self- | | Autonomic | | Network | | 515 | | knowledge |<------>| Service |<------>| Knowledge | | 516 | | | | Agents | | (Discovery)| | 517 | +-----------+ +------------+ +------------+ | 518 | ^ ^ | 519 | | | | 520 | V V | 521 |------------------------------------------------------------| 522 | Autonomic Control Plane | 523 |------------------------------------------------------------| 524 | Standard Operating System Functions | 525 +------------------------------------------------------------+ 527 Figure 1 529 6. Security Considerations 531 This document provides definitions and design goals for autonomic 532 networking. A full threat analysis will be required as part of the 533 development of solutions, taking account of potential attacks from 534 within the network as well as from outside. 536 7. Acknowledgements 538 The work on Autonomic Networking is the result of a large team 539 project at Cisco Systems. In alphabetical order: Ignas Bagdonas, 540 Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno 541 Klauser. 543 The ETSI working group AFI (http://portal.etsi.org/afi) defines a 544 similar framework for autonomic networking in the "General Autonomic 545 Network Architecture" [GANA]. Many concepts explained in this 546 document can be mapped to the GANA framework. The mapping is outside 547 the scope of this document. Special thanks to Ranganai Chaparadza 548 for his comments and help on this document. 550 8. Informative References 552 [GANA] ETSI GS AFI 002, , "Autonomic network engineering for the 553 self-managing Future Internet (AFI): GANA Architectural 554 Reference Model for Autonomic Networking, Cognitive 555 Networking and Self-Management.", April 2013, 556 . 559 [I-D.behringer-autonomic-control-plane] 560 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 561 Autonomic Control Plane", draft-behringer-autonomic- 562 control-plane-00 (work in progress), June 2014. 564 [I-D.irtf-nmrg-an-gap-analysis] 565 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 566 for Autonomic Networking", draft-irtf-nmrg-an-gap- 567 analysis-00 (work in progress), April 2014. 569 [Jennings] 570 Jennings et al, B., "Challenges for federated, autonomic 571 network management in the Future Internet", Integrated 572 Network Management-Workshops, 2009. IM '09 DOI: 10.1109/ 573 INMW.2009.5195942 Page(s): 87 - 92, 2009. 575 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 576 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 577 January 2003, . 580 [Movahedi] 581 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 582 Survey of Autonomic Network Architectures and Evaluation 583 Criteria", IEEE Communications Surveys & Tutorials Volume: 584 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 585 Page(s): 464 - 490, 2012. 587 Authors' Addresses 589 Michael Behringer 590 Cisco Systems 591 Building D, 45 Allee des Ormes 592 Mougins 06250 593 France 595 Email: mbehring@cisco.com 596 Max Pritikin 597 Cisco Systems 598 5330 Airport Blvd 599 Boulder, CO 80301 600 USA 602 Email: pritikin@cisco.com 604 Steinthor Bjarnason 605 Cisco Systems 606 Mail Stop LYS01/5 607 Philip Pedersens vei 1 608 LYSAKER, AKERSHUS 1366 609 Norway 611 Email: sbjarnas@cisco.com 613 Alexander Clemm 614 Cisco Systems 615 170 West Tasman Drive 616 San Jose , California 95134-1706 617 USA 619 Email: alex@cisco.com 621 Brian Carpenter 622 Department of Computer Science 623 University of Auckland 624 PB 92019 625 Auckland 1142 626 New Zealand 628 Email: brian.e.carpenter@gmail.com 630 Sheng Jiang 631 Huawei Technologies Co., Ltd 632 Q14, Huawei Campus 633 No.156 Beiqing Road 634 Hai-Dian District, Beijing 100095 635 P.R. China 637 Email: jiangsheng@huawei.com 638 Laurent Ciavaglia 639 Alcatel-Lucent 641 Email: Laurent.Ciavaglia@alcatel-lucent.com