idnits 2.17.1 draft-sin-sdnrg-sdn-approach-06.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 (November 20, 2013) is 3810 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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-01 == Outdated reference: A later version (-05) exists of draft-boucadair-network-automation-requirements-01 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-04 == Outdated reference: A later version (-13) exists of draft-ietf-idr-sla-exchange-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: May 24, 2014 November 20, 2013 7 Software-Defined Networking: A Perspective From Within A Service 8 Provider 9 draft-sin-sdnrg-sdn-approach-06 11 Abstract 13 Software-Defined Networking (SDN) has been one of the major buzz 14 words of the networking industry for the past couple of years. And 15 yet, no clear definition of what SDN actually covers has been broadly 16 admitted so far. This document aims at contributing to the 17 clarification of the SDN landscape by providing a perspective on 18 requirements, issues and other considerations about SDN, as seen from 19 within a service provider environment. 21 It is not meant to endlessly discuss what SDN truly means, but rather 22 to suggest a functional taxonomy of the techniques that can be used 23 under a SDN umbrella and to elaborate on the various pending issues 24 the combined activation of such techniques inevitably raises. As 25 such, a definition of SDN is only mentioned for the sake of 26 clarification. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Introducing Software-Defined Networking . . . . . . . . . . . 4 64 2.1. A Tautology? . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. On Flexibility . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. A Tentative Definition . . . . . . . . . . . . . . . . . 5 67 2.4. Functional Meta-Domains . . . . . . . . . . . . . . . . . 5 68 3. Reality Check . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Remember The Past . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Be Pragmatic . . . . . . . . . . . . . . . . . . . . . . 7 71 3.3. Measure Experience Against Expectations . . . . . . . . . 8 72 3.4. Design Carefully . . . . . . . . . . . . . . . . . . . . 8 73 3.5. There Is Life Beyond OpenFlow . . . . . . . . . . . . . . 9 74 3.6. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.1. Implications Of Full Automation . . . . . . . . . . . . . 10 77 4.2. Bootstrapping An SDN . . . . . . . . . . . . . . . . . . 12 78 4.3. The Intelligence Resides In The PDP . . . . . . . . . . . 12 79 4.4. Simplicity And Adaptability Vs. Complexity . . . . . . . 13 80 4.5. Performance And Scalability . . . . . . . . . . . . . . . 13 81 4.6. Risk Assessment . . . . . . . . . . . . . . . . . . . . . 14 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 8. Informative References . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 The Internet has become the federative network that supports a wide 91 range of service offerings. The delivery of network services such as 92 IP VPNs assumes the combined activation of various capabilities that 93 include (but are not necessarily limited to) forwarding and routing 94 capabilities (e.g., customer-specific addressing scheme management, 95 dynamic path computation to reach a set of destination prefixes, 96 dynamic establishment of tunnels, etc.), quality of service 97 capabilities (e.g., traffic classification and marking, traffic 98 conditioning and scheduling), security capabilities (e.g., filters to 99 protect customer premises from network-originated attacks, to avoid 100 malformed route announcements, etc.) and management capabilities 101 (e.g., fault detection and processing). 103 As these services not only grow in variety but also in complexity, 104 their design, delivery and operation have become a complex alchemy 105 that often requires various levels of expertise. This situation is 106 further aggravated by the wide variety of (network) protocols and 107 tools, as well as recent Any Time Any-Where Any Device 108 (ATAWAD)-driven convergence trends that are meant to make sure an 109 end-user can access the whole range of services he/she has subscribed 110 to, whatever the access and device technologies, wherever the end- 111 user is connected to the network, and whether this end-user is in 112 motion or not. 114 Yet, most of these services have been deployed for the past decade, 115 primarily based upon often static service production procedures that 116 are more and more exposed to the risk of erroneous configuration 117 commands. In addition, most of these services do not assume any 118 specific negotiation between the customer and the service provider or 119 between service providers besides the typical financial terms. 121 At best, five-year master plans are referred to as the network 122 planning policy that will be enforced by the service provider, given 123 the foreseen business development perspectives, manually-computed 124 traffic forecasts and the market coverage (fixed/mobile, residential/ 125 corporate). This so-called network planning policy may very well 126 affect the way resources are allocated in a network, but clearly 127 fails to be adequately responsive to highly dynamic customer 128 requirements in an "always-on" fashion. The need for improved 129 service delivery procedures (including the time it takes to deliver 130 the service once possible negotiation phase is completed) is even 131 more critical for corporate customers. 133 In addition, various tools are used for different, sometimes service- 134 centric, management purposes but their usage is not necessarily 135 coordinated for the sake of event aggregation, correlation and 136 processing. This lack of coordination may come at the cost of extra 137 complexity and possible customer's Quality of Experience degradation. 139 Multi-service, multi-protocol, multi-technology convergent and 140 dynamically-adaptive networking environments of the near future have 141 therefore become one of the major challenges faced by service 142 providers. 144 This document aims at clarifying the SDN landscape by providing a 145 perspective on the functional taxonomy of the techniques that can be 146 used in SDN, as seen from within a service provider environment. 148 2. Introducing Software-Defined Networking 150 2.1. A Tautology? 152 The separation of the forwarding and control planes (beyond 153 implementation considerations) have almost become a gimmick to 154 promote flexibility as a key feature of the SDN approach. 155 Technically, most of current router implementations have been 156 assuming this separation for decades. Routing processes (such as IGP 157 and BGP route computation) have often been software-based, while 158 forwarding capabilities are usually implemented in hardware. 160 As such, the current state-of-the-art tends to confirm the said 161 separation, which rather falls under a tautology. 163 But a somewhat centralized, "controller-embedded", control plane for 164 the sake of optimized route computation before FIB population is 165 certainly another story. 167 2.2. On Flexibility 169 Promoters of SDN have argued that it provides additional flexibility 170 in how the network is operated. This is undoubtedly one of the key 171 objectives that must be achieved by service providers. This is 172 because the ability to dynamically adapt to a wide range of 173 customer's requests for the sake of flexible network service delivery 174 is an important competitive advantage. But flexibility is much, much 175 more than separating the control and forwarding planes to facilitate 176 forwarding decision-making processes. 178 For example, the ability to accommodate short duration extra 179 bandwidth requirements so that end users can stream a video file to 180 their 4G terminal device is an example of that flexibility that 181 several mobile operators are currently investigating. 183 From this perspective, the ability to predict the network behavior as 184 a function of the network services to be delivered is of paramount 185 importance for service providers, so that they can assess the impact 186 of introducing new services or activating additional network features 187 or enforcing a given set of (new) policies from both a financial and 188 technical standpoints. This argues in favor of investigating 189 advanced network emulation engines, which can be fed with information 190 that can be derived from [I-D.ietf-idr-ls-distribution], for example. 192 Given the rather broad scope that the flexibility wording suggests: 194 o The exact characterization of what flexibility actually means is 195 still required. 196 o The exposure of programmable interfaces is not a goal per se, 197 rather a means to facilitate configuration procedures for the sake 198 of improved flexibility. 200 2.3. A Tentative Definition 202 We define Software-Defined Networking as the set of techniques used 203 to facilitate the design, the delivery and the operation of network 204 services in a deterministic, dynamic, and scalable manner. The said 205 determinism refers to the ability to completely master the various 206 components of the service delivery chain, so that the service that 207 has been delivered complies with what has been negotiated and 208 contractually defined with the customer. 210 As such, determinism implies the ability to control how network 211 services are structured, designed and delivered, and where traffic 212 should be forwarded in the network for the sake of optimized resource 213 usage. Although not explicitly reminded in the following sections of 214 the document, determinism lies beneath any action that may be taken 215 by a service provider once service parameter negotiation is 216 completed, from configuration tasks to service delivery, fulfillment 217 and assurance (see Section 2.4 below). 219 Such a definition assumes the introduction of a high level of 220 automation in the overall service delivery and operation procedures. 222 Because networking is software-driven by nature, the above definition 223 does not emphasize the claimed "Software-Defined" properties of SDN- 224 labeled solutions. 226 2.4. Functional Meta-Domains 228 SDN techniques can be classified into the following functional meta- 229 domains: 231 o Techniques for the dynamic discovery of network topology, devices 232 and capabilities, along with relevant information and data models 233 that are meant to precisely document such topology, devices and 234 capabilities. 236 o Techniques for exposing network services and their 237 characteristics, and for dynamically negotiating the set of 238 service parameters that will be used to measure the level of 239 quality associated to the delivery of a given service or a 240 combination thereof. For example, 241 [I-D.boucadair-connectivity-provisioning-profile]) . 242 o Techniques used by service requirements-derived dynamic resource 243 allocation and policy enforcement schemes, so that networks can be 244 programmed accordingly. Decisions made to dynamically allocate 245 resources and enforce policies are typically the result of the 246 correlation of various inputs, such as the status of available 247 resources in the network at any given time, the number of customer 248 service subscription requests that need to be processed over a 249 given period of time, the traffic forecasts and the possible need 250 to trigger additional resource provisioning cycles according to a 251 typical multi-year master plan, etc. 252 o Dynamic feedback mechanisms that are meant to assess how 253 efficiently a given policy (or a set thereof) is enforced from a 254 service fulfillment and assurance perspective. 256 3. Reality Check 258 The networking ecosystem has become awfully complex and highly 259 demanding in terms of robustness, performance, scalability, 260 flexibility, agility, etc. This means in particular that service 261 providers and network operators must deal with such complexity and 262 operate networking infrastructures that can evolve easily, remain 263 scalable, guarantee robustness and availability, and are resilient 264 against denial-of-service attacks. 266 The introduction of new SDN-based networking features should 267 obviously take into account this context, especially from a cost 268 impact assessment perspective. 270 3.1. Remember The Past 272 SDN techniques are not the next big thing per se, but rather a kind 273 of rebranding of proposals that have been investigated for several 274 years, like Active or Programmable Networks. As a matter of fact, 275 some of the claimed "new" SDN features have been already implemented 276 (e.g., NMS (Network Management System), PCE (Path Computation 277 Element, [RFC4655])), and supported by vendors for quite some time 278 (references can be added if needed). 280 Some of these features have also been standardized (e.g., DNS-based 281 routing [RFC1383] that can be seen as an illustration of separated 282 control and forwarding planes or ForCES ([RFC5810][RFC5812])). 284 Also, the Policy-Based Management framework[RFC2753] introduced in 285 the early 2000's was designed to orchestrate available resources, by 286 means of a typical Policy Decision Point (PDP) which masters advanced 287 offline traffic engineering capabilities. As such, this framework 288 has the ability to interact with in-band software modules embedded in 289 controlled devices (or not). 291 The Policy Decision Point (PDP) is where policy decisions are made. 292 PDPs use a directory service for policy repository purposes. The 293 policy repository stores the policy information that can be retrieved 294 and updated by the PDP. The PDP delivers policy rules to the Policy 295 Enforcement Point (PEP) in the form of policy-provisioning 296 information that includes configuration information. 298 The Policy Enforcement Point (PEP) is where policy decisions are 299 applied. PEPs are embedded in (network) devices, which are 300 dynamically configured based upon the policy-formatted information 301 that has been processed by the PEP. PEPs request configuration from 302 the PDP, store the configuration information in the Policy 303 Information Base (PIB), and delegate any policy decision to the PDP. 305 SDN techniques as a whole are an instantiation of the policy-based 306 network management framework. Within this context, SDN techniques 307 can be used to activate capabilities on demand, to dynamically invoke 308 network and storage resources and to operate dynamically-adaptive 309 networks according to events (e.g., alteration of the network 310 topology) and triggers (e.g., dynamic notification of a link 311 failure), etc. 313 3.2. Be Pragmatic 315 SDN approaches should be holistic, i.e., global, network-wide. It is 316 not a matter of configuring devices one by one to enforce a specific 317 forwarding policy. SDN techniques are about configuring and 318 operating a whole range of devices at the scale of the network for 319 the sake of automated service delivery 320 ([I-D.boucadair-network-automation-requirements]), from service 321 negotiation and creation (e.g., [I-D.ietf-idr-sla-exchange]) to 322 assurance and fulfillment. 324 Because the complexity of activating SDN capabilities is largely 325 hidden to the end-user and software-handled, a clear understanding of 326 the overall ecosystem is needed to figure out how to manage this 327 complexity and to what extent this hidden complexity does not have 328 side effects on network operation. 330 As an example, SDN designs that assume a central decision-making 331 entity must avoid single points of failure. They must not affect 332 packet forwarding performances either (e.g., transit delays must not 333 be impacted). 335 SDN techniques are not necessary to develop new network services per 336 se. The basic service remains (IP) connectivity that solicits 337 resources located in the network. SDN techniques can thus be seen as 338 another means to interact with network service modules and invoke 339 both connectivity and storage resources accordingly in order to meet 340 service-specific requirements. 342 By definition, SDN technique activation and operation remain limited 343 to what is supported by embedded software and hardware. One cannot 344 expect SDN techniques to support unlimited customizable features. 346 3.3. Measure Experience Against Expectations 348 Because several software modules may be controlled by external 349 entities, there is a need for a means to make sure that what has been 350 delivered complies with what has been negotiated. Such means belong 351 to the set of SDN techniques. 353 These typical policy-based techniques should interact with both 354 Service Structuring engines (that are meant to expose the service 355 characteristics and to possibly negotiate those characteristics) and 356 the network to continuously assess whether the experienced network 357 behavior is compliant with the objectives set by the Service 358 Structuring engine, and which may have been dynamically negotiated 359 with the customer (e.g., as captured in a CPP 360 [I-D.boucadair-connectivity-provisioning-profile], 361 [I-D.boucadair-connectivity-provisioning-protocol]). This 362 requirement applies to several regions of a network, including: 364 1. At the interface between two adjacent IP network providers. 365 2. At the access interface between a service provider and an IP 366 network provider. 367 3. At the interface between a customer and the IP network provider. 369 Ideally, a fully automated service delivery procedure from 370 negotiation and ordering, through order processing, to delivery, 371 assurance and fulfillment, should be supported, at the cost of 372 implications that are discussed in Section 4.1. This approach also 373 assumes widely adopted standard data and information models, let 374 alone interfaces. 376 3.4. Design Carefully 378 Exposing open and programmable interfaces has a cost, from both a 379 scalability and performance standpoints. 381 Maintaining hard-coded performance optimization techniques is 382 encouraged. So is the use of interfaces that allow the direct 383 control of some engines (e.g., routing, forwarding) without requiring 384 any in-between adaptation layer (generic objects to vendor-specific 385 CLI commands for instance). Nevertheless, the use of vendor-specific 386 access means to some engines could be beneficial from a performance 387 standpoint, at the cost of increasing the complexity of configuration 388 tasks. 390 SDN techniques will have to accommodate vendor-specific components 391 anyway. Indeed, these vendor-specific features will not cease to 392 exist mainly because of the harsh competition. 394 The introduction of new functions or devices that may jeopardize 395 network flexibility should be avoided, or at least carefully 396 considered in light of possible performance and scalability impacts. 397 SDN-enabled devices will have to coexist with legacy systems. 399 One single SDN, network-wide deployment is therefore very unlikely. 400 Instead, multiple instantiations of SDN techniques will be 401 progressively deployed and adapted to various network and service 402 segments. 404 3.5. There Is Life Beyond OpenFlow 406 Empowering networking with in-band controllable modules does not 407 necessarily mean the use of the OpenFlow protocol, which is just 408 another protocol that helps devices populate their forwarding tables 409 according to a set of instructions. 411 OpenFlow is certainly not the "next big thing": there are many, many 412 other candidate protocols that can be used for the same or even 413 broader purposes (e.g., resource reservation purposes). The 414 forwarding of the configuration information can indeed rely upon a 415 variety of protocols that include (but is not necessarily limited to) 416 PCEP [RFC5440], NETCONF [RFC6241], COPS-PR [RFC3084], Routing Policy 417 Specification Language (RPSL, [RFC2622]), etc. 419 There is therefore no 1:1 relationship between OpenFlow and SDN. 420 Rather, OpenFlow is one of the candidate protocols to convey specific 421 configuration information towards devices. As such, OpenFlow is one 422 possible component of the global SDN toolkit. 424 3.6. Non Goals 426 There are inevitable trade-offs to be found between operating the 427 current networking ecosystem and introducing some SDN techniques, 428 possibly at the cost of introducing new technologies. Operators do 429 not have to choose between the two as both environments will have to 430 coexist. 432 In particular, the following considerations cannot justify the 433 deployment of SDN techniques: 435 o Fully flexible software implementations, because the claimed 436 flexibility remains limited by the own software and hardware 437 limitations, anyway. 438 o Fully modular implementations are difficult to achieve (because of 439 the implicit complexity) and may introduce extra effort for 440 testing, validation and troubleshooting. 441 o Fully centralized control systems that are likely to raise some 442 scalability issues. Distributed protocols and their ability to 443 react to some events (e.g., link failure) in a timely manner 444 remains a cornerstone of scalable networks. This means that SDN 445 designs can rely upon a logical representation of centralized 446 features (an abstraction layer that would support inter-PDP 447 communications, for example). 449 4. Discussion 451 4.1. Implications Of Full Automation 453 The path towards full automation is paved with numerous challenges 454 and requirements, including: 456 o Make sure automation is well implemented so as to facilitate 457 testing (including validation checks) and troubleshooting. 459 * This suggests the need for simulation tools that accurately 460 assess the impact of introducing a high level of automation in 461 the overall service delivery procedure, so as to avoid a 462 typical "mad robot" syndrome whose consequences can be serious, 463 from a control and QoS standpoints among others. 464 * This also suggests careful management of human expertise, so 465 that network operators can use robust, flexible means to 466 automate repetitive or error-prone tasks, and then build on 467 automation or stringing together multiple actions to create 468 increasingly complex tasks that require less human interaction 469 (guidance, input) to complete. 471 o Simplify and foster service delivery, assurance and fulfillment, 472 as well as network failure detection, diagnosis and root cause 473 analysis, for the sake of cost optimization: 475 * Such cost optimization relates to improved service delivery 476 times as well as optimized human expertise (see above) and 477 global, technology-agnostic, service structuring and delivery 478 procedures. In particular, the ability to inject new functions 479 in existing devices should not assume a replacement of the said 480 devices, but rather allow smart investment capitalization. 481 * This can be achieved thanks to automation, possibly based upon 482 a logically centralized view of the network infrastructure (or 483 a portion thereof), yielding the need for highly automated 484 topology, device and capabilities discovery means as well as 485 operational procedures. 486 * The main intelligence resides in the PDP, which suggests that 487 an important part of the SDN-related development effort should 488 focus on a detailed specification of the PDP function, 489 including algorithms and behavioral state machineries, based 490 upon a complete set of standardized data and information 491 models. 492 * These information models and data need to be carefully 493 structured for the sakes of efficiency and flexibility. This 494 probably suggests a set of simplified pseudo-blocks that can be 495 assembled as per the nature of the service to be delivered. 496 o Need for abstraction layers: clear interfaces between business 497 actors, between layers, let alone cross-layer considerations, etc. 499 * For the sake of various service structuring and packaging. 500 * Need for IP connectivity service exposure to customers, peers, 501 applications, content/service providers, etc. (e.g., 502 [I-D.boucadair-connectivity-provisioning-profile]). 503 * Need for solutions that accommodate IP connectivity service 504 requirements with network engineering objectives. 505 * Need for dynamically-adaptive decision-making processes, which 506 can properly operate according to a set of input data and 507 metrics, such as current resource usage and demand, traffic 508 forecasts and matrices, etc., all for the sake of highly 509 responsive dynamic resource allocation and policy enforcement 510 schemes. 511 o Better accommodate technologically heterogeneous networking 512 environments: 514 * Need for vendor-independent configuration procedures, based 515 upon the enforcement of vendor-agnostic generic policies 516 instead of vendor-specific languages. 517 * Need for tools to aid manageability and orchestrate resources. 519 * Avoid proxies and privilege direct interaction with engines 520 (e.g., routing, forwarding). 522 4.2. Bootstrapping An SDN 524 Means to dynamically discover the functional capabilities of the 525 devices that will be steered by a PDP intelligence for the sake of 526 automated network service delivery need to be provided. This is 527 indeed because the acquisition of the information related to what the 528 network is actually capable of will help structuring the PDP 529 intelligence so that policy provisioning information can be derived 530 accordingly. 532 A typical example would consist in documenting a traffic engineering 533 policy based upon the dynamic discovery of the various functions 534 supported by the network devices, as a function of the services to be 535 delivered, thus yielding the establishment of different routes 536 towards the same destination depending on the nature of the traffic, 537 the location of the functions that need to be invoked to forward such 538 traffic, etc. 540 Likewise, means to dynamically acquire the descriptive information 541 (including the base configuration) of any network device that may 542 participate to the delivery of a given service should be provided so 543 as to help the PDP structure the services that can be delivered, as a 544 function of the available resources, their location, etc. 546 SDN-related features can be grafted into an existing network 547 infrastructure. These features may not be enabled at once, but a 548 gradual approach can rather be adopted. A typical deployment example 549 would be to use an SDN decision-making process as an emulation 550 platform that would help in making appropriate technical choices 551 before their actual deployment in the network. 553 4.3. The Intelligence Resides In The PDP 555 The proposed SDN definition in Section 2.3 assumes an intelligence 556 that may reside in the control or the management planes (or both). 557 This intelligence is typically represented by a Policy Decision Point 558 (PDP), which is one of the key functional components of the Policy- 559 Based Management framework [RFC2753]. 561 SDN networking therefore relies upon PDP functions that are capable 562 of processing various input data (traffic forecasts, outcomes of 563 negotiation between customers and service providers, resource status 564 (as depicted in appropriate information models instantiated in the 565 PIB, etc.) to make appropriate decisions. 567 The design and the operation of such PDP-based intelligence in a 568 scalable manner remains of the major areas that needs to be 569 investigated. 571 To avoid centralized design schemes, inter-PDP communication is 572 likely to be required, and corresponding issues and solutions should 573 be considered. Several PDP instances may thus be activated in a 574 given domain. Because each of these PDP instances may be responsible 575 for making decisions about the enforcement of a specific policy 576 (e.g., one PDP for QoS policy enforcement purposes, another one for 577 security policy enforcement purposes, etc.), an inter-PDP 578 communication scheme is required for the sake of global PDP 579 coordination and correlation. 581 Inter-domain PDP exchanges may also be needed for specific usages. 582 Examples of such exchanges are: (1) During the network attachment 583 phase of a node to a visited network, the PDP operated by the visited 584 network can contact the home PDP to retrieve the policies to be 585 enforced for that node. (2) Various PDPs can collaborate together in 586 order to compute inter-domain paths which satisfy a set of traffic 587 performance guarantees. 589 4.4. Simplicity And Adaptability Vs. Complexity 591 The meta functional domains introduced in Section 2.4 assume the 592 introduction of a high level of automation, from service negotiation 593 to delivery and operation. Automation is the key to simplicity, but 594 must not be seen as a magic button that would be hit by a network 595 administrator whenever a customer request has to be processed or 596 additional resources need to be allocated. 598 The need for simplicity and adaptability thanks to automated 599 procedures generally assumes some complexity that lies beneath 600 automation. 602 4.5. Performance And Scalability 604 The combination of flexibility with software inevitably raises 605 performance and scalability issues as a function of the number and 606 the nature of the services to be delivered and their associated 607 dynamics. 609 For example: Networks deployed in Data Centers (DC) and which rely 610 upon OpenFlow switches are unlikely to raise important FIB 611 scalability issues. Conversely, DC interconnect designs that aim at 612 dynamically managing Virtual Machine (VM) mobility, possibly based 613 upon the dynamic enforcement of specific QoS policies, may raise 614 scalability issues. 616 The claimed flexibility of SDN networking in the latter context will 617 have to be carefully investigated by operators. 619 4.6. Risk Assessment 621 Various risks are to be assessed such as: 623 o Evaluating the risk of depending on a controller technology rather 624 than a device technology. 625 o Evaluating the risk of operating frozen architectures because of 626 potential interoperability issues between a controller and a 627 controlled device. 628 o Assessing whether SDN-labeled solutions are likely to obsolete 629 existing technologies because of hardware limitations: from a 630 technical standpoint, the ability to dynamically provision 631 resources as a function of the services to be delivered may be 632 incompatible with legacy routing systems because of their hardware 633 limitations, for example. Likewise, from an economical 634 standpoint, the use of SDN solutions for the sakes of flexibility 635 and automation may dramatically impact CAPEX (Capital Expenditure) 636 and OPEX (Operational Expenditure) budgets. 637 o Etc. 639 5. IANA Considerations 641 This document does not require any action from IANA. 643 6. Security Considerations 645 Security has to be a first-class part of any SDN design, thus giving 646 both network and applications people the control to ensure that the 647 other has access to the info and controls that they need (but no 648 more), and to ensure that they are properly safeguarded against 649 taking actions that will adversely affect the network or application 650 as a whole [I-D.hartman-sdnsec-requirements]. 652 Likewise, PEP-PDP interactions suggest the need to make sure that (1) 653 A PDP is entitled to solicit PEPs so that they can apply the 654 decisions made by the said PDP, (2) A PEP is entitled to solicit a 655 PDP for whatever reason (request for additional configuration 656 information, notification about the results of a set of configuration 657 tasks, etc.), and (3) communication between PDPs within a domain or 658 between domains is properly secured (e.g., make sure a pair of PDPs 659 are entitled to communicate with each other, make sure the 660 confidentiality of the information exchanged between two PDPs can be 661 preserved, etc.). 663 7. Acknowledgements 665 Many thanks to A. Farrel, W. George, J. Halpern, D. King, J. Hadi 666 Salim, and T. Tsou for their comments. Special thanks to P. 667 Georgatos for the fruitful discussions on SDNI (SDN Interconnection) 668 in particular. 670 8. Informative References 672 [I-D.boucadair-connectivity-provisioning-profile] 673 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 674 Connectivity Provisioning Profile", draft-boucadair- 675 connectivity-provisioning-profile-02 (work in progress), 676 September 2012. 678 [I-D.boucadair-connectivity-provisioning-protocol] 679 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 680 Negotiation Protocol (CPNP)", draft-boucadair- 681 connectivity-provisioning-protocol-01 (work in progress), 682 October 2013. 684 [I-D.boucadair-network-automation-requirements] 685 Boucadair, M. and C. Jacquenet, "Requirements for 686 Automated (Configuration) Management", draft-boucadair- 687 network-automation-requirements-01 (work in progress), 688 June 2013. 690 [I-D.hartman-sdnsec-requirements] 691 Hartman, S. and D. Zhang, "Security Requirements in the 692 Software Defined Networking Model", draft-hartman-sdnsec- 693 requirements-01 (work in progress), April 2013. 695 [I-D.ietf-idr-ls-distribution] 696 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 697 Ray, "North-Bound Distribution of Link-State and TE 698 Information using BGP", draft-ietf-idr-ls-distribution-04 699 (work in progress), November 2013. 701 [I-D.ietf-idr-sla-exchange] 702 Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. 703 Boucadair, "Inter-domain SLA Exchange", draft-ietf-idr- 704 sla-exchange-02 (work in progress), November 2013. 706 [RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 707 1383, December 1992. 709 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 710 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 711 "Routing Policy Specification Language (RPSL)", RFC 2622, 712 June 1999. 714 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 715 for Policy-based Admission Control", RFC 2753, January 716 2000. 718 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 719 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 720 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 721 3084, March 2001. 723 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 724 Element (PCE)-Based Architecture", RFC 4655, August 2006. 726 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 727 (PCE) Communication Protocol (PCEP)", RFC 5440, March 728 2009. 730 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 731 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 732 Control Element Separation (ForCES) Protocol 733 Specification", RFC 5810, March 2010. 735 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 736 Element Separation (ForCES) Forwarding Element Model", RFC 737 5812, March 2010. 739 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 740 Bierman, "Network Configuration Protocol (NETCONF)", RFC 741 6241, June 2011. 743 Authors' Addresses 745 Mohamed Boucadair 746 France Telecom 747 Rennes 35000 748 France 750 Email: mohamed.boucadair@orange.com 752 Christian Jacquenet 753 France Telecom 754 Rennes 755 France 757 Email: christian.jacquenet@orange.com