idnits 2.17.1 draft-boucadair-network-automation-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2013) is 3972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-05) exists of draft-boucadair-connectivity-provisioning-profile-02 == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: December 12, 2013 June 10, 2013 7 Requirements for Automated (Configuration) Management 8 draft-boucadair-network-automation-requirements-01 10 Abstract 12 Given the ever-increasing complexity of the configuration tasks 13 required for the dynamic provisioning of IP networks and services, 14 this document aims at listing the requirements to drive the 15 specification of an automated configuration management framework, 16 including the requirements for a protocol to convey configuration 17 information towards the managed entities. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 12, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 58 3. Issues Raised by Configuration Operations . . . . . . . . . . 6 59 3.1. Heterogeneous Environments . . . . . . . . . . . . . . . 6 60 3.2. Complex Topologies . . . . . . . . . . . . . . . . . . . 6 61 3.3. Multi-Functional Devices . . . . . . . . . . . . . . . . 6 62 3.4. Performance Impacts . . . . . . . . . . . . . . . . . . . 7 63 3.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Limits of Manual Configuration . . . . . . . . . . . . . 8 65 3.7. Security Issues . . . . . . . . . . . . . . . . . . . . . 8 66 4. Introducing Service-Driven Configuration Management . . . . . 8 67 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 9 69 5.1.1. Functional Requirements . . . . . . . . . . . . . . . 10 70 5.1.2. Performance Requirements . . . . . . . . . . . . . . 11 71 5.1.3. Backward Compatibility . . . . . . . . . . . . . . . 11 72 5.2. Requirements for Configuration Information . . . . . . . 11 73 5.2.1. Network Services . . . . . . . . . . . . . . . . . . 12 74 5.2.2. Forwarding Services . . . . . . . . . . . . . . . . . 13 75 5.3. Global Management Requirements . . . . . . . . . . . . . 14 76 5.3.1. Fault Management . . . . . . . . . . . . . . . . . . 15 77 5.3.2. Configuration Management . . . . . . . . . . . . . . 15 78 5.3.3. Performance Management . . . . . . . . . . . . . . . 15 79 5.4. Security Management . . . . . . . . . . . . . . . . . . . 15 80 5.4.1. Device Authentication . . . . . . . . . . . . . . . . 15 81 5.4.2. Integrity of Configuration Information . . . . . . . 15 82 5.4.3. Confidentiality of Exchanged Data . . . . . . . . . . 16 83 5.4.4. Key Management . . . . . . . . . . . . . . . . . . . 16 84 5.4.5. Connection Log . . . . . . . . . . . . . . . . . . . 16 85 5.4.6. Profiles . . . . . . . . . . . . . . . . . . . . . . 16 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 9.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 IP network and service configuration procedures are currently handled 97 by skilled personnel who is often required to acquire a high level of 98 expertise that grows as the variety and the complexity of the 99 services to be delivered over an IP network. This demand for a high 100 level of expertise is further increased by heterogeneous network and 101 service environments where each equipment manufacturer has developed 102 its own proprietary interfaces and configuration schemes. As a 103 consequence, the time to deliver complex yet advanced IP service 104 offerings (such as IPTV, VPN, etc.) is also increasing at the risk of 105 jeopardizing customers' quality of experience. 107 This document advocates for the need to undertake a standardization 108 effort to define an automated provisioning framework that includes a 109 set of interfaces and protocol(s) for conveying configuration 110 information which should help in facilitating the automation of the 111 network resource allocation and service delivery procedures. 112 Defining standard data and information models [RFC3444] to capture 113 offered network services would help to automate the process of 114 service ordering and activation and therefore accelerating service 115 provisioning. Automation should not be targeted at dynamically 116 enforcing policies only, but also be encouraged to: 118 o Generate policy-related and configuration data based on a well- 119 defined set of triggers and events. 120 o Monitor the outcome of a configured function/device to assess 121 whether the observed behavior is aligned with the expected 122 behavior. 124 This document assumes that service differentiation at the network 125 layer can be enforced by tweaking various parameters which belong to 126 distinct dimensions (e.g, forwarding, routing, traffic access 127 management, traffic classification, etc.). As such, the decision 128 point is likely to interact with several engines (e.g., routing 129 engine, forwarding engine, etc.). In particular, this document 130 considers that an I2RS system can be seen as a subset of an overall 131 framework. I2RS is limited to routing and forwarding actions (see 132 Section 5.2.2). To meet performance requirements (see 133 Section 5.1.2), it is strongly encouraged to design a system which 134 interacts directly with the routing and forwarding system, rather 135 than requiring local proxy functions which are responsible for 136 translating vendor-independent commands and policies into vendor- 137 specific configuration commands and syntax. 139 In addition to protocol-related considerations, automating network 140 operations heavily relies upon the availability of intelligent policy 141 decision points. Sharing best design practices for policy decision 142 point logics would facilitate the adoption of the proposed approach 143 (see Section 4). 145 The document enumerates currently encountered issues (see Section 3) 146 and identifies a set of requirements (see Section 5). A service- 147 driven approach is purposed in Section 4. 149 1.1. Terminology 151 This document makes use of the following terms: 153 o Decision point: is an entity that is responsible for making 154 decisions that yield the production of configuration information 155 which will be conveyed towards (and processed by) the set of 156 relevant managed entities. 157 o Managed entity: any (networking) device that will participate in 158 the establishment, the activation and the maintenance of a given 159 service. Such devices MAY include routers and terminals, whatever 160 the configuration procedures and underlying technologies to be 161 used for the delivery of the said service. 163 1.2. Motivation 165 Service providers and network operators have gained experience in 166 implementing, deploying and manipulating a large set of protocols and 167 associated information. Some data models have also been defined for 168 network management purposes. Thus, several protocols have been 169 standardized, such as SNMP (Simple Network Management Protocol 170 [RFC3410]), COPS (Common Open Policy Service [RFC2748]), (COPS-PR 171 [RFC3084]) or, more recently, NETCONF [RFC6241]. 173 In addition, multiple data models have been defined and used by 174 operators like CIM (Core Information Model), DEN (Directory-Enabled 175 Network), SMI (Structure of Management Information [RFC2578]), SPPI 176 (Structure of Policy Provisioning Information [RFC3159]), and, more 177 recently, YANG [RFC6022]. 179 Despite this standardization effort, most of the service operators 180 still assume manual configuration through proprietary CLI (Command 181 Line Interface) commands possibly combined with in-house developed, 182 vendor-specific scripts to proceed with the configuration of numerous 183 features, such as forwarding and routing capabilities, Quality of 184 Service (sometimes including traffic engineering) capabilities, and 185 security capabilities. 187 Other non-technological challenges are also to be taken into 188 consideration when discussing network automation (e.g., to what 189 extent an automated system will accommodate both simple and complex 190 business scenarios, how an automated system will evolve to 191 accommodate changes and new procedures, assess the impact on testing 192 methodologies,etc.). 194 The purpose of this document is to document requirements rather than 195 focusing on the non-technological challenges. 197 1.3. Scope 199 Maintain and operate self-adaptive networks may be seen as a long 200 term objective for IP service providers. To achieve this goal, 201 intermediate objectives should be defined, such as: 203 1. Define a framework to expose IP connectivity services to external 204 parties, including peering IP network operators, content 205 providers, services relying on connectivity services (e.g., IP 206 TV, VoIP) (see 207 [I-D.boucadair-connectivity-provisioning-profile]). 208 2. Ability to automatically translate IP connectivity requirements 209 into configuration and provision actions. 210 3. Dynamically adapt service configuration to be aligned with 211 expected service objectives. 212 4. Automate service negotiation and service activation (e.g., 213 [I-D.boucadair-connectivity-provisioning-protocol]). 214 5. Optimize resource utilization, e.g., automatically set traffic 215 engineering objectives. 217 Discussing the items above is out of scope. This document only 218 discusses requirements for (automated) configuration procedures and 219 protocol. 221 2. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in [RFC2119]. 227 3. Issues Raised by Configuration Operations 229 The following sub-sections enumerates a set of issues. 231 3.1. Heterogeneous Environments 233 The delivery of IP services relies upon the activation of a set of 234 capabilities located in various devices that include routers, 235 switches, service platforms, etc. In particular, a large set of 236 protocols need to be configured, such as routing protocols, 237 management protocols, security protocols, let alone capabilities that 238 relate to addressing scheme management, policy enforcement, etc. 240 Such a diversity of features and protocols may increase the risk of 241 inconsistency at the cost of QoS degradation or even service 242 disruption. Therefore, the configuration information which is 243 forwarded to the whole set of participating devices for delivering a 244 given service or a set of services should be consistent, whatever the 245 number of features/services to be activated/deployed in the network. 247 3.2. Complex Topologies 249 Network operators should have means to dynamically discover the 250 topology of their network. 252 Such topological information should be as elaborate as possible, 253 including details like the links that connect network devices, their 254 capacity, such as the total bandwidth, the available bandwidth, the 255 bandwidth that can be reserved, etc. 257 3.3. Multi-Functional Devices 259 Numerous, often multi-vendor devices are involved in the delivery of 260 IP services. These devices support various capabilities that need to 261 be combined for the delivery of a given service or a set of services. 262 The availability and status of such capabilities is therefore a 263 critical information for service providers, since it is likely to 264 affect service and network design, let alone operational procedures. 266 Therefore, service providers and network operators should have means 267 to: 269 o Dynamically retrieve, list and classify the capabilities supported 270 by a given device (or a set thereof), 271 o Dynamically acquire detailed information about the availability 272 and status of any activated capability of any device at any given 273 time. 274 o Dynamically retrieve the version of embedded software modules, 275 interfaces, OS version, etc. 277 3.4. Performance Impacts 279 Configuring a set of devices to deliver a service takes time. In 280 addition, depending on the complexity of the service, erroneous 281 configurations may occur at the cost of jeopardizing the overall 282 quality of a service, if not causing service disruption. From this 283 perspective, some performance indicators must be defined and measured 284 to assess: 286 o The time to deliver a service, from subscription to operation. 287 Such indicator may be further decomposed into elementary 288 performance metrics, e.g., the time it takes to complete the 289 configurations tasks that are specific to the enforcement of a 290 given policy (forwarding, routing, QoS, etc.) 291 o The impact of any configuration change on the overall service 292 performance (including customer's own perception). 294 Tools to qualify (by simulation or emulation) any possible impact of 295 an elementary configuration task before such task is performed should 296 be supported. These tools aims to prevent errors amplification. 298 3.5. Scalability 300 As far as scalability is concerned, adequate indicators should be 301 specified in order to assess the ability of configuration techniques 302 and protocols to support a large number of simultaneous processes. 303 The maintenance of these processes should not impact the performance 304 of the configuration system as a whole (i.e., manager and managed 305 entities, amount of configuration task-specific traffic exchanged 306 between manager and managed entities, periodicity of configuration 307 operations, etc.). 309 Therefore, configuration operations should be qualified with 310 performance indicators in order to check whether the architecture 311 designed for configuration management is scalable in terms of: 313 o Amount of configuration data to be processed per unit of time, as 314 a function of the number and the nature of the capabilities and 315 devices that need to be configured. 317 o Amount of traffic generated by any reporting mechanism that may be 318 associated to a configuration process. 319 o Number of processes that are created in order to achieve specific 320 configuration operations. 322 3.6. Limits of Manual Configuration 324 Manual configuration is not only a likely source of errors, but it 325 also affects the time it takes to complete a configuration task (or a 326 combination thereof) to deliver a service, as a function of the task 327 complexity and the need for global consistency. Thus, the efficiency 328 of a configuration process is likely to be improved by the 329 introduction of a high level of automation. Automation is defined as 330 follows: 332 o Automatic provisioning of configuration information to the 333 participating devices. 334 o Dynamic enforcement of policies (possibly based upon the use of 335 dynamic resource allocation techniques). 336 o Dynamic reporting mechanisms to notify about the actual processing 337 of configuration information by a participating device. 339 3.7. Security Issues 341 Configuring a network or a service raises several security issues, 342 including (but not limited to): 344 o The integrity of the configuration information, possibly yielding 345 the preservation of the confidentiality of such information when 346 being forwarded over a public IP infrastructure, 347 o The need for authorizing and authenticating devices/entities that 348 have the ability of manipulating configuration information 349 (define, instantiate, forward and process), 350 o Mutual authentication between manager and managed entities. 352 4. Introducing Service-Driven Configuration Management 354 Current practice consists in configuring elementary functions, i.e., 355 configuration management for a given service offering is decomposed 356 into a set of elementary tasks. Thus, the consistency of 357 configuration operations for the sake of service delivery must be 358 checked by any means appropriate. 360 A network device should be seen as a means to deploy a service and 361 not just as a component of such service. Thus, service delivery 362 procedures should not assume the configuration of devices one after 363 the other, but rather globally, i.e., at the scale of the network 364 that supports the said service. Such a service-driven configuration 365 management scheme is therefore meant to facilitate and improve the 366 completion of configuration tasks, by means of highly automated, 367 service-wise, global configuration procedures. 369 This in particular assumes the need for robust configuration 370 mechanisms that include appropriate protocol machinery (e.g., from a 371 reliable transport mode perspective) to convey configuration 372 information between manager and managed entities, as well as reliable 373 consistency check procedures. The latter is not only meant to assess 374 the validity of all the configuration operations service-wise, but 375 also the efficiency of the corresponding yet dynamic policy 376 enforcement and resource allocation schemes. 378 An implementation example is the case of service providers who could 379 dedicate (logical) centralized entities which are responsible for the 380 provisioning and the management of participating devices. The main 381 function of these centralized entities is to make appropriate 382 decisions and generate the decision-derived configuration data that 383 will be forwarded to the participating devices. In addition, these 384 centralized entities will make sure of the consistency of the 385 decisions that have been made to deliver the service, according to a 386 dynamic configuration policy enforcement scheme. These logical 387 entities will be responsible for assessing whether the enforced 388 policies are compliant with the expected behavior and how efficiently 389 they are enforced. 391 Service-driven configuration management leads to the following 392 assumptions: 394 o Data and information models MUST be service-oriented, 395 o Configuration protocol(s) SHOULD reuse existing standard data and 396 information models as much as possible, 397 o Configuration protocol(s) SHOULD be flexible enough to facilitate 398 the support of new features without compromising the protocol 399 robustness (especially from a performance and scalability 400 standpoints), 401 o Configuration protocol(s) SHOULD provide means to check the 402 consistency of configuration information service-wise. 404 5. Requirements 406 5.1. Protocol Requirements 408 Configuration information MUST be provided to the participating 409 devices by means of a protocol to be used between such devices and a 410 presumably centralized manager entity. The latter can be seen as a 411 decision point where configuration information is stored, maintained 412 and updated whenever required. 414 Decisions about configuring additional features or devices, enforcing 415 policies and allocating resources are made accordingly, e.g., as a 416 function of the number of Service Level Specification templates that 417 are processed per unit of time combined with traffic forecasts that 418 are updated on a regular basis. Such decisions are converted into 419 configuration information that is forwarded towards the relevant 420 managed entities. 422 5.1.1. Functional Requirements 424 The vendor-independent communication protocol for conveying 425 configuration information SHOULD have the following characteristics: 427 1. The protocol MUST use a reliable transport mode, and be 428 independent from the network layer (i.e., configuration 429 information MUST be conveyed over IPv4 and IPv6 network 430 infrastructures indifferently), 431 2. The protocol architecture SHOULD provide a means for dynamically 432 providing the configuration information to the participating 433 devices, so that a high level of automation is introduced in the 434 actual delivery of any given service. 435 3. The protocol SHOULD provide the relevant means (encoding 436 capabilities, operation and command primitives, extension 437 capabilities that allow additional operations, etc.) to be able 438 to reliably and securely convey configuration information, 439 4. The protocol SHOULD be a privileged vector for the dynamic 440 provisioning of configuration data, as well as the dynamic 441 enforcement of any policy such as a routing policy, a QoS policy 442 or a security policy. This requirement suggests the definition 443 and the support of vendor-independent instantiation procedures 444 that will aim at uniquely identifying the configuration data 445 model and the policy enforcement scheme that refer to a given IP 446 service. 447 5. The protocol SHOULD support a reporting mechanism for various 448 purposes, including the assessment of the efficiency of a given 449 policy, the ability to dynamically notify the aforementioned 450 decision point about the completion of a set of configuration 451 tasks, or the ability to dynamically report any event that may 452 affect global service operation, 453 6. The protocol SHOULD support the appropriate security mechanisms 454 to provide guarantees as far as the preservation of the 455 confidentiality of the configuration information is concerned. 457 5.1.2. Performance Requirements 459 The protocol for conveying configuration information within a network 460 should be designed so that: 462 1. The activation of the protocol by the participating devices MUST 463 NOT affect the overall performance of such devices, whatever the 464 amount of configuration data these devices will have to process 465 at any given time. 466 2. The activation of the protocol SHOULD NOT dramatically affect the 467 global resources of the network infrastructure that will convey 468 configuration information whatever its amount and scope (e.g., 469 the set of policies that need to be dynamically enforced). 471 5.1.3. Backward Compatibility 473 The introduction and the activation of a protocol for conveying 474 configuration information SHOULD allow for smooth migration 475 procedures, so that vendor-specific and vendor-independent 476 configuration procedures may gracefully co-exist on a (hopefully) 477 limited period of time. 479 Also, in case of any kind of protocol failure, it MUST be possible to 480 rely upon any vendor-specific configuration procedure as some kind of 481 rollback procedure. Such a rollback procedure MUST protect services 482 that are up and running from any risk of disruption. 484 5.2. Requirements for Configuration Information 486 Configuration tasks are currently performed with vendor-specific 487 solutions that reflect technology-specific information. It is 488 therefore more and more difficult for a service provider to get a 489 unified, homogeneous view of the network resources service-wise 490 (rather than device-wise). 492 Configuration information SHOULD therefore be provided to the 493 participating devices as unified, vendor-agnostic, service 494 configuration parameters. These parameters MUST reflect a 495 standardized service data model rather than a vendor-specific 496 information model, unlike the current situation. Examples of such 497 service data models include a tunneling service, an intra-domain 498 routing service, or a VPN service. 500 The need for a unified, homogeneous access to a multi-vendor 501 environment is becoming critical for N-Play, residential and 502 corporate, fixed and mobile service providers so that a high level of 503 automation can be introduced while proceeding with the configuration 504 of the said multi-vendor environment. This unification is clearly 505 conditioned by the availability of two key components: A 506 configuration protocol (the container) and a set of data models (the 507 content). 509 The standardization of these two components has several yet major 510 benefits: 512 o Devices are seen as functional blocks that support a set of 513 standardized capabilities; 514 o These functional blocks are described as vendor-independent 515 capabilities; 516 o These functional blocks are all managed homogeneously, whatever 517 the underlying technology. 519 As a consequence, it becomes possible to add semantic rules to 520 automate detection and correction of erroneous configurations, either 521 at the scale of a single device or at the scale of a whole network. 522 Furthermore, an equipment from vendor X could de replaced by another 523 technology from vendor Y with very little impact (if no impact at 524 all) on the configuration management procedures. 526 To do so, the data models SHOULD satisfy the following requirements. 528 5.2.1. Network Services 530 5.2.1.1. Interface Identification 532 Configuration information for identification purposes mostly deals 533 with the naming of any interface supported by a given device. This 534 naming scheme describes the properties of an interface, and must take 535 into account all the parameters that are required to correctly 536 configure an interface. The following information MUST be provided: 538 o A name, with a generic syntax that is vendor-agnostic by nature. 539 The name can define the media type of the interface. Depending on 540 the medium type, further information MAY be added (such as MTU, 541 bandwidth, supported framing and encapsulation modes, etc.); 542 o Optionally, a logical descriptor (e.g., VLANs declared on Ethernet 543 interfaces). In this case the encapsulation mode MUST be part of 544 the configuration information; 545 o Optionally, a description field that provides general (possibly 546 administrative) information about the interface. 548 5.2.1.2. Quality of Service (QoS) 550 IP services are provided with a level of quality that MAY be 551 guaranteed (either qualitatively or quantitatively) by any means 552 appropriate. QoS policies SHOULD be dynamically enforced according 553 to a data model that will accurately reflect all the elementary QoS 554 capabilities that MAY be configured and activated to enforce such 555 policies. 557 For instance, in the case of the activation of the DiffServ QoS model 558 within a network infrastructure, the participating routers SHOULD be 559 provided with the appropriate PHB (Per Hop Behavior) configuration 560 parameters. 562 5.2.1.3. Applications 564 Network devices usually support functions that allow the activation 565 of specific services like HTTP, BOOTP, DHCP, SYSLOG, etc. These 566 devices MUST therefore be provided with the corresponding 567 configuration information. 569 5.2.2. Forwarding Services 571 5.2.2.1. Routing and Forwarding Configuration Information 573 Routing and forwarding configuration information deals with the 574 decision that should be applied by a participating device to forward 575 an incoming IP datagram, according to the (possibly service-specific) 576 forwarding and routing policies defined by the service provider. 577 From this perspective, the participating devices should be provided 578 with the following configuration information: 580 1. Metric information for IGP route computation purposes, 581 2. Attribute information for BGP route computation purposes, 582 3. Static routes (if any). 584 Any candidate protocol MUST be compliant with the following 585 requirements: 587 1. Ability to retrieve routing and forwarding tables. 588 2. Ability to retrieve the configuration information of each routing 589 /forwarding device. 590 3. Ability to retrieve the capabilities of each routing/forwarding 591 device. 592 4. Ability to dynamically enforce policies on active routing 593 processes. 594 5. Ability to dynamically inject new routing and forwarding entries. 596 6. Ability to receive notifications when route changes occurred, 597 tagged by the decision point. 599 5.2.2.2. Traffic Engineering Configuration Information 601 Traffic Engineering (TE) is an important and often complex task of 602 configuration management: the participating devices should be 603 provided with the configuration information that will help them to 604 select the appropriate routes that lead to a set of destinations, 605 according to specific constraints and requirements that may have been 606 dynamically negotiated with the customer. 608 These constraints may be expressed in terms of time duration (e.g., 609 the use of a traffic-engineered route on a weekly basis), traffic 610 characterization (e.g., all IP multicast traffic should be forwarded 611 along a specific distribution tree), security concerns (e.g., use 612 IPsec tunnels), and/or QoS considerations (e.g., EF (Expedited 613 Forwarding)-marked traffic [RFC3246] should always use a subset of 614 "EF-compliant" routes). 616 5.2.2.3. Configuration Information for Tunnel Design and Activation 618 5.2.2.3.1. Tunnel Identification Information 620 The identification of a tunnel should be globally unique, especially 621 if the tunnel is to be established and activated across autonomous 622 systems. The tunnel identification schemes (e.g., endpoint 623 numbering) should be left to service providers, assuming that the 624 corresponding formalism is commonly understood, whatever the number 625 of autonomous systems the tunnel may cross. 627 The tunnel identification information SHOULD at least be composed of 628 the tunnel endpoint identification information. The tunnel 629 identification information MAY also be composed of an informal 630 description of the tunnel, e.g., the purpose of its establishment, 631 customer traffic that may be forwarded into this tunnel, etc. 633 5.2.2.3.2. Tunneling Protocol Configuration Information 635 Any participating device MUST be provided with the configuration 636 information related to the tunneling technique to be used for the 637 establishment and the activation of the tunnel. Such techniques 638 include Generic Routing Encapsulation (GRE, [RFC2784]), IP Secure in 639 tunnel mode (IPsec, [RFC2401]), Layer 2 Tunneling Protocol (L2TP, 640 [RFC2661]), etc. 642 5.3. Global Management Requirements 643 5.3.1. Fault Management 645 Mechanisms to monitor and report any fault that affects service 646 operation SHOULD be independent of the configuration protocol. 648 5.3.2. Configuration Management 650 Errors during a configuration procedure could impact the availability 651 of a given service offering, while consistency checks are mandatory 652 so as to correctly enforce a configuration policy. 654 The following requirements have been identified: 656 o Provisioning of configuration information SHOULD be as automated 657 as possible, 658 o Mechanisms to detect and diagnose configuration errors MUST be 659 supported, 660 o Consistency of configuration operations service-wise MUST be 661 checked, 662 o Simulation tools SHOULD be used to assess the validity of 663 configuration information before it is downloaded to the relevant 664 participant devices. 666 5.3.3. Performance Management 668 To be detailed. 670 5.4. Security Management 672 5.4.1. Device Authentication 674 It MUST be possible to activate mutual authentication between manager 675 and managed entities. The authentication MUST be checked before 676 exchanging any configuration data, so as to prevent DoS (Denial of 677 Service) attacks. 679 5.4.2. Integrity of Configuration Information 681 Two types of integrity MUST be provided. The first one may be done 682 at the network layer, e.g., by using the IPsec protocol suite. The 683 second type should protect configuration data at the application 684 layer (e.g., the entire file configuration is integrity protected). 686 5.4.3. Confidentiality of Exchanged Data 688 The participating device SHOULD provide security functions that 689 provide confidentiality. Encryption algorithms MUST be standard and 690 manually or automatically activated. 692 5.4.4. Key Management 694 The configuration system MUST provide a scalable key management 695 scheme. The number of keys to be managed must be at most linearly 696 proportional to the number of the devices. 698 5.4.5. Connection Log 700 The participating device MUST log all configuration connections. At 701 least the following information must be provided: 703 o Identity of the device which provided the configuration 704 information, 705 o Date of the connection, 706 o Identity of the user who has initiated the configuration process, 707 o Description of the configuration information that has been 708 forwarded. 710 5.4.6. Profiles 712 The configuration system MUST allow the definition and the activation 713 of several privilege levels. Each level could be associated to a set 714 of administrative functions. Each configuration administrator could 715 be assigned a specific access level to perform a (possibly limited) 716 set of configuration tasks. 718 6. IANA Considerations 720 This document does not require any action from IANA. 722 7. Security Considerations 724 This document reflects a set of requirements as far as the design and 725 the enforcement of configuration policies are concerned for 726 (automated) service subscription, delivery and maintenance. As such, 727 the document addresses some security concerns that have been depicted 728 in Section 5.4, and that SHOULD be taken into account when 729 considering the specification of a protocol that will convey 730 configuration information, as well as configuration information 731 itself. 733 8. Acknowledgements 735 Many thanks to M. Achemlal and Y. Adam who contributed to a first 736 version of this text. 738 Thanks for W. George for the comments. 740 9. References 742 9.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, March 1997. 747 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 748 Internet Protocol", RFC 2401, November 1998. 750 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 751 Schoenwaelder, Ed., "Structure of Management Information 752 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 754 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 755 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 756 RFC 2661, August 1999. 758 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 759 and A. Sastry, "The COPS (Common Open Policy Service) 760 Protocol", RFC 2748, January 2000. 762 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 763 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 764 March 2000. 766 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 767 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 768 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 769 3084, March 2001. 771 [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, 772 S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure 773 of Policy Provisioning Information (SPPI)", RFC 3159, 774 August 2001. 776 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 777 J., Courtney, W., Davari, S., Firoiu, V., and D. 778 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 779 Behavior)", RFC 3246, March 2002. 781 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 782 Monitoring", RFC 6022, October 2010. 784 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 785 Bierman, "Network Configuration Protocol (NETCONF)", RFC 786 6241, June 2011. 788 9.2. Informative References 790 [I-D.boucadair-connectivity-provisioning-profile] 791 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 792 Connectivity Provisioning Profile", draft-boucadair- 793 connectivity-provisioning-profile-02 (work in progress), 794 September 2012. 796 [I-D.boucadair-connectivity-provisioning-protocol] 797 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 798 Negotiation Protocol (CPNP)", draft-boucadair- 799 connectivity-provisioning-protocol-00 (work in progress), 800 May 2013. 802 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 803 "Introduction and Applicability Statements for Internet- 804 Standard Management Framework", RFC 3410, December 2002. 806 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 807 Information Models and Data Models", RFC 3444, January 808 2003. 810 Authors' Addresses 812 Mohamed Boucadair 813 France Telecom 814 Rennes 35000 815 France 817 Email: mohamed.boucadair@orange.com 819 Christian Jacquenet 820 France Telecom 821 Rennes 35000 822 France 824 Email: christian.jacquenet@orange.com