idnits 2.17.1 draft-boucadair-network-automation-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2012) is 4149 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 Summary: 1 error (**), 0 flaws (~~), 2 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: June 17, 2013 December 14, 2012 7 Requirements for Automated (Configuration) Management 8 draft-boucadair-network-automation-requirements-00 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 June 17, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 5 58 3. Issues Raised by Configuration Operations . . . . . . . . . . 5 59 3.1. Heterogeneous Environments . . . . . . . . . . . . . . . . 5 60 3.2. Complex Topologies . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Multi-Functional Devices . . . . . . . . . . . . . . . . . 6 62 3.4. Performance Impacts . . . . . . . . . . . . . . . . . . . 6 63 3.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Limits of Manual Configuration . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . 9 70 5.1.2. Performance Requirements . . . . . . . . . . . . . . . 10 71 5.1.3. Backward Compatibility . . . . . . . . . . . . . . . . 10 72 5.2. Requirements for Configuration Information . . . . . . . . 11 73 5.2.1. Network Services . . . . . . . . . . . . . . . . . . . 11 74 5.2.2. Forwarding Services . . . . . . . . . . . . . . . . . 12 75 5.3. Global Management Requirements . . . . . . . . . . . . . . 14 76 5.3.1. Fault Management . . . . . . . . . . . . . . . . . . . 14 77 5.3.2. Configuration Management . . . . . . . . . . . . . . . 14 78 5.3.3. Performance Management . . . . . . . . . . . . . . . . 14 79 5.4. Security Management . . . . . . . . . . . . . . . . . . . 14 80 5.4.1. Device Authentication . . . . . . . . . . . . . . . . 14 81 5.4.2. Integrity of Configuration Information . . . . . . . . 15 82 5.4.3. Confidentiality of Exchanged Data . . . . . . . . . . 15 83 5.4.4. Key Management . . . . . . . . . . . . . . . . . . . . 15 84 5.4.5. Connection Log . . . . . . . . . . . . . . . . . . . . 15 85 5.4.6. Profiles . . . . . . . . . . . . . . . . . . . . . . . 15 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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: 117 o Generate policy-related and configuration data based on a well- 118 defined set of triggers and events. 119 o Monitor the outcome of a configured function/device to assess 120 whether the observed behavior is aligned with the expected 121 behavior. 123 This document assumes that service differentiation at the network 124 layer can be enforced by tweaking various parameters which belong to 125 distinct dimensions (e.g, forwarding, routing, traffic access 126 management, traffic classification, etc.). As such, the decision 127 point is likely to interact with several engines (e.g., routing 128 engine, forwarding engine, etc.). In particular, this document 129 considers that an I2RS system can be seen as a subset of an overall 130 framework. I2RS is limited to routing and forwarding actions (see 131 Section 5.2.2). To meet performance requirements (see 132 Section 5.1.2), it is strongly encouraged to design a system which 133 interacts directly with the routing and forwarding system, rather 134 than requiring local proxy functions which are responsible for 135 translating vendor-independent commands and policies into vendor- 136 specific configuration commands and syntax. 138 In addition to protocol-related considerations, automating network 139 operations heavily relies upon the availability of intelligent policy 140 decision points. Sharing best design practices for policy decision 141 point logics would facilitate the adoption of the proposed approach 142 (see Section 4). 144 The document enumerates currently encountered issues (see Section 3) 145 and identifies a set of requirements (see Section 5). A service- 146 driven approach is purposed in Section 4. 148 1.1. Terminology 150 This document makes use of the following terms: 151 o Decision point: is an entity that is responsible for making 152 decisions that yield the production of configuration information 153 which will be conveyed towards (and processed by) the set of 154 relevant managed entities. 155 o Managed entity: any (networking) device that will participate in 156 the establishment, the activation and the maintenance of a given 157 service. Such devices MAY include routers and terminals, whatever 158 the configuration procedures and underlying technologies to be 159 used for the delivery of the said service. 161 1.2. Motivation 163 Service providers and network operators have gained experience in 164 implementing, deploying and manipulating a large set of protocols and 165 associated information. Some data models have also been defined for 166 network management purposes. Thus, several protocols have been 167 standardized, such as SNMP (Simple Network Management Protocol 168 [RFC3410]), COPS (Common Open Policy Service [RFC2748]), (COPS-PR 169 [RFC3084]) or, more recently, NETCONF [RFC6241]. 171 In addition, multiple data models have been defined and used by 172 operators like CIM (Core Information Model), DEN (Directory-Enabled 173 Network), SMI (Structure of Management Information [RFC2578]), SPPI 174 (Structure of Policy Provisioning Information [RFC3159]), and, more 175 recently, YANG [RFC6022]. 177 Despite this standardization effort, most of the service operators 178 still assume manual configuration through proprietary CLI (Command 179 Line Interface) commands possibly combined with in-house developed, 180 vendor-specific scripts to proceed with the configuration of numerous 181 features, such as forwarding and routing capabilities, Quality of 182 Service (sometimes including traffic engineering) capabilities, and 183 security capabilities. 185 This is because existing standards have either failed to (1) be 186 massively adopted so far (e.g., very few operators (if no operator at 187 all) use SNMP to configure routers due to security concerns, while 188 YANG-formatted information models are hardly supported and remain at 189 a very embryonic stage), or (2) address service provider and network 190 operator requirements about configuration framework and procedures. 192 The purpose of this document is to document such requirements. 194 1.3. Scope 196 Maintain and operate self-adaptive networks may be seen as a long 197 term objective for IP service providers. To achieve this goal, 198 intermediate objectives should be defined, such as: 199 1. Define a framework to expose IP connectivity services to external 200 parties, including peering IP network operators, content 201 providers, services relying on connectivity services (e.g., IP 202 TV, VoIP) (see 203 [I-D.boucadair-connectivity-provisioning-profile]). 204 2. Ability to automatically translate IP connectivity requirements 205 into configuration and provision actions. 206 3. Dynamically adapt service configuration to be aligned with 207 expected service objectives. 208 4. Automate service negotiation and service activation. 209 5. Optimize resource utilization, e.g., automatically set traffic 210 engineering objectives. 212 Discussing the items above is out of scope. This document only 213 discusses requirements for (automated) configuration procedures and 214 protocol. 216 2. Requirements Language 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [RFC2119]. 222 3. Issues Raised by Configuration Operations 224 The following sub-sections enumerates a set of issues. 226 3.1. Heterogeneous Environments 228 The delivery of IP services relies upon the activation of a set of 229 capabilities located in various devices that include routers, 230 switches, service platforms, etc. In particular, a large set of 231 protocols need to be configured, such as routing protocols, 232 management protocols, security protocols, let alone capabilities that 233 relate to addressing scheme management, policy enforcement, etc. 235 Such a diversity of features and protocols may increase the risk of 236 inconsistency at the cost of QoS degradation or even service 237 disruption. Therefore, the configuration information which is 238 forwarded to the whole set of participating devices for delivering a 239 given service or a set of services should be consistent, whatever the 240 number of features/services to be activated/deployed in the network. 242 3.2. Complex Topologies 244 Network operators should have means to dynamically discover the 245 topology of their network. 247 Such topological information should be as elaborate as possible, 248 including details like the links that connect network devices, their 249 capacity, such as the total bandwidth, the available bandwidth, the 250 bandwidth that can be reserved, etc. 252 3.3. Multi-Functional Devices 254 Numerous, often multi-vendor devices are involved in the delivery of 255 IP services. These devices support various capabilities that need to 256 be combined for the delivery of a given service or a set of services. 257 The availability and status of such capabilities is therefore a 258 critical information for service providers, since it is likely to 259 affect service and network design, let alone operational procedures. 261 Therefore, service providers and network operators should have means 262 to: 264 o Dynamically retrieve, list and classify the capabilities supported 265 by a given device (or a set thereof), 266 o Dynamically acquire detailed information about the availability 267 and status of any activated capability of any device at any given 268 time. 269 o Dynamically retrieve the version of embedded software modules, 270 interfaces, OS version, etc. 272 3.4. Performance Impacts 274 Configuring a set of devices to deliver a service takes time. In 275 addition, depending on the complexity of the service, erroneous 276 configurations may occur at the cost of jeopardizing the overall 277 quality of a service, if not causing service disruption. From this 278 perspective, some performance indicators must be defined and measured 279 to assess: 280 o The time to deliver a service, from subscription to operation. 281 Such indicator may be further decomposed into elementary 282 performance metrics, e.g., the time it takes to complete the 283 configurations tasks that are specific to the enforcement of a 284 given policy (forwarding, routing, QoS, etc.) 285 o The impact of any configuration change on the overall service 286 performance (including customer's own perception). 288 Tools to qualify (by simulation) any possible impact of an elementary 289 configuration task before such task is performed should be supported. 290 These tools aims to prevent errors amplification. 292 3.5. Scalability 294 As far as scalability is concerned, adequate indicators should be 295 specified in order to assess the ability of configuration techniques 296 and protocols to support a large number of simultaneous processes. 297 The maintenance of these processes should not impact the performance 298 of the configuration system as a whole (i.e., manager and managed 299 entities, amount of configuration task-specific traffic exchanged 300 between manager and managed entities, periodicity of configuration 301 operations, etc.). 303 Therefore, configuration operations should be qualified with 304 performance indicators in order to check whether the architecture 305 designed for configuration management is scalable in terms of: 306 o Amount of configuration data to be processed per unit of time, as 307 a function of the number and the nature of the capabilities and 308 devices that need to be configured. 309 o Amount of traffic generated by any reporting mechanism that may be 310 associated to a configuration process. 311 o Number of processes that are created in order to achieve specific 312 configuration operations. 314 3.6. Limits of Manual Configuration 316 Manual configuration is not only a likely source of errors, but it 317 also affects the time it takes to complete a configuration task (or a 318 combination thereof) to deliver a service, as a function of the task 319 complexity and the need for global consistency. Thus, the efficiency 320 of a configuration process is likely to be improved by the 321 introduction of a high level of automation. Automation is defined as 322 follows: 324 o Automatic provisioning of configuration information to the 325 participating devices. 326 o Dynamic enforcement of policies (possibly based upon the use of 327 dynamic resource allocation techniques). 328 o Dynamic reporting mechanisms to notify about the actual processing 329 of configuration information by a participating device. 331 3.7. Security Issues 333 Configuring a network or a service raises several security issues, 334 including (but not limited to): 335 o The integrity of the configuration information, possibly yielding 336 the preservation of the confidentiality of such information when 337 being forwarded over a public IP infrastructure, 338 o The need for authorizing and authenticating devices/entities that 339 have the ability of manipulating configuration information 340 (define, instantiate, forward and process), 341 o Mutual authentication between manager and managed entities. 343 4. Introducing Service-Driven Configuration Management 345 Current practice consists in configuring elementary functions, i.e., 346 configuration management for a given service offering is decomposed 347 into a set of elementary tasks. Thus, the consistency of 348 configuration operations for the sake of service delivery must be 349 checked by any means appropriate. 351 A network device should be seen as a means to deploy a service and 352 not just as a component of such service. Thus, service delivery 353 procedures should not assume the configuration of devices one after 354 the other, but rather globally, i.e., at the scale of the network 355 that supports the said service. Such a service-driven configuration 356 management scheme is therefore meant to facilitate and improve the 357 completion of configuration tasks, by means of highly automated, 358 service-wise, global configuration procedures. 360 This in particular assumes the need for robust configuration 361 mechanisms that include appropriate protocol machinery (e.g., from a 362 reliable transport mode perspective) to convey configuration 363 information between manager and managed entities, as well as reliable 364 consistency check procedures. The latter is not only meant to assess 365 the validity of all the configuration operations service-wise, but 366 also the efficiency of the corresponding yet dynamic policy 367 enforcement and resource allocation schemes. 369 An implementation example is the case of service providers who could 370 dedicate (logical) centralized entities which are responsible for the 371 provisioning and the management of participating devices. The main 372 function of these centralized entities is to make appropriate 373 decisions and generate the decision-derived configuration data that 374 will be forwarded to the participating devices. In addition, these 375 centralized entities will make sure of the consistency of the 376 decisions that have been made to deliver the service, according to a 377 dynamic configuration policy enforcement scheme. These logical 378 entities will be responsible for assessing whether the enforced 379 policies are compliant with the expected behavior and how efficiently 380 they are enforced. 382 Service-driven configuration management leads to the following 383 assumptions: 384 o Data and information models MUST be service-oriented, 385 o Configuration protocol(s) SHOULD reuse existing standard data and 386 information models as much as possible, 387 o Configuration protocol(s) SHOULD be flexible enough to facilitate 388 the support of new features without compromising the protocol 389 robustness (especially from a performance and scalability 390 standpoints), 391 o Configuration protocol(s) SHOULD provide means to check the 392 consistency of configuration information service-wise. 394 5. Requirements 396 5.1. Protocol Requirements 398 Configuration information MUST be provided to the participating 399 devices by means of a protocol to be used between such devices and a 400 presumably centralized manager entity. The latter can be seen as a 401 decision point where configuration information is stored, maintained 402 and updated whenever required. 404 Decisions about configuring additional features or devices, enforcing 405 policies and allocating resources are made accordingly, e.g., as a 406 function of the number of Service Level Specification templates that 407 are processed per unit of time combined with traffic forecasts that 408 are updated on a regular basis. Such decisions are converted into 409 configuration information that is forwarded towards the relevant 410 managed entities. 412 5.1.1. Functional Requirements 414 The vendor-independent communication protocol for conveying 415 configuration information SHOULD have the following characteristics: 416 1. The protocol MUST use a reliable transport mode, and be 417 independent from the network layer (i.e., configuration 418 information MUST be conveyed over IPv4 and IPv6 network 419 infrastructures indifferently), 420 2. The protocol architecture SHOULD provide a means for dynamically 421 providing the configuration information to the participating 422 devices, so that a high level of automation is introduced in the 423 actual delivery of any given service. 425 3. The protocol SHOULD provide the relevant means (encoding 426 capabilities, operation and command primitives, extension 427 capabilities that allow additional operations, etc.) to be able 428 to reliably and securely convey configuration information, 429 4. The protocol SHOULD be a privileged vector for the dynamic 430 provisioning of configuration data, as well as the dynamic 431 enforcement of any policy such as a routing policy, a QoS policy 432 or a security policy. This requirement suggests the definition 433 and the support of vendor-independent instantiation procedures 434 that will aim at uniquely identifying the configuration data 435 model and the policy enforcement scheme that refer to a given IP 436 service. 437 5. The protocol SHOULD support a reporting mechanism for various 438 purposes, including the assessment of the efficiency of a given 439 policy, the ability to dynamically notify the aforementioned 440 decision point about the completion of a set of configuration 441 tasks, or the ability to dynamically report any event that may 442 affect global service operation, 443 6. The protocol SHOULD support the appropriate security mechanisms 444 to provide guarantees as far as the preservation of the 445 confidentiality of the configuration information is concerned. 447 5.1.2. Performance Requirements 449 The protocol for conveying configuration information within a network 450 should be designed so that: 451 1. The activation of the protocol by the participating devices MUST 452 NOT affect the overall performance of such devices, whatever the 453 amount of configuration data these devices will have to process 454 at any given time. 455 2. The activation of the protocol SHOULD NOT dramatically affect the 456 global resources of the network infrastructure that will convey 457 configuration information whatever its amount and scope (e.g., 458 the set of policies that need to be dynamically enforced). 460 5.1.3. Backward Compatibility 462 The introduction and the activation of a protocol for conveying 463 configuration information SHOULD allow for smooth migration 464 procedures, so that vendor-specific and vendor-independent 465 configuration procedures may gracefully co-exist on a (hopefully) 466 limited period of time. 468 Also, in case of any kind of protocol failure, it MUST be possible to 469 rely upon any vendor-specific configuration procedure as some kind of 470 rollback procedure. Such a rollback procedure MUST protect services 471 that are up and running from any risk of disruption. 473 5.2. Requirements for Configuration Information 475 Configuration tasks are currently performed with vendor-specific 476 solutions that reflect technology-specific information. It is 477 therefore more and more difficult for a service provider to get a 478 unified, homogeneous view of the network resources service-wise 479 (rather than device-wise). 481 Configuration information SHOULD therefore be provided to the 482 participating devices as unified, vendor-agnostic, service 483 configuration parameters. These parameters MUST reflect a 484 standardized service data model rather than a vendor-specific 485 information model, unlike the current situation. Examples of such 486 service data models include a tunneling service, an intra-domain 487 routing service, or a VPN service. 489 The need for a unified, homogeneous access to a multi-vendor 490 environment is becoming critical for N-Play, residential and 491 corporate, fixed and mobile service providers so that a high level of 492 automation can be introduced while proceeding with the configuration 493 of the said multi-vendor environment. This unification is clearly 494 conditioned by the availability of two key components: A 495 configuration protocol (the container) and a set of data models (the 496 content). 498 The standardization of these two components has several yet major 499 benefits: 500 o Devices are seen as functional blocks that support a set of 501 standardized capabilities; 502 o These functional blocks are described as vendor-independent 503 capabilities; 504 o These functional blocks are all managed homogeneously, whatever 505 the underlying technology. 506 As a consequence, it becomes possible to add semantic rules to 507 automate detection and correction of erroneous configurations, either 508 at the scale of a single device or at the scale of a whole network. 509 Furthermore, an equipment from vendor X could de replaced by another 510 technology from vendor Y with very little impact (if no impact at 511 all) on the configuration management procedures. 513 To do so, the data models SHOULD satisfy the following requirements. 515 5.2.1. Network Services 516 5.2.1.1. Interface Identification 518 Configuration information for identification purposes mostly deals 519 with the naming of any interface supported by a given device. This 520 naming scheme describes the properties of an interface, and must take 521 into account all the parameters that are required to correctly 522 configure an interface. The following information MUST be provided: 523 o A name, with a generic syntax that is vendor-agnostic by nature. 524 The name can define the media type of the interface. Depending on 525 the medium type, further information MAY be added (such as MTU, 526 bandwidth, supported framing and encapsulation modes, etc.); 527 o Optionally, a logical descriptor (e.g., VLANs declared on Ethernet 528 interfaces). In this case the encapsulation mode MUST be part of 529 the configuration information; 530 o Optionally, a description field that provides general (possibly 531 administrative) information about the interface. 533 5.2.1.2. Quality of Service (QoS) 535 IP services are provided with a level of quality that MAY be 536 guaranteed (either qualitatively or quantitatively) by any means 537 appropriate. QoS policies SHOULD be dynamically enforced according 538 to a data model that will accurately reflect all the elementary QoS 539 capabilities that MAY be configured and activated to enforce such 540 policies. 542 For instance, in the case of the activation of the DiffServ QoS model 543 within a network infrastructure, the participating routers SHOULD be 544 provided with the appropriate PHB (Per Hop Behavior) configuration 545 parameters. 547 5.2.1.3. Applications 549 Network devices usually support functions that allow the activation 550 of specific services like HTTP, BOOTP, DHCP, SYSLOG, etc. These 551 devices MUST therefore be provided with the corresponding 552 configuration information. 554 5.2.2. Forwarding Services 556 5.2.2.1. Routing and Forwarding Configuration Information 558 Routing and forwarding configuration information deals with the 559 decision that should be applied by a participating device to forward 560 an incoming IP datagram, according to the (possibly service-specific) 561 forwarding and routing policies defined by the service provider. 562 From this perspective, the participating devices should be provided 563 with the following configuration information: 565 1. Metric information for IGP route computation purposes, 566 2. Attribute information for BGP route computation purposes, 567 3. Static routes (if any). 569 Any candidate protocol MUST be compliant with the following 570 requirements: 571 1. Ability to retrieve routing and forwarding tables. 572 2. Ability to retrieve the configuration information of each 573 routing/forwarding device. 574 3. Ability to retrieve the capabilities of each routing/forwarding 575 device. 576 4. Ability to dynamically enforce policies on active routing 577 processes. 578 5. Ability to dynamically inject new routing and forwarding entries. 579 6. Ability to receive notifications when route changes occurred, 580 tagged by the decision point. 582 5.2.2.2. Traffic Engineering Configuration Information 584 Traffic Engineering (TE) is an important and often complex task of 585 configuration management: the participating devices should be 586 provided with the configuration information that will help them to 587 select the appropriate routes that lead to a set of destinations, 588 according to specific constraints and requirements that may have been 589 dynamically negotiated with the customer. 591 These constraints may be expressed in terms of time duration (e.g., 592 the use of a traffic-engineered route on a weekly basis), traffic 593 characterization (e.g., all IP multicast traffic should be forwarded 594 along a specific distribution tree), security concerns (e.g., use 595 IPsec tunnels), and/or QoS considerations (e.g., EF (Expedited 596 Forwarding)-marked traffic [RFC3246] should always use a subset of 597 "EF-compliant" routes). 599 5.2.2.3. Configuration Information for Tunnel Design and Activation 601 5.2.2.3.1. Tunnel Identification Information 603 The identification of a tunnel should be globally unique, especially 604 if the tunnel is to be established and activated across autonomous 605 systems. The tunnel identification schemes (e.g., endpoint 606 numbering) should be left to service providers, assuming that the 607 corresponding formalism is commonly understood, whatever the number 608 of autonomous systems the tunnel may cross. 610 The tunnel identification information SHOULD at least be composed of 611 the tunnel endpoint identification information. The tunnel 612 identification information MAY also be composed of an informal 613 description of the tunnel, e.g., the purpose of its establishment, 614 customer traffic that may be forwarded into this tunnel, etc. 616 5.2.2.3.2. Tunneling Protocol Configuration Information 618 Any participating device MUST be provided with the configuration 619 information related to the tunneling technique to be used for the 620 establishment and the activation of the tunnel. Such techniques 621 include Generic Routing Encapsulation (GRE, [RFC2784]), IP Secure in 622 tunnel mode (IPsec, [RFC2401]), Layer 2 Tunneling Protocol (L2TP, 623 [RFC2661]), etc. 625 5.3. Global Management Requirements 627 5.3.1. Fault Management 629 Mechanisms to monitor and report any fault that affects service 630 operation SHOULD be independent of the configuration protocol. 632 5.3.2. Configuration Management 634 Errors during a configuration procedure could impact the availability 635 of a given service offering, while consistency checks are mandatory 636 so as to correctly enforce a configuration policy. 638 The following requirements have been identified: 639 o Provisioning of configuration information SHOULD be as automated 640 as possible, 641 o Mechanisms to detect and diagnose configuration errors MUST be 642 supported, 643 o Consistency of configuration operations service-wise MUST be 644 checked, 645 o Simulation tools SHOULD be used to assess the validity of 646 configuration information before it is downloaded to the relevant 647 participant devices. 649 5.3.3. Performance Management 651 To be detailed. 653 5.4. Security Management 655 5.4.1. Device Authentication 657 It MUST be possible to activate mutual authentication between manager 658 and managed entities. The authentication MUST be checked before 659 exchanging any configuration data, so as to prevent DoS (Denial of 660 Service) attacks. 662 5.4.2. Integrity of Configuration Information 664 Two types of integrity MUST be provided. The first one may be done 665 at the network layer, e.g., by using the IPsec protocol suite. The 666 second type should protect configuration data at the application 667 layer (e.g., the entire file configuration is integrity protected). 669 5.4.3. Confidentiality of Exchanged Data 671 The participating device SHOULD provide security functions that 672 provide confidentiality. Encryption algorithms MUST be standard and 673 manually or automatically activated. 675 5.4.4. Key Management 677 The configuration system MUST provide a scalable key management 678 scheme. The number of keys to be managed must be at most linearly 679 proportional to the number of the devices. 681 5.4.5. Connection Log 683 The participating device MUST log all configuration connections. At 684 least the following information must be provided: 685 o Identity of the device which provided the configuration 686 information, 687 o Date of the connection, 688 o Identity of the user who has initiated the configuration process, 689 o Description of the configuration information that has been 690 forwarded. 692 5.4.6. Profiles 694 The configuration system MUST allow the definition and the activation 695 of several privilege levels. Each level could be associated to a set 696 of administrative functions. Each configuration administrator could 697 be assigned a specific access level to perform a (possibly limited) 698 set of configuration tasks. 700 6. IANA Considerations 702 This document does not require any action from IANA. 704 7. Security Considerations 706 This document reflects a set of requirements as far as the design and 707 the enforcement of configuration policies are concerned for 708 (automated) service subscription, delivery and maintenance. As such, 709 the document addresses some security concerns that have been depicted 710 in Section 5.4, and that SHOULD be taken into account when 711 considering the specification of a protocol that will convey 712 configuration information, as well as configuration information 713 itself. 715 8. Acknowledgements 717 Many thanks to M. Achemlal and Y. Adam who contributed to a first 718 version of this text. 720 9. References 722 9.1. Normative References 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 728 Internet Protocol", RFC 2401, November 1998. 730 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 731 Schoenwaelder, Ed., "Structure of Management Information 732 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 734 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 735 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 736 RFC 2661, August 1999. 738 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 739 and A. Sastry, "The COPS (Common Open Policy Service) 740 Protocol", RFC 2748, January 2000. 742 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 743 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 744 March 2000. 746 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 747 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 748 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 749 RFC 3084, March 2001. 751 [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, 752 S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure 753 of Policy Provisioning Information (SPPI)", RFC 3159, 754 August 2001. 756 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 757 J., Courtney, W., Davari, S., Firoiu, V., and D. 758 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 759 Behavior)", RFC 3246, March 2002. 761 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 762 Monitoring", RFC 6022, October 2010. 764 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 765 Bierman, "Network Configuration Protocol (NETCONF)", 766 RFC 6241, June 2011. 768 9.2. Informative References 770 [I-D.boucadair-connectivity-provisioning-profile] 771 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 772 Connectivity Provisioning Profile", 773 draft-boucadair-connectivity-provisioning-profile-02 (work 774 in progress), September 2012. 776 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 777 "Introduction and Applicability Statements for Internet- 778 Standard Management Framework", RFC 3410, December 2002. 780 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 781 Information Models and Data Models", RFC 3444, 782 January 2003. 784 Authors' Addresses 786 Mohamed Boucadair 787 France Telecom 788 Rennes, 35000 789 France 791 Email: mohamed.boucadair@orange.com 793 Christian Jacquenet 794 France Telecom 795 Rennes, 35000 796 France 798 Email: christian.jacquenet@orange.com