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