idnits 2.17.1 draft-ietf-anima-prefix-management-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 (March 10, 2017) is 2603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-09 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-04 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 -- Obsolete informational reference (is this intentional?): RFC 7749 (Obsoleted by RFC 7991) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG S. Jiang, Ed. 3 Internet-Draft Z. Du 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: September 11, 2017 B. Carpenter 6 Univ. of Auckland 7 Q. Sun 8 China Telecom 9 March 10, 2017 11 Autonomic IPv6 Edge Prefix Management in Large-scale Networks 12 draft-ietf-anima-prefix-management-03 14 Abstract 16 This document describes an autonomic solution for IPv6 prefix 17 management at the edge of large-scale ISP networks. An important 18 purpose of the document is to use it for validation of the design of 19 various components of the autonomic networking infrastructure. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 11, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Intended User and Administrator Experience . . . . . . . 4 59 3.2. Analysis of Parameters and Information Involved . . . . . 4 60 3.2.1. Parameters each device can decide for itself . . . . 5 61 3.2.2. Information needed from network operations . . . . . 5 62 3.2.3. Comparison with current solutions . . . . . . . . . . 5 63 3.3. Interaction with other devices . . . . . . . . . . . . . 6 64 3.3.1. Information needed from other devices . . . . . . . . 6 65 3.3.2. Monitoring, diagnostics and reporting . . . . . . . . 6 66 4. Autonomic Edge Prefix Management Solution . . . . . . . . . . 7 67 4.1. Behaviors on prefix requesting device . . . . . . . . . . 7 68 4.2. Behaviors on prefix providing device . . . . . . . . . . 8 69 4.3. Behavior after Successful Negotiation . . . . . . . . . . 9 70 4.4. Prefix logging . . . . . . . . . . . . . . . . . . . . . 9 71 5. Autonomic Prefix Management Options . . . . . . . . . . . . . 9 72 5.1. Edge Prefix Objective Option . . . . . . . . . . . . . . 9 73 6. Prefix Management Parameters . . . . . . . . . . . . . . . . 10 74 6.1. Example of Prefix Management Parameters . . . . . . . . . 10 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 11.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This document proposes an autonomic solution for IPv6 prefix 87 management in large-scale networks. The background to Autonomic 88 Networking (AN) is described in [RFC7575] and [RFC7576]. A generic 89 autonomic signaling protocol (GRASP) is specified by 90 [I-D.ietf-anima-grasp] and would be used by the proposed autonomic 91 prefix management solution. An important purpose of the present 92 document is to use it for validation of the design of GRASP and other 93 components of the autonomic networking infrastructure described in 94 [I-D.ietf-anima-reference-model]. 96 This document is not intended to solve all cases of IPv6 prefix 97 management. In fact, it assumes that the network's main 98 infrastructure elements already have addresses and prefixes. The 99 document is dedicated to how to make IPv6 prefix management at the 100 edges of large-scale networks as autonomic as possible. It is 101 specifically written for service provider (ISP) networks. Although 102 there are similarities between ISPs and large enterprise networks, 103 the requirements for the two use cases differ. 105 However, the solution is designed in a general way. Its use for a 106 broader scope than edge prefixes, including some or all 107 infrastructure prefixes, is left for future discussion. 109 Note in draft: This version is preliminary. In particular, many 110 design details may be subject to change until the Anima 111 specifications become agreed. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 [RFC2119] when they appear in ALL CAPS. When these words are not in 119 ALL CAPS (such as "should" or "Should"), they have their usual 120 English meanings, and are not to be interpreted as [RFC2119] key 121 words. 123 This document uses terminology defined in [RFC7575]. 125 3. Problem Statement 127 The autonomic networking use case considered here is autonomic IPv6 128 prefix management at the edge of large-scale ISP networks. 130 Although DHCPv6 Prefix Delegation [RFC3633] supports automated 131 delegation of IPv6 prefixes from one router to another, prefix 132 management is still largely depending on human planning. In other 133 words, there is no basic information or policy to support autonomic 134 decisions on the prefix length that each router should request or be 135 delegated, according to its role in the network. Roles could be 136 locally defined or could be generic (edge router, interior router, 137 etc.). Furthermore, IPv6 prefix management by humans tends to be 138 rigid and static after initial planning. 140 The problem to be solved by autonomic networking is how to 141 dynamically manage IPv6 address space in large-scale networks, so 142 that IPv6 addresses can be used efficiently. Here, we limit the 143 problem to assignment of prefixes at the edge of the network, close 144 to access routers that support individual fixed-line subscribers, 145 mobile customers, and corporate customers. We assume that the core 146 infrastructure of the network has already been established with 147 appropriately assigned prefixes. The AN approach discussed in this 148 document is based on the assumption that there is a generic discovery 149 and negotiation protocol that enables direct negotiation between 150 intelligent IP routers. GRASP [I-D.ietf-anima-grasp] is intended to 151 be such a protocol. 153 3.1. Intended User and Administrator Experience 155 The intended experience is, for the administrator(s) of a large-scale 156 network, that the management of IPv6 address space at the edge of the 157 network can be run with minimum efforts, as devices at the edge are 158 added and removed and as customers of all kinds join and leave the 159 network. In the ideal scenario, the administrator(s) only have to 160 specify a single IPv6 prefix for the whole network and the initial 161 prefix length for each device role. As far as users are concerned, 162 IPv6 prefix assignment would occur exactly as it does in any other 163 network. 165 The actual prefix usage needs to be logged for potential offline 166 management operations including audit and security incident tracing. 168 3.2. Analysis of Parameters and Information Involved 170 For specific purposes of address management, a few parameters are 171 involved on each edge device (some of them can be pre-configured 172 before they are connected). They include: 174 o Identity, authentication and authorization of this device. This 175 is expected to use the autonomic networking secure bootstrap 176 process [I-D.ietf-anima-bootstrapping-keyinfra], following which 177 the device could safely take part in autonomic operations. 179 o Role of this device. 181 o An IPv6 prefix length for this device. 183 o An IPv6 prefix that is assigned to this device and its downstream 184 devices. 186 A few parameters are involved in the network as a whole. They are: 188 o Identity of a trust anchor, which is a certification authority 189 (CA) maintained by the network administrator(s), used during the 190 secure bootstrap process. 192 o Total IPv6 address space available for edge devices. It is one 193 (or several) IPv6 prefix(es). 195 o The initial prefix length for each device role. 197 3.2.1. Parameters each device can decide for itself 199 This section identifies those of the above parameters that do not 200 need external information in order for the devices concerned to set 201 them to a reasonable value after bootstrap or after a network 202 disruption. There are few of these: 204 o Role of this device. 206 o Default IPv6 prefix length for this device. 208 o Identity of this device. 210 The device may be shipped from the manufacturer with pre-configured 211 role and default prefix length, which could be modified by an 212 autonomic mechanism. 214 3.2.2. Information needed from network operations 216 This section identifies those parameters that might need operational 217 input in order for the devices concerned to set them to a non-default 218 value. 220 o Non-default value for the IPv6 prefix length for this device. 221 This needs to be decided based on the role of this device. 223 o The initial prefix length for each device role. 225 o Whether to allow the device to request more address space. 227 o The policy when to request more address space, for example, if the 228 address usage reaches a certain limit or percentage. 230 3.2.3. Comparison with current solutions 232 This section briefly compares the above use case with current 233 solutions. Currently, the address management is still largely 234 dependent on human planning. It is rigid and static after initial 235 planning. Address requests will fail if the configured address space 236 is used up. 238 Some autonomic and dynamic address management functions may be 239 achievable by extending the existing protocols, for example, 240 extending DHCPv6-PD to request IPv6 prefixes according to the device 241 role. However, defining uniform device roles may not be a practical 242 task. Some functions are not suitable to be achieved by any existing 243 protocols. 245 Using a generic autonomic discovery and negotiation protocol instead 246 of specific solutions has the advantage that additional parameters 247 can be included in the autonomic solution without creating new 248 mechanisms. This is the principal argument for a generic approach. 250 3.3. Interaction with other devices 252 3.3.1. Information needed from other devices 254 This section identifies those of the above parameters that need 255 external information from neighbor devices (including the upstream 256 devices). In many cases, two-way dialogue with neighbor devices is 257 needed to set or optimize them. 259 o Identity of a trust anchor. 261 o The device will need to discover a device, from which it can 262 acquire IPv6 address space. 264 o The initial prefix length for each device role, particularly for 265 its own downstream devices. 267 o The default value of the IPv6 prefix length may be overridden by a 268 non-default value. 270 o The device will need to request and acquire IPv6 prefix that is 271 assigned to this device and its downstream devices. 273 o The device may respond to prefix delegation request from its 274 downstream devices. 276 o The device may require to be assigned more IPv6 address space, if 277 it used up its assigned IPv6 address space. 279 3.3.2. Monitoring, diagnostics and reporting 281 This section discusses what role devices should play in monitoring, 282 fault diagnosis, and reporting. 284 o The actual address assignments need to be logged for the potential 285 offline management operations. 287 o In general, the usage situation of address space should be 288 reported to the network administrators, in an abstract way, for 289 example, statistics or visualized report. 291 o A forecast of address exhaustion should be reported. 293 4. Autonomic Edge Prefix Management Solution 295 This section introduces an autonomic edge prefix management solution. 296 It uses the generic discovery and negotiation protocol defined by 297 [I-D.ietf-anima-grasp]. The relevant options are defined in 298 Section 5. 300 The procedures described below are carried out by an Autonomic 301 Service Agent (ASA) in each device that participates in the solution. 302 We will refer to this as the PrefixManager ASA. 304 4.1. Behaviors on prefix requesting device 306 If the device containing an PrefixManager ASA has used up its address 307 pool, it can request more space according to its requirements. It 308 should decide the length of the requested prefix by the mechanism 309 described in Section 6. 311 An PrefixManager ASA that needs additional address space should 312 firstly discover peers that may be able to provide extra address 313 space. The ASA should send out a GRASP Discovery message that 314 contains an PrefixManager Objective option Section 5.1 in order to 315 discover peers also supporting that option. Then it should choose 316 one such peer, most likely the first to respond. 318 If the GRASP discovery Response message carries a divert option 319 pointing to an off-link PrefixManager ASA, the requesting ASA may 320 initiate negotiation with that ASA diverted device to find out 321 whether it can provide the requested length prefix. 323 In any case, the requesting ASA will act as a GRASP negotiation 324 initiator by sending a GRASP Request message with an PrefixManager 325 Objective option. The ASA indicates in this option both the length 326 of the requested prefix and whether the ASA supports the DHCPv6 327 Prefix Delegation (PD) function [RFC3633]. This starts a GRASP 328 negotiation process. 330 During the subsequent negotiation, the ASA will decide at each step 331 whether to accept the offered prefix. That decision, and the 332 decision to end negotiation, is an implementation choice. 334 The ASA could alternatively initiate rapid mode GRASP discovery with 335 an embedded negotiation request, if it is implemented. 337 4.2. Behaviors on prefix providing device 339 A device that receives a Discovery message with an PrefixManager 340 Objective option should respond with a GRASP Response message if it 341 contains an PrefixManager ASA. Further details of the discovery 342 process are described in [I-D.ietf-anima-grasp]. When this ASA 343 receives a subsequent Request message it should conduct a GRASP 344 negotiation sequence, using Negotiate, Confirm-waiting, and 345 Negotiation-ending messages as appropriate. The Negotiate messages 346 carry an PrefixManager Objective option. This will indicate whether 347 the sending device supports the PD function. More importantly, it 348 will indicate the prefix and its length offered to the requesting 349 ASA. As described in [I-D.ietf-anima-grasp], negotiation will 350 continue until either end stops it with a Negotiation-ending message. 351 If the negotiation succeeds, the prefix providing ASA will remove the 352 negotiated prefix from its pool, and the requesting ASA will add it. 353 If the negotiation fails, the party sending the Negotiation-ending 354 message may include an error code string. 356 During the negotiation, the ASA will decide at each step how large a 357 prefix to offer. That decision, and the decision to end negotiation, 358 is an implementation choice. 360 The ASA could alternatively negotiate in response to rapid mode GRASP 361 discovery, if it is implemented. 363 This specification is independent of whether the PrefixManager ASAs 364 are all embedded in routers, but that would be a rather natural 365 scenario. A gateway router in a hierarchical network topology 366 normally provides prefixes for routers within its subnet, and it is 367 likely to contain the first PrefixManager ASA discovered by its 368 downstream routers. However, the GRASP discovery model, including 369 its Redirect feature, means that this is not an exclusive scenario, 370 and a downstream PrefixManager ASA could negotiate a new prefix with 371 a router other than its upstream router. 373 A resource shortage may cause the gateway router to request more 374 resource in turn from its own upstream device. This would be another 375 independent GRASP discovery and negotiation process. During the 376 processing time, the gateway router should send a Confirm-waiting 377 Message to the initial requesting router, to extend its timeout. 378 When the new resource becomes available, the gateway router responds 379 with a GRASP Negotiate message with a prefix length matching the 380 request. 382 The algorithm to choose which prefixes to assign on the prefix 383 providing devices is an implementation choice. 385 4.3. Behavior after Successful Negotiation 387 Upon receiving a GRASP Negotiation-ending message that indicates that 388 an acceptable prefix length is available, the requesting device may 389 request the prefix using DHCPv6 PD, if both ASAs have indicated that 390 they are within a device that supports PD. Otherwise, it is 391 permissible for the initiating ASA to use the negotiated prefix 392 without further messages. 394 [Author's note: It is not intended to undermine DHCPv6 PD. But in 395 fact, if PD is not supported and the GRASP negotiation has succeeded, 396 there should be no problem with this and it seems consistent as a 397 solution.] 399 4.4. Prefix logging 401 Within the autonomic prefix management, all the prefix assignment is 402 done by devices without human intervention. It is therefore 403 important to record all the prefix assignment history. However, the 404 logging and reporting process is out of scope for this specification. 406 5. Autonomic Prefix Management Options 408 This section defines the GRASP options that are used to support 409 autonomic prefix management. 411 5.1. Edge Prefix Objective Option 413 The PrefixManager Objective option is a GRASP objective option 414 conforming to [I-D.ietf-anima-grasp]. Its name is "PrefixManager" 415 (see Section 8) and it carries up to three data items as its value: 416 the PD support flag, the prefix length, and the actual prefix bits. 417 The format of the PrefixManager Objective option is described as 418 follows in CBOR data definition language (CDDL) 419 [I-D.greevenbosch-appsawg-cbor-cddl]: 421 objective = ["PrefixManager", objective-flags, loop-count, 422 [PD-support, length, ?prefix]] 424 loop-count = 0..255 ; as in the GRASP specification 425 objective-flags /= ; as in the GRASP specification 426 PD-support = true / false ; indicates whether sender supports PD 427 length = 0..128 ; requested or offered prefix length 428 prefix = bytes .size 16 ; offered prefix in binary format 430 6. Prefix Management Parameters 432 An implementation of a prefix manager MUST include default settings 433 of all necessary parameters. However, within a single administrative 434 domain, the network operator MAY change default parameters for all 435 devices with a certain role. Thus it would be possible to apply an 436 intended policy for every device in a simple way, without traditional 437 configuration files. 439 For example, the network operator could change the default prefix 440 length for each type of role. A prefix management parameters 441 objective, which contains mapping information of device roles and 442 their default prefix lengths, MAY be flooded in the network, through 443 the Autonomic Control Plane (ACP) 444 [I-D.ietf-anima-autonomic-control-plane]. The objective is defined 445 in CDDL as follows: 447 objective = ["PrefixManager.Params", objective-flags, any] 449 loop-count = 0..255 ; as in the GRASP specification 450 objective-flags /= ; as in the GRASP specification 452 The 'any' object would be the relevant parameter definitions (such as 453 the example below) transmitted as a CBOR object in an appropriate 454 format. 456 This could be flooded to all nodes, and any PrefixManager ASA that 457 did not receive it for some reason could obtain a copy using GRASP 458 unicast synchronization. Upon receiving the prefix management 459 parameters, every device can decide its default prefix length by 460 matching its own role. 462 6.1. Example of Prefix Management Parameters 464 The parameters comprise mapping information of device roles and their 465 default prefix lengths in an autonomic domain. For example, suppose 466 an IPRAN operator wants to configure the prefix length of RNC Site 467 Gateway (RSG) as 34, the prefix length of Aggregation Site Gateway 468 (ASG) as 44, and the prefix length of Cell Site Gateway (CSG) as 56. 469 This could be described in the value of the PrefixManager.Params 470 objective as: 472 [ 473 [["role", "RSG"],["prefix_length", 34]], 474 [["role", "ASG"],["prefix_length", 44]], 475 [["role", "CSG"],["prefix_length", 56]] 476 ] 477 This example is expressed in JSON notation [RFC7159], which is easy 478 to represent in CBOR. 480 An alternative would be to express the parameters in YANG [RFC7950] 481 using the YANG-to-CBOR mapping [I-D.ietf-core-yang-cbor]. 483 7. Security Considerations 485 Relevant security issues are discussed in [I-D.ietf-anima-grasp]. 486 The preferred security model is that devices are trusted following 487 the secure bootstrap procedure 488 [I-D.ietf-anima-bootstrapping-keyinfra] and that a secure Autonomic 489 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] is in 490 place. 492 It is RECOMMENDED that DHCPv6 PD, if used, should be operated using 493 DHCPv6 authentication or Secure DHCPv6. 495 8. IANA Considerations 497 This document defines two new GRASP Objective Option names, 498 "PrefixManager" and "PrefixManager.Params". The IANA is requested to 499 add these to the GRASP Objective Names Table registry defined by 500 [I-D.ietf-anima-grasp] (if approved). 502 9. Acknowledgements 504 Valuable comments were received from Michael Behringer, Joel Halpern, 505 and Chongfeng Xie. 507 This document was produced using the xml2rfc tool [RFC7749]. 509 10. Change log [RFC Editor: Please remove] 511 draft-jiang-anima-prefix-management-00: original version, 2014-10-25. 513 draft-jiang-anima-prefix-management-01: add intent example and 514 coauthor Zongpeng Du, 2015-05-04. 516 draft-jiang-anima-prefix-management-02: update references and the 517 format of the prefix management intent, 2015-10-14. 519 draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and 520 purpose, update text to match latest GRASP spec, 2016-01-11. 522 draft-ietf-anima-prefix-management-01: minor update, 2016-07-08. 524 draft-ietf-anima-prefix-management-02: replaced intent discussion by 525 parameter setting, 2017-01-10. 527 draft-ietf-anima-prefix-management-03: corrected object format, 528 improved parameter setting example, 2017-03-10. 530 11. References 532 11.1. Normative References 534 [I-D.ietf-anima-autonomic-control-plane] 535 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 536 Control Plane", draft-ietf-anima-autonomic-control- 537 plane-05 (work in progress), January 2017. 539 [I-D.ietf-anima-bootstrapping-keyinfra] 540 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 541 S., and K. Watsen, "Bootstrapping Remote Secure Key 542 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 543 keyinfra-04 (work in progress), October 2016. 545 [I-D.ietf-anima-grasp] 546 Bormann, C., Carpenter, B., and B. Liu, "A Generic 547 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 548 grasp-09 (work in progress), December 2016. 550 [I-D.ietf-core-yang-cbor] 551 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 552 Minaburo, "CBOR Encoding of Data Modeled with YANG", 553 draft-ietf-core-yang-cbor-04 (work in progress), February 554 2017. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 562 Host Configuration Protocol (DHCP) version 6", RFC 3633, 563 DOI 10.17487/RFC3633, December 2003, 564 . 566 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 567 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 568 2014, . 570 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 571 RFC 7950, DOI 10.17487/RFC7950, August 2016, 572 . 574 11.2. Informative References 576 [I-D.greevenbosch-appsawg-cbor-cddl] 577 Vigano, C. and H. Birkholz, "CBOR data definition language 578 (CDDL): a notational convention to express CBOR data 579 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 580 in progress), September 2016. 582 [I-D.ietf-anima-reference-model] 583 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 584 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 585 Reference Model for Autonomic Networking", draft-ietf- 586 anima-reference-model-02 (work in progress), July 2016. 588 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 589 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 590 Networking: Definitions and Design Goals", RFC 7575, 591 DOI 10.17487/RFC7575, June 2015, 592 . 594 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 595 Analysis for Autonomic Networking", RFC 7576, 596 DOI 10.17487/RFC7576, June 2015, 597 . 599 [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", 600 RFC 7749, DOI 10.17487/RFC7749, February 2016, 601 . 603 Authors' Addresses 605 Sheng Jiang (editor) 606 Huawei Technologies Co., Ltd 607 Q14, Huawei Campus, No.156 Beiqing Road 608 Hai-Dian District, Beijing, 100095 609 P.R. China 611 Email: jiangsheng@huawei.com 612 Zongpeng Du 613 Huawei Technologies Co., Ltd 614 Q14, Huawei Campus, No.156 Beiqing Road 615 Hai-Dian District, Beijing, 100095 616 P.R. China 618 Email: duzongpeng@huawei.com 620 Brian Carpenter 621 Department of Computer Science 622 University of Auckland 623 PB 92019 624 Auckland 1142 625 New Zealand 627 Email: brian.e.carpenter@gmail.com 629 Qiong Sun 630 China Telecom 631 No.118, Xizhimennei Street 632 Beijing 100035 633 P. R. China 635 Email: sunqiong@ctbri.com.cn