idnits 2.17.1 draft-jiang-config-negotiation-ps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2014) is 3629 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-boucadair-network-automation-requirements-03 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-00 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-00 == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Jiang 3 Internet-Draft Y. Yin 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: November 20, 2014 B. Carpenter 6 Univ. of Auckland 7 May 19, 2014 9 Network Configuration Negotiation Problem Statement and Requirements 10 draft-jiang-config-negotiation-ps-03 12 Abstract 14 This document describes a problem statement and general requirements 15 for distributed autonomic configuration of multiple aspects of 16 networks, in particular carrier networks. The basic model is that 17 network elements need to negotiate configuration settings with each 18 other to meet overall goals. The document describes a generic 19 negotiation behavior model. The document also reviews whether 20 existing management and configuration protocols may be suitable for 21 autonomic networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 20, 2014. 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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements and Application Scenarios for Network Devices 59 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Negotiation between downstream and upstream network 61 devices . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Negotiation between peer network devices . . . . . . . . 5 63 2.3. Negotiation between networks . . . . . . . . . . . . . . 5 64 2.4. Information and status queries among devices . . . . . . 6 65 2.5. Unavoidable configuration . . . . . . . . . . . . . . . . 6 66 3. Existing protocols . . . . . . . . . . . . . . . . . . . . . 6 67 4. A Behavior Model of a Generic Negotiation Protocol . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 71 8. Change Log [RFC Editor please remove] . . . . . . . . . . . . 13 72 9. Informative References . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 The success of IP and the Internet has made the network model very 78 complicated, and networks have become larger and larger. The network 79 of a large ISP typically contains more than a hundred thousand 80 network devices which play many roles. The initial setup 81 configuration, dynamic management and maintenance, troubleshooting 82 and recovery of these devices have become a huge outlay for network 83 operators. Particularly, these devices are managed by many different 84 staff requiring very detailed training and skills. The coordination 85 of these staff is also difficult and often inefficient. There are 86 therefore increased requirements for autonomy in the networks. 87 [I-D.boucadair-network-automation-requirements] is one of the 88 attempts to describe such requirements. It listed a "requirement for 89 a protocol to convey configuration information towards the managed 90 entities". However, this document is going further by requiring a 91 configuration negotiation protocol rather than only unidirectional 92 provisioning. 94 Autonomic operation means network devices could decide configurations 95 by themselves. More background on autonomic networking is given in 96 [I-D.irtf-nmrg-autonomic-network-definitions] and 98 [I-D.irtf-nmrg-an-gap-analysis]. There are already many existing 99 internal implementations or algorithms for a network device to decide 100 or compute its configuration according to its own status, often 101 referred to as device intelligence. In one particular area, routing 102 protocols, distributed autonomic configuration is a well established 103 mechanism. The question is how to extend autonomy to cover all kinds 104 of configuration, not just routing tables. 106 However, in order to make right or good decisions, the network 107 devices need to know more information than just routes from the 108 relevant or neighbor devices. There are dependencies between such 109 information and configurations. Currently, most of these 110 configurations currently require centralised manual coordination. 111 The basic model for this document is that in an autonomic network, 112 devices will need to negotiate directly with one another to provide 113 this coordination. 115 Today, there is no generic negotiation protocol that can be used to 116 control decision processes among distributed devices or between 117 networks. Proprietary network management systems are widely used but 118 tend to be hierarchical systems ultimately relying on a console 119 operator and a central database. An autonomic system needs to be 120 less hierarchical and with less dependence on an operator. This 121 requires network elements to negotiate directly with each other, with 122 an absolute minimum or zero configuration data at the installation 123 stage. 125 This document analyzes the requirements for a generic negotiation 126 protocol in view of various application use cases, then gives 127 considerations for detailed technical requirements for designing such 128 a protocol. Some existing protocols are also reviewed as part of the 129 analysis. A protocol behavior model, which may be used to define 130 such a negotiation protocol, is also described. 132 Note in draft: the requirements analysis will need to be reviewed and 133 completed after a number of use cases for autonomic networking have 134 been documented. 136 2. Requirements and Application Scenarios for Network Devices 137 Negotiation 139 Routing protocols are a typical autonomic model based on distributed 140 devices. But routing is mainly one-way information announcement (in 141 both directions), rather than bi-directional negotiation. Its only 142 focus is reachability. The future networks need to be able to manage 143 many more dimensions of the network, such as power saving, load 144 balancing, etc. The current routing protocols only show simple link 145 status, as up or down. More information, such as latency, 146 congestion, capacity, and particularly available throughput, is very 147 helpful to get better path selection and utilization rate. 149 A negotiation model with no human intervention is needed when the 150 coordination of multiple devices can provide better overall network 151 performance. 153 A negotiation model provides a possibility for forecasting. A "dry 154 run" becomes possible before the concrete configuration takes place. 156 Another area is tunnel management, with automatic setup, maintenance, 157 and removal. A related area is ad hoc routes, without encapsulation, 158 to handle specific traffic flows (which might be regarded as a form 159 of software defined networking). 161 Negotiation of security mechanisms, for example to determine the 162 strongest possible protection for a given link, is another example. 164 When a new user or device comes online, it might be necessary to set 165 up resources on multiple relevant devices, coordinated and matched to 166 each other so that there is no wasted resource. Security settings 167 might also be needed to allow for the new user/device. 169 Status information and traffic metrics need to be shared between 170 nodes for dynamic adjustment of resources. 172 Troubleshooting should be as automatic as possible. Although it is 173 far from trivial, there is a need to detect the "real" breakdown 174 amongst many alerts, and then take action to reconfigure the relevant 175 devices. Again, routing protocols have done this for many years, but 176 in an autonomic network it is not just routing that needs to 177 reconfigure itself after a failure. 179 2.1. Negotiation between downstream and upstream network devices 181 The typical scenario is that there is a new access gateway, which 182 could be a wireless base station, WiFi hot spot, Data Center switch, 183 VPN site switch, enterprise CE, home gateway, etc. When it is 184 plugged into the network, bi-direction configuration/control is 185 needed. The upstream network needs to configure the device, its 186 delegated prefix(es), DNS server, etc. For this direction, DHCP 187 might be suitable and sufficient. However, there is another 188 direction: the connection of downstream devices also needs to trigger 189 the upstream devices, for example the provider edge, to create a 190 corresponding configuration, by setting up a new tunnel, service, 191 authentication, etc. 193 Furthermore, after the communication between gateway and provider has 194 been established, the devices would like to optimize their 195 configurations interactively according to dynamic link status or 196 performance measurements, power consumption, etc. For dynamic 197 management and maintenance, there are many other network events that 198 downstream network devices may need to report to upstream network 199 devices and then initiate some configuration change on these upstream 200 devices. Currently, these kinds of synchronizing operations require 201 the involvement of human operators. 203 Similar requirements can also appear between other types of 204 downstream and upstream network devices. 206 2.2. Negotiation between peer network devices 208 Within a large network, in many segments, there are network devices 209 that are in equivalent positions. They have a peer rather than 210 hierarchical relationship. There may be many horizontal traffic 211 flows or tunnels between them. In order to make these connections 212 efficient, their configurations (for example, quality of service 213 parameters) have to match each other. Any change of a device's 214 configuration may require synchronizing with its peer network 215 devices. 217 However, in many cases the peer network devices may not be able to 218 make the exact changes as requested. Instead, another slightly 219 different change may be the best choice for optimal performance. In 220 order to decide on this best choice, multiple rounds of information 221 exchange between peers may be necessary. This should be done without 222 requiring the involvement of human operators. To provide this 223 ability, a mechanism for network devices to be able to negotiate with 224 each other is needed. 226 2.3. Negotiation between networks 228 A network may announce some information about its internal 229 capabilities to connected peer networks, so that the peer networks 230 can react accordingly. BGP routing information is a simple example. 232 Beyond reachability, more information may enable better coordination 233 among networks. Examples include traffic engineering among multiple 234 connections between two networks, particularly when these connections 235 are geographically distributed; dynamic capacity adjustment to match 236 changing traffic from a peer network; dynamic establishment and 237 adjustment of differentiated service classes to support Service Level 238 Agreements; and so on. 240 2.4. Information and status queries among devices 242 In distributed routers, many data such as status indicators or 243 traffic measurements are dynamically changing. These may be the 244 triggers for subsequent negotiation. For example, assume there are 245 two routers A and B sharing traffic load. Router A may request the 246 traffic situation of router B, then start negotiation, such as 247 requesting router B to handle all the traffic so that router A can 248 enter power-saving mode. Another example is that a device may 249 request its neighbor to send a forecast or dry-run result based on a 250 given potential configuration change. Then, the initiating router 251 can evaluate whether the potential configuration change would meet 252 its original target. 254 2.5. Unavoidable configuration 256 Even with autonomic negotiation, some initial configuration data 257 cannot be avoided in some devices. A design goal is to reduce this 258 to an absolute minimum. This information may have to be pre- 259 configured on the device before it has been deployed physically, and 260 is typically static. A preliminary list of unavoidable configuration 261 data is: 263 o Authentic identity for each device. This may be a public key or a 264 signed certification. This is necessary to protect the 265 infrastructure against unauthorized replacement of equipment. 267 o The role and function and capability of the device. The role and 268 function may depend on the network planning. The capability is 269 typically decided by the hardware. 271 o On the network edge, the routers may need to be configured with 272 the identity of each peer provider, and their entitlements to 273 service. 275 Ideally, everything else (topology, link capacity, address prefixes, 276 shared resources, customer authentication and authority, etc.) will 277 be discovered or negotiated autonomously according to general policy 278 for various negotiated objective. 280 3. Existing protocols 282 Routing protocols are mainly one-way information announcements. The 283 receiver makes independent decisions based on the received 284 information and there is no direct feedback information to the 285 announcing peer. This remains true even though the protocol is used 286 in both directions between peer routers; there is no negotiation, and 287 each peer runs its route calculations independently. 289 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ 290 response model not well suited for peer negotiation. Network 291 Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that 292 does allow positive or negative responses from the target system, but 293 this is still not adequate for negotiation. 295 There are various existing protocols that have elementary negotiation 296 abilities, such as Dynamic Host Configure Protocol for IPv6 (DHCPv6) 297 [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control Protocol 298 (PCP) [RFC6887], Remote Authentication Dial In User Service (RADIUS) 299 [RFC2865], Diameter [RFC6733], etc. Most of them are configuration 300 or management protocols. However, they either provide only a simple 301 request/response model in a master/slave context or very limited 302 negotiation abilities. 304 There are also signalling protocols with an element of negotiation. 305 For example Resource ReSerVation Protocol (RSVP) [RFC2205] was 306 designed for negotiating quality of service parameters along the path 307 of a unicast or multicast flow. RSVP is a very specialised protocol 308 aimed at end-to-end flows. However, it has some flexibility, having 309 been extended for MPLS label distribution [RFC3209]. A more generic 310 design is General Internet Signalling Transport (GIST) [RFC5971], but 311 it is complex, tries to solve many problems, and is also aimed at 312 per-flow signalling across many hops rather than at device-to-device 313 signalling. However, we cannot yet exclude extended RSVP or GIST as 314 a negotiation protocol. 316 It is worth noting that some of the above protocols have either an 317 explicit information model describing their messages, or at least a 318 flexible and extensible message format. A negotiation protocol will 319 require such capabilities. One design consideration is whether to 320 adopt an existing information model or to design a new one. Another 321 consideration is whether to be able to carry some or all of the 322 message formats used by the above protocols. 324 We now consider two protocols that are works in progress at the time 325 of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a 326 protocol intended to convey NETCONF information expressed in the YANG 327 language via HTTP, including the ability to transit HTML 328 intermediaries. While this is a powerful approach in the context of 329 centralised configuration of a complex network, it is not well 330 adapted to efficient interactive negotiation between peer devices, 331 especially simple ones that are unlikely to include YANG processing 332 already. 334 Secondly, we consider HomeNet Control Protocol (HNCP) 335 [I-D.ietf-homenet-hncp]. This is defined as "a minimalist state 336 synchronization protocol for Homenet routers." Specific features 337 are: 339 o Every participating node has a unique node identifier. 341 o "HNCP is designed to operate between directly connected neighbors 342 on a shared link using link-local IPv6 addresses." 344 o Currency of state is maintained by spontaneous link-local 345 multicast messages. 347 o HNCP discovers and tracks link-local neighbours. 349 o HNCP messages are encoded as a sequence of TLV objects, sent over 350 UDP. 352 o Authentication depends on a signature TLV (assuming public keys 353 are associated with node identifiers). 355 o The functionality covered initially includes: site border 356 discovery, prefix assignment, DNS namespace discovery, and routing 357 protocol selection. 359 Clearly HNCP does not completely meet the needs of a general 360 negotiation protocol, especially due to its limitation to link-local 361 messages and its strict dependency on IPv6, but at the minimum it is 362 a very interesting test case for this style of interaction between 363 devices without needing a central authority. 365 4. A Behavior Model of a Generic Negotiation Protocol 367 This section describes a behavior model and some considerations for 368 designing a generic negotiation protocol, which would act as a 369 platform for different negotiation objectives. 371 o A generic platform 373 The design of the network device protocol is desired to be a 374 generic platform, which is independent from the negotiation 375 contents. It should only take care of the general 376 intercommunication between negotiation counterparts. The 377 negotiation contents will vary according to the various 378 negotiation objectives and the different pairs of negotiating 379 counterparts. 381 o Security infrastructure and trust relationship 382 Because this negotiation protocol may directly cause changes to 383 device configurations and bring significant impacts to a running 384 network, this protocol must be based on a restrictive security 385 infrastructure. It should be carefully managed and monitored so 386 that every device in this negotiation system behaves well and 387 remains well protected. 389 On the other hand, a limited negotiation model might be deployed 390 based on a limited trust relationship. For example, between two 391 administrative domains, devices might also exchange limited 392 information and negotiate some particular configurations based on 393 a limited conventional or contractual trust relationship. 395 o A uniform pattern for negotiation contents 397 The negotiation contents should be defined according to a uniform 398 pattern. They could be carried either in TLV (Type, Length and 399 Value) format or in payloads described by a flexible language, 400 like XML. A protocol design should choose one of these two. The 401 format must be extensible for unknown future requirements. As 402 noted above, an existing information model and existing message 403 format(s) should be considered. 405 o A simple initiator/responder model 407 Multi-party negotiations are too complicated to be modeled and 408 there may be too many dependencies among the parties to converge 409 efficiently. A simple initiator/responder model is more feasible 410 and could actually complete multiple-party negotiations by 411 indirect steps. Naturally this process must be guaranteed to 412 terminate and must contain tie-breaking rules. 414 o Organizing of negotiation content 416 Naturally, the negotiation content should be organized according 417 to the relevant function or service. The content from different 418 functions or services should be kept independent from each other. 419 They should not be combined into a single option or single session 420 because these contents may be negotiated with different 421 counterparts or may be different in response time. 423 o Topology neighbor device discovery 424 Every network device that supports the negotiation protocol is a 425 responder and always listens to a well-known (UDP?) port. A well- 426 known link-local multicast address should be defined for discovery 427 purposes. Upon receiving a discovery or request message, the 428 recipient device should return a message in which it either 429 indicates itself as a proper negotiation counterpart or diverts 430 the initiator towards another more suitable device. 432 o Self aware network device 434 Every network device should be pre-configured with its role and 435 functions and be aware of its own capabilities. The roles may be 436 only distinguished because of network behaviors, which may include 437 forwarding behaviors, aggregation properties, topology location, 438 bandwidth, tunnel or translation properties, etc. The role and 439 functions may depend on the network planning. The capability is 440 typically decided by the hardware or firmware. These parameters 441 are the foundation of the negotiation behavior of a specific 442 device. 444 o Requests and responses in negotiation procedures 446 The initiator should be able to negotiate with its relevant 447 negotiation counterpart devices, which may be different according 448 to the negotiation objective. It may request relevant information 449 from the negotiation counterpart so that it can decide its local 450 configuration to give the most coordinated performance. It may 451 request the negotiation counterpart to make a matching 452 configuration in order to set up a successful communication with 453 it. It may request certain simulation or forecast results by 454 sending some dry run conditions. 456 Beyond the traditional yes/no answer, the responder should be able 457 to reply with a suggested alternative if its answer is 'no'. This 458 would start a bi-directional negotiation ending in a compromise 459 between the two devices. 461 o Convergence of negotiation procedures 463 The negotiation procedure should move towards convergent results. 464 It means that when a responder makes a suggestion of a changed 465 condition in a negative reply, it should be as close as possible 466 to the original request or previous suggestion. The suggested 467 value of the third or later negotiation steps should be chosen 468 between the suggested values from the last two negotiation steps. 470 In any case there must be a mechanism to guarantee rapid 471 convergence in a small number of steps. 473 o Dependencies of negotiation 475 In order to decide a configuration on a device, the device may 476 need information from neighbors. This can be reached through the 477 above negotiation procedure. However, a given item in a neighbor 478 may depend on other information from its own neighbors, which may 479 need another negotiation procedure to obtain or decide. 480 Therefore, there are dependencies among negotiation procedures. 481 There need to be clear boundaries and convergence mechanisms for 482 these negotiation dependencies. Also some mechanisms are needed 483 to avoid loop dependencies. 485 o End of negotiation 487 A single negotiation procedure also needs ending conditions if it 488 does not converge. A limited number of rounds, for example three, 489 should be set on the devices. It may be an implementation choice 490 or a pre-configurable parameter. However, the protocol design 491 needs to clearly specify this, so that the negotiation can be 492 terminated properly. In some cases, a timeout might be needed to 493 end a negotiation. 495 o Failed negotiation 497 There must be a well-defined procedure for concluding that a 498 negotiation cannot succeed, and if so deciding what happens next 499 (deadlock resolution, tie-breaking, or revert to best-effort 500 service). 502 o Policy constraints 504 There must be provision for general policy rules to be applied by 505 all devices in the network (e.g., security rules, prefix length, 506 resource sharing rules). However, policy distribution might not 507 use the negotiation protocol itself. 509 o Management monitoring, alerts and intervention 511 Devices should be able to report to a monitoring system. Some 512 events must be able to generate operator alerts and some provision 513 for emergency intervention must be possible (e.g. to freeze 514 negotiation in a mis-behaving device). These features may not use 515 the negotiation protocol itself. 517 5. Security Considerations 519 This document does not include a detailed threat analysis for 520 autonomic configuration, but it is obvious that a successful attack 521 on autonomic nodes would be extremely harmful, as such nodes might 522 end up with a completely undesirable configuration. A concrete 523 protocol proposal will therefore require a threat analysis, and some 524 form of strong authentication and, if possible, built-in protection 525 against denial of service attacks. 527 Separation of network devices and user devices may become very 528 helpful in this kind of scenario. 530 Also, security configuration itself should become autonomic whenever 531 possible. However, in the security area at least, operator override 532 of autonomic configuration must be possible for emergency use. 534 As noted earlier, a cryptographically authenticated identity for each 535 device is needed in an autonomic network. It is not safe to assume 536 that a large network is physically secured against interference or 537 that all personnel are trustworthy. Each autonomic device should be 538 capable of proving its identity and authenticating its messages. One 539 approach would be to use a private/public key pair and sufficiently 540 strong cryptography. Each device would generate its own private key, 541 which is never exported from the device. The device identity and 542 public key would be recorded in a network-wide database. The 543 alternative of using symmetric keys (shared secrets) is less 544 attractive, since it creates a risk of key leakage as well as a key 545 management problem when devices are installed or removed. 547 Generally speaking, no personal information is expected to be 548 involved in the negotiation protocol, so there should be no direct 549 impact on personal privacy. Nevertheless, traffic flow paths, VPNs, 550 etc. may be negotiated, which could be of interest for traffic 551 analysis. Also, carriers generally want to conceal details of their 552 network topology and traffic density from outsiders. Therefore, 553 since insider attacks cannot be prevented in a large carrier network, 554 the security mechanism for the negotiation protocol needs to provide 555 message confidentiality. 557 6. IANA Considerations 559 This draft does not request any IANA action. 561 7. Acknowledgements 563 The authors want to thank Zhenbin Li, Bing Liu for valuable comments. 565 This document was produced using the xml2rfc tool [RFC2629]. 567 8. Change Log [RFC Editor please remove] 569 draft-jiang-negotiation-config-ps-03, text improvements, added 570 RESTCONF and HNCP to existing protocols, 2014-05-19. 572 draft-jiang-negotiation-config-ps-02, text improvements, added extra 573 existing protocols, 2014-01-19. 575 draft-jiang-negotiation-config-ps-01, add more requirements, and add 576 more considerations for behavior model, 2013-10-11. 578 draft-jiang-negotiation-config-ps-00, original version, 2013-06-29. 580 9. Informative References 582 [I-D.boucadair-network-automation-requirements] 583 Boucadair, M., Jacquenet, C., and L. Contreras, 584 "Requirements for Automated (Configuration) Management", 585 draft-boucadair-network-automation-requirements-03 (work 586 in progress), February 2014. 588 [I-D.ietf-homenet-hncp] 589 Stenberg, M. and S. Barth, "Home Networking Control 590 Protocol", draft-ietf-homenet-hncp-00 (work in progress), 591 April 2014. 593 [I-D.ietf-netconf-restconf] 594 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 595 "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work 596 in progress), March 2014. 598 [I-D.irtf-nmrg-an-gap-analysis] 599 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 600 for Autonomic Networking", draft-irtf-nmrg-an-gap- 601 analysis-00 (work in progress), April 2014. 603 [I-D.irtf-nmrg-autonomic-network-definitions] 604 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 605 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 606 Networking - Definitions and Design Goals", draft-irtf- 607 nmrg-autonomic-network-definitions-00 (work in progress), 608 December 2013. 610 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 611 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 612 Functional Specification", RFC 2205, September 1997. 614 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 615 June 1999. 617 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 618 "Remote Authentication Dial In User Service (RADIUS)", RFC 619 2865, June 2000. 621 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 622 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 623 Tunnels", RFC 3209, December 2001. 625 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 626 and M. Carney, "Dynamic Host Configuration Protocol for 627 IPv6 (DHCPv6)", RFC 3315, July 2003. 629 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 630 Simple Network Management Protocol (SNMP)", STD 62, RFC 631 3416, December 2002. 633 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 634 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 635 September 2007. 637 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 638 Signalling Transport", RFC 5971, October 2010. 640 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 641 Bierman, "Network Configuration Protocol (NETCONF)", RFC 642 6241, June 2011. 644 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 645 "Diameter Base Protocol", RFC 6733, October 2012. 647 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 648 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 649 2013. 651 Authors' Addresses 653 Sheng Jiang 654 Huawei Technologies Co., Ltd 655 Q14, Huawei Campus, No.156 Beiqing Road 656 Hai-Dian District, Beijing, 100095 657 P.R. China 659 Email: jiangsheng@huawei.com 661 Yuanbin Yin 662 Huawei Technologies Co., Ltd 663 Q15, Huawei Campus, No.156 Beiqing Road 664 Hai-Dian District, Beijing, 100095 665 P.R. China 667 Email: yinyuanbin@huawei.com 669 Brian Carpenter 670 Department of Computer Science 671 University of Auckland 672 PB 92019 673 Auckland 1142 674 New Zealand 676 Email: brian.e.carpenter@gmail.com