idnits 2.17.1 draft-boucadair-network-automation-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '...e. Such devices MAY include routers a...' RFC 2119 keyword, line 546: '...ther information MAY be added (such as...' RFC 2119 keyword, line 558: '...ed with a level of quality that MAY be...' RFC 2119 keyword, line 562: '...apabilities that MAY be configured and...' RFC 2119 keyword, line 641: '...tion information MAY also be composed ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2015) is 3359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-08 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: August 17, 2015 L. Contreras 6 Telefonica I+D 7 February 13, 2015 9 Requirements for Automated (Configuration) Management 10 draft-boucadair-network-automation-requirements-05 12 Abstract 14 Given the ever-increasing complexity of the configuration tasks 15 required for the dynamic provisioning of IP networks and services, 16 this document aims at listing the requirements for an automated 17 configuration management framework. 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 August 17, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Scope & Overall Context . . . . . . . . . . . . . . . . . . . 4 56 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Issues Raised by Configuration Operations . . . . . . . . . . 5 58 5.1. Heterogeneous Environments . . . . . . . . . . . . . . . 5 59 5.2. Complex Topologies . . . . . . . . . . . . . . . . . . . 6 60 5.3. Multi-Functional Devices . . . . . . . . . . . . . . . . 6 61 5.4. Performance Impacts . . . . . . . . . . . . . . . . . . . 6 62 5.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.6. Limits of Manual Configuration . . . . . . . . . . . . . 7 64 5.7. Security Issues . . . . . . . . . . . . . . . . . . . . . 8 65 6. Introducing Service-Driven Configuration Management . . . . . 8 66 7. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 9 68 7.1.1. Functional Requirements . . . . . . . . . . . . . . . 9 69 7.1.2. Performance Requirements . . . . . . . . . . . . . . 10 70 7.1.3. Backward Compatibility . . . . . . . . . . . . . . . 10 71 7.2. Requirements for Configuration Information . . . . . . . 11 72 7.2.1. Network Services . . . . . . . . . . . . . . . . . . 12 73 7.2.2. Forwarding Services . . . . . . . . . . . . . . . . . 13 74 7.3. Global Management Requirements . . . . . . . . . . . . . 14 75 7.3.1. Fault Management . . . . . . . . . . . . . . . . . . 14 76 7.3.2. Configuration Management . . . . . . . . . . . . . . 14 77 7.3.3. Performance Management . . . . . . . . . . . . . . . 15 78 7.4. Security Management . . . . . . . . . . . . . . . . . . . 15 79 7.4.1. Device Authentication . . . . . . . . . . . . . . . . 15 80 7.4.2. Integrity of Configuration Information . . . . . . . 16 81 7.4.3. Confidentiality of Exchanged Data . . . . . . . . . . 16 82 7.4.4. Key Management . . . . . . . . . . . . . . . . . . . 16 83 7.4.5. Connection Log . . . . . . . . . . . . . . . . . . . 16 84 7.4.6. Profiles . . . . . . . . . . . . . . . . . . . . . . 16 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 88 11. Informative References . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 IP network and service configuration procedures are currently handled 94 by skilled personnel who is often required to acquire a high level of 95 expertise that grows as the variety and the complexity of the 96 services to be delivered over an IP network. This demand for a high 97 level of expertise is further increased by heterogeneous network and 98 service environments where each equipment manufacturer has developed 99 its own proprietary interfaces and configuration schemes. As a 100 consequence, the time to deliver complex yet advanced IP service 101 offerings (such as IP TV, VPN, etc.) is also increasing at the risk 102 of jeopardizing customers' quality of experience. 104 This document advocates for the need to undertake a standardization 105 effort to define an automated provisioning framework that includes a 106 set of interfaces and protocol(s) for conveying configuration 107 information which should help in facilitating the automation of the 108 network resource allocation and service delivery procedures. 109 Defining standard data and information models [RFC3444] to capture 110 offered network services would help to automate the process of 111 service ordering and activation and therefore accelerating service 112 provisioning. 114 Automation should not be targeted at dynamically enforcing policies 115 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 7.2.2). To meet performance requirements (see 132 Section 7.1.2), it is encouraged to design a system which interacts 133 directly with the routing and forwarding system, rather than 134 requiring local proxy functions which are responsible for translating 135 vendor-independent commands and policies into vendor-specific 136 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 6). 144 The document enumerates a set of encountered issues (see Section 5) 145 and identifies a set of requirements (see Section 7). A service- 146 driven approach is purposed in Section 6. 148 2. Terminology 150 This document makes use of the following terms: 152 o Decision point: is an entity that is responsible for making 153 decisions that yield the production of configuration information 154 which will be conveyed towards (and processed by) the set of 155 relevant managed entities. 156 o Managed entity: any (networking) device that will participate in 157 the establishment, the activation and the maintenance of a given 158 service. Such devices MAY include routers and terminals, whatever 159 the configuration procedures and underlying technologies to be 160 used for the delivery of the said service. 162 3. Scope & Overall Context 164 Maintain and operate self-adaptive networks may be seen as a long 165 term objective for IP service providers. To achieve this goal, 166 intermediate objectives should be defined, such as: 168 1. Define a framework to expose IP connectivity services to external 169 parties, including peering IP network operators, content 170 providers, services relying on connectivity services (e.g., IP 171 TV, VoIP) (see for example [RFC7297]). 172 2. Ability to automatically translate IP connectivity requirements 173 into configuration and provision actions. 174 3. Dynamically adapt service configuration to be aligned with 175 expected service objectives. 176 4. Automate service negotiation and service activation (e.g., 177 [I-D.boucadair-connectivity-provisioning-protocol]). 178 5. Optimize resource utilization, e.g., automatically set traffic 179 engineering objectives. 181 Discussing the items above is out of scope. This document only 182 discusses requirements for (automated) configuration procedures and 183 protocol. 185 4. Motivations 187 Service providers and network operators have gained experience in 188 implementing, deploying and manipulating a large set of protocols and 189 associated information. Some data models have also been defined for 190 network management purposes. Thus, several protocols have been 191 standardized, such as SNMP (Simple Network Management Protocol 193 [RFC3410]), COPS (Common Open Policy Service [RFC2748]), (COPS-PR 194 [RFC3084]) or, more recently, NETCONF [RFC6241]. 196 In addition, multiple data models have been defined and used by 197 operators like CIM (Core Information Model), DEN (Directory-Enabled 198 Network), SMI (Structure of Management Information [RFC2578]), SPPI 199 (Structure of Policy Provisioning Information [RFC3159]), and, more 200 recently, YANG [RFC6022]. 202 Despite this standardization effort, most of the service operators 203 still assume manual configuration through proprietary CLI (Command 204 Line Interface) commands possibly combined with in-house developed, 205 vendor-specific scripts to proceed with the configuration of numerous 206 features, such as forwarding and routing capabilities, Quality of 207 Service (sometimes including traffic engineering) capabilities, and 208 security capabilities. Some of these requirements are fulfilled by 209 existing tools/protocols but there is still a lack of wide adoption 210 of those tools. 212 Other non-technological challenges are also to be taken into 213 consideration when discussing network automation (e.g., to what 214 extent an automated system will accommodate both simple and complex 215 business scenarios, how an automated system will evolve to 216 accommodate changes and new procedures, assess the impact on testing 217 methodologies,etc.). 219 The purpose of this document is to document requirements rather than 220 focusing on the non-technological challenges. 222 5. Issues Raised by Configuration Operations 224 The following sub-sections enumerates a set of issues. 226 5.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 5.2. Complex Topologies 244 Network operators should have means to dynamically discover the 245 topology of the 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 5.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 5.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: 281 o The time to deliver a service, from subscription to operation. 282 Such indicator may be further decomposed into elementary 283 performance metrics, e.g., the time it takes to complete the 284 configurations tasks that are specific to the enforcement of a 285 given policy (forwarding, routing, QoS, etc.) 286 o The impact of any configuration change on the overall service 287 performance (including customer's own perception). 289 Tools to qualify (by simulation or emulation) any possible impact of 290 an elementary configuration task before such task is performed should 291 be supported. These tools aims to prevent errors amplification. 293 5.5. Scalability 295 As far as scalability is concerned, adequate indicators should be 296 specified in order to assess the ability of configuration techniques 297 and protocols to support a large number of simultaneous processes. 298 The maintenance of these processes should not impact the performance 299 of the configuration system as a whole (i.e., manager and managed 300 entities, amount of configuration task-specific traffic exchanged 301 between manager and managed entities, periodicity of configuration 302 operations, etc.). 304 Therefore, configuration operations should be qualified with 305 performance indicators in order to check whether the architecture 306 designed for configuration management is scalable in terms of: 308 o Amount of configuration data to be processed per unit of time, as 309 a function of the number and the nature of the capabilities and 310 devices that need to be configured. 311 o Amount of traffic generated by any reporting mechanism that may be 312 associated to a configuration process. 313 o Number of processes that are created in order to achieve specific 314 configuration operations. 316 5.6. Limits of Manual Configuration 318 Manual configuration is not only a likely source of errors, but it 319 also affects the time it takes to complete a configuration task (or a 320 combination thereof) to deliver a service, as a function of the task 321 complexity and the need for global consistency. Thus, the efficiency 322 of a configuration process is likely to be improved by the 323 introduction of a high level of automation. Automation is defined as 324 follows: 326 o Automatic provisioning of configuration information to the 327 participating devices. 328 o Dynamic enforcement of policies (possibly based upon the use of 329 dynamic resource allocation techniques). 330 o Dynamic reporting mechanisms to notify about the actual processing 331 of configuration information by a participating device. 332 o Autonomic provisioning capabilities for triggering self- 333 configuration mechanisms for the network devices. 335 Refer to Section 4.1 of [RFC7149] for a discussion on the 336 implications of full automation. 338 5.7. Security Issues 340 Configuring a network or a service raises several security issues, 341 including (but not limited to): 343 o The integrity of the configuration information, possibly yielding 344 the preservation of the confidentiality of such information when 345 being forwarded over a public IP infrastructure, 346 o The need for authorizing and authenticating devices/entities that 347 have the ability of manipulating configuration information 348 (define, instantiate, forward and process), 349 o Mutual authentication between manager and managed entities. 351 6. Introducing Service-Driven Configuration Management 353 Current practice consists in configuring elementary functions, i.e., 354 configuration management for a given service offering is decomposed 355 into a set of elementary tasks. Thus, the consistency of 356 configuration operations for the sake of service delivery must be 357 checked by any means appropriate. 359 A network device should be seen as a means to deploy a service and 360 not just as a component of such service. Thus, service delivery 361 procedures should not assume the configuration of devices one after 362 the other, but rather globally, i.e., at the scale of the network 363 that supports the said service. Such a service-driven configuration 364 management scheme is therefore meant to facilitate and improve the 365 completion of configuration tasks, by means of highly automated, 366 service-wise, global configuration procedures. 368 This in particular assumes the need for robust configuration 369 mechanisms that include appropriate protocol machinery (e.g., from a 370 reliable transport mode perspective) to convey configuration 371 information between manager and managed entities, as well as reliable 372 consistency check procedures. The latter is not only meant to assess 373 the validity of all the configuration operations service-wise, but 374 also the efficiency of the corresponding yet dynamic policy 375 enforcement and resource allocation schemes. 377 An implementation example is the case of service providers who could 378 dedicate (logical) centralized entities which are responsible for the 379 provisioning and the management of participating devices. The main 380 function of these centralized entities is to make appropriate 381 decisions and generate the decision-derived configuration data that 382 will be forwarded to the participating devices. In addition, these 383 centralized entities will make sure of the consistency of the 384 decisions that have been made to deliver the service, according to a 385 dynamic configuration policy enforcement scheme. These logical 386 entities will be responsible for assessing whether the enforced 387 policies are compliant with the expected behavior and how efficiently 388 they are enforced. 390 Service-driven configuration management leads to the following 391 assumptions: 393 o Data and information models must be service-oriented, 394 o Configuration protocol(s) should reuse existing standard data and 395 information models as much as possible, 396 o Configuration protocol(s) should be flexible enough to facilitate 397 the support of new features without compromising the protocol 398 robustness (especially from a performance and scalability 399 standpoints), 400 o Configuration protocol(s) should provide means to check the 401 consistency of configuration information service-wise. 403 7. Detailed Requirements 405 7.1. Protocol Requirements 407 Configuration information must be provided to the participating 408 devices by means of a protocol to be used between such devices and a 409 presumably centralized manager entity. The latter can be seen as a 410 decision point where configuration information is stored, maintained 411 and updated whenever required. 413 Decisions about configuring additional features or devices, enforcing 414 policies and allocating resources are made accordingly, e.g., as a 415 function of the number of Service Level Specification templates that 416 are processed per unit of time combined with traffic forecasts that 417 are updated on a regular basis. Such decisions are converted into 418 configuration information that is forwarded towards the relevant 419 managed entities. 421 7.1.1. Functional Requirements 423 The vendor-independent communication protocol for conveying 424 configuration information should have the following characteristics: 426 1. The protocol must be reliable, and be independent from the 427 network layer (i.e., configuration information must be conveyed 428 over IPv4 and IPv6 network infrastructures indifferently), 429 2. The protocol architecture should provide a means for dynamically 430 providing the configuration information to the participating 431 devices, so that a high level of automation is introduced in the 432 actual delivery of any given service. 434 3. The protocol should provide the relevant means (encoding 435 capabilities, operation and command primitives, extension 436 capabilities that allow additional operations, etc.) to be able 437 to reliably and securely convey configuration information, 438 4. The protocol should be a privileged vector for the dynamic 439 provisioning of configuration data, as well as the dynamic 440 enforcement of any policy such as a routing policy, a QoS policy 441 or a security policy. This requirement suggests the definition 442 and the support of vendor-independent instantiation procedures 443 that will aim at uniquely identifying the configuration data 444 model and the policy enforcement scheme that refer to a given IP 445 service. 446 5. The protocol should support a reporting mechanism for various 447 purposes, including the assessment of the efficiency of a given 448 policy, the ability to dynamically notify the aforementioned 449 decision point about the completion of a set of configuration 450 tasks, or the ability to dynamically report any event that may 451 affect global service operation, 452 6. The protocol should support the appropriate security mechanisms 453 to provide guarantees as far as the preservation of the 454 confidentiality of the configuration information is concerned. 455 7. The protocol should provide a mean of preserving the order in 456 which the configuration information should be applied in the 457 participating devices. The ordering of the configuration 458 information could be implemented by means of sequence numbers, 459 timing or scheduling indicators, etc. Through this requirement, 460 any aged or disordered configuration information is prevented to 461 be applied to the devices. 463 7.1.2. Performance Requirements 465 The protocol for conveying configuration information within a network 466 should be designed so that: 468 1. The activation of the protocol by the participating devices must 469 not affect the overall performance of such devices, whatever the 470 amount of configuration data these devices will have to process 471 at any given time. 472 2. The activation of the protocol should not dramatically affect the 473 global resources of the network infrastructure that will convey 474 configuration information whatever its amount and scope (e.g., 475 the set of policies that need to be dynamically enforced). 477 7.1.3. Backward Compatibility 479 The introduction and the activation of a protocol for conveying 480 configuration information should allow for smooth migration 481 procedures, so that vendor-specific and vendor-independent 482 configuration procedures may gracefully co-exist on a (hopefully) 483 limited period of time. 485 Also, in case of any kind of protocol failure, it must be possible to 486 rely upon any vendor-specific configuration procedure as some kind of 487 rollback procedure. Such a rollback procedure must protect services 488 that are up and running from any risk of disruption. 490 7.2. Requirements for Configuration Information 492 Configuration tasks are currently performed with vendor-specific 493 solutions that reflect technology-specific information. It is 494 therefore more and more difficult for a service provider to get a 495 unified, homogeneous view of the network resources service-wise 496 (rather than device-wise). 498 Configuration information should therefore be provided to the 499 participating devices as unified, vendor-agnostic, service 500 configuration parameters. These parameters must reflect a 501 standardized service data model rather than a vendor-specific 502 information model, unlike the current situation. Examples of such 503 service data models include a tunneling service, an intra-domain 504 routing service, or a VPN service. 506 The need for a unified, homogeneous access to a multi-vendor 507 environment is becoming critical for N-Play, residential and 508 corporate, fixed and mobile service providers so that a high level of 509 automation can be introduced while proceeding with the configuration 510 of the said multi-vendor environment. This unification is clearly 511 conditioned by the availability of two key components: A 512 configuration protocol (the container) and a set of data models (the 513 content). 515 The standardization of these two components has several yet major 516 benefits: 518 o Devices are seen as functional blocks that support a set of 519 standardized capabilities; 520 o These functional blocks are described as vendor-independent 521 capabilities; 522 o These functional blocks are all managed homogeneously, whatever 523 the underlying technology. 525 As a consequence, it becomes possible to add semantic rules to 526 automate detection and correction of erroneous configurations, either 527 at the scale of a single device or at the scale of a whole network. 528 Furthermore, an equipment from vendor X could de replaced by another 529 technology from vendor Y with very little impact (if no impact at 530 all) on the configuration management procedures. 532 To do so, the data models should satisfy the following requirements. 534 7.2.1. Network Services 536 7.2.1.1. Interface Identification 538 Configuration information for identification purposes mostly deals 539 with the naming of any interface supported by a given device. This 540 naming scheme describes the properties of an interface, and must take 541 into account all the parameters that are required to correctly 542 configure an interface. The following information must be provided: 544 o A name, with a generic syntax that is vendor-agnostic by nature. 545 The name can define the media type of the interface. Depending on 546 the medium type, further information MAY be added (such as MTU, 547 bandwidth, supported framing and encapsulation modes, etc.). 548 o The interface technology (e.g., optical / electrical) and nominal 549 capacity (e.g., 10 GE / 100 GE). 550 o Optionally, a logical descriptor (e.g., VLANs declared on Ethernet 551 interfaces). In this case the encapsulation mode must be part of 552 the configuration information. 553 o Optionally, a description field that provides general (possibly 554 administrative) information about the interface. 556 7.2.1.2. Quality of Service (QoS) 558 IP services are provided with a level of quality that MAY be 559 guaranteed (either qualitatively or quantitatively) by any means 560 appropriate. QoS policies should be dynamically enforced according 561 to a data model that will accurately reflect all the elementary QoS 562 capabilities that MAY be configured and activated to enforce such 563 policies. 565 For instance, in the case of the activation of the Diffserv QoS model 566 within a network infrastructure, the participating routers should be 567 provided with the appropriate PHB (Per Hop Behavior) configuration 568 parameters. 570 Additional information relevant to the service, such as path 571 protection, can be provided to the participating devices to mitigate 572 network failures. This information can be proactively or reactively 573 provided, according to the service level agreed. 575 7.2.1.3. Applications 577 Network devices usually support functions that allow the activation 578 of specific services like HTTP, BOOTP, DHCP, SYSLOG, etc. These 579 devices must therefore be provided with the corresponding 580 configuration information. 582 7.2.2. Forwarding Services 584 7.2.2.1. Routing and Forwarding Configuration Information 586 Routing and forwarding configuration information deals with the 587 decision that should be applied by a participating device to forward 588 an incoming IP datagram, according to the (possibly service-specific) 589 forwarding and routing policies defined by the service provider. 590 From this perspective, the participating devices should be provided 591 with the following configuration information: 593 1. Metric information for IGP route computation purposes, 594 2. Attribute information for BGP route computation purposes, 595 3. Static routes (if any). 597 Any candidate protocol must be compliant with the following 598 requirements: 600 1. Ability to retrieve routing and forwarding tables. 601 2. Ability to retrieve the configuration information of each 602 routing/forwarding device. 603 3. Ability to retrieve the capabilities of each routing/forwarding 604 device. 605 4. Ability to dynamically enforce policies on active routing 606 processes. 607 5. Ability to dynamically inject new routing and forwarding entries. 608 6. Ability to receive notifications when route changes occurred, 609 tagged by the decision point. 611 7.2.2.2. Traffic Engineering Configuration Information 613 Traffic Engineering (TE) is an important and often complex task of 614 configuration management: the participating devices should be 615 provided with the configuration information that will help them to 616 select the appropriate routes that lead to a set of destinations, 617 according to specific constraints and requirements that may have been 618 dynamically negotiated with the customer. 620 These constraints may be expressed in terms of time duration (e.g., 621 the use of a traffic-engineered route on a weekly basis), traffic 622 characterization (e.g., all IP multicast traffic should be forwarded 623 along a specific distribution tree), security concerns (e.g., use 624 IPsec tunnels), and/or QoS considerations (e.g., EF (Expedited 625 Forwarding)-marked traffic [RFC3246] should always use a subset of 626 "EF-compliant" routes). 628 7.2.2.3. Configuration Information for Tunnel Design and Activation 630 7.2.2.3.1. Tunnel Identification Information 632 The identification of a tunnel should be globally unique, especially 633 if the tunnel is to be established and activated across autonomous 634 systems. The tunnel identification schemes (e.g., endpoint 635 numbering) should be left to service providers, assuming that the 636 corresponding formalism is commonly understood, whatever the number 637 of autonomous systems the tunnel may cross. 639 The tunnel identification information should at least be composed of 640 the tunnel endpoint identification information. The tunnel 641 identification information MAY also be composed of an informal 642 description of the tunnel, e.g., the purpose of its establishment, 643 customer traffic that may be forwarded into this tunnel, etc. 645 7.2.2.3.2. Tunneling Protocol Configuration Information 647 Any participating device must be provided with the configuration 648 information related to the tunneling technique to be used for the 649 establishment and the activation of the tunnel. Such techniques 650 include Generic Routing Encapsulation (GRE, [RFC2784]), IP Secure in 651 tunnel mode (IPsec, [RFC2401]), Layer 2 Tunneling Protocol (L2TP, 652 [RFC2661]), etc. 654 7.3. Global Management Requirements 656 7.3.1. Fault Management 658 Mechanisms to monitor and report any fault that affects service 659 operation should be independent of the configuration protocol. 661 7.3.2. Configuration Management 663 Errors during a configuration procedure could impact the availability 664 of a given service offering, while consistency checks are mandatory 665 so as to correctly enforce a configuration policy. 667 The following requirements have been identified: 669 o Provisioning of configuration information should be as automated 670 as possible, 672 o Mechanisms to detect and diagnose configuration errors must be 673 supported, 674 o Consistency of configuration operations service-wise must be 675 checked, 676 o Simulation tools should be used to assess the validity of 677 configuration information before it is downloaded to the relevant 678 participant devices. 679 o Autonomic provisioning capabilities should be enabled to 680 facilitate new device deployments in an automatic way, ideally 681 without any human configuration intervention. Of course, the 682 procedure must be designed to allow for administrative validation 683 under some events. The purpose of allowing for such events is to 684 ease troubleshooting and react to failures events when unexpected 685 behaviors are experienced. 686 o Means to prevent against "mad robot" phenomena should be 687 supported. 689 7.3.3. Performance Management 691 Performance management is key for guaranteeing Service Assurance by 692 proactively detecting network degradation. 694 In a vendor-agnostic scenario, the mechanisms for performance 695 management should implement standardized measurements among the 696 involved devices, represented by abstract, standard data models. 697 There are a number of measurements that can be taken into account for 698 different purposes, such as CPP validation, bandwidth utilization or 699 network and service level resilience. To that end, the performance 700 management tools should provide reporting capabilities of the 701 obtained measurements through counters or any other mean agnostic to 702 specific vendor implementations. 704 The activation (and de-activation) of the reporting capabilities MAY 705 be enabled by using automated configuration mechanisms. 707 7.4. Security Management 709 7.4.1. Device Authentication 711 It must be possible to activate mutual authentication between manager 712 and managed entities. The authentication must be checked before 713 exchanging any configuration data, so as to prevent DoS (Denial of 714 Service) attacks. 716 7.4.2. Integrity of Configuration Information 718 Two types of integrity must be provided. The first one may be done 719 at the network layer, e.g., by using the IPsec protocol suite. The 720 second type should protect configuration data at the application 721 layer (e.g., the entire file configuration is integrity protected). 723 7.4.3. Confidentiality of Exchanged Data 725 The participating device should provide security functions that 726 provide confidentiality. Encryption algorithms must be standard and 727 manually or automatically activated. 729 7.4.4. Key Management 731 The configuration system must provide a scalable key management 732 scheme. The number of keys to be managed must be at most linearly 733 proportional to the number of the devices. 735 7.4.5. Connection Log 737 The participating device must log all configuration connections. At 738 least the following information must be provided: 740 o Identity of the device which provided the configuration 741 information, 742 o Date of the connection, 743 o Identity of the user who has initiated the configuration process, 744 o Description of the configuration information that has been 745 forwarded. 747 7.4.6. Profiles 749 The configuration system must allow the definition and the activation 750 of several privilege levels. Each level could be associated to a set 751 of administrative functions. Each configuration administrator could 752 be assigned a specific access level to perform a (possibly limited) 753 set of configuration tasks. 755 8. IANA Considerations 757 This document does not require any action from IANA. 759 9. Security Considerations 761 This document reflects a set of requirements as far as the design and 762 the enforcement of configuration policies are concerned for 763 (automated) service subscription, delivery and maintenance. The 764 document addresses some security concerns that have been depicted in 765 Section 7.4, and that should be taken into account when considering 766 the specification of a protocol that will convey configuration 767 information, as well as configuration information itself. 769 10. Acknowledgements 771 Many thanks to M. Achemlal and Y. Adam who contributed to a first 772 version of this text. 774 Thanks for W. George for the comments. 776 11. Informative References 778 [I-D.boucadair-connectivity-provisioning-protocol] 779 Boucadair, M., Jacquenet, C., Zhang, D., and P. 780 Georgatsos, "Connectivity Provisioning Negotiation 781 Protocol (CPNP)", draft-boucadair-connectivity- 782 provisioning-protocol-08 (work in progress), September 783 2014. 785 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 786 Internet Protocol", RFC 2401, November 1998. 788 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 789 Schoenwaelder, Ed., "Structure of Management Information 790 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 792 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 793 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 794 RFC 2661, August 1999. 796 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 797 and A. Sastry, "The COPS (Common Open Policy Service) 798 Protocol", RFC 2748, January 2000. 800 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 801 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 802 March 2000. 804 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 805 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 806 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 807 3084, March 2001. 809 [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, 810 S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure 811 of Policy Provisioning Information (SPPI)", RFC 3159, 812 August 2001. 814 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 815 J., Courtney, W., Davari, S., Firoiu, V., and D. 816 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 817 Behavior)", RFC 3246, March 2002. 819 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 820 "Introduction and Applicability Statements for Internet- 821 Standard Management Framework", RFC 3410, December 2002. 823 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 824 Information Models and Data Models", RFC 3444, January 825 2003. 827 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 828 Monitoring", RFC 6022, October 2010. 830 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 831 Bierman, "Network Configuration Protocol (NETCONF)", RFC 832 6241, June 2011. 834 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 835 Networking: A Perspective from within a Service Provider 836 Environment", RFC 7149, March 2014. 838 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 839 Connectivity Provisioning Profile (CPP)", RFC 7297, July 840 2014. 842 Authors' Addresses 844 Mohamed Boucadair 845 France Telecom 846 Rennes 35000 847 France 849 Email: mohamed.boucadair@orange.com 850 Christian Jacquenet 851 France Telecom 852 Rennes 35000 853 France 855 Email: christian.jacquenet@orange.com 857 Luis M. Contreras 858 Telefonica I+D 859 Ronda de la Comunicacion, s/n 860 Madrid 28050 861 Spain 863 Email: lmcm@tid.es 864 URI: http://people.tid.es/LuisM.Contreras/