idnits 2.17.1 draft-sin-sdnrg-sdn-approach-07.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 22, 2013) is 3779 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 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Informational France Telecom 5 Expires: May 26, 2014 November 22, 2013 7 Software-Defined Networking: A Perspective From Within A Service 8 Provider 9 draft-sin-sdnrg-sdn-approach-07 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 26, 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. On OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.6. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.1. Implications Of Full Automation . . . . . . . . . . . . . 10 77 4.2. Bootstrapping An SDN . . . . . . . . . . . . . . . . . . 11 78 4.3. Operating An SDN . . . . . . . . . . . . . . . . . . . . 12 79 4.4. The Intelligence Resides In The PDP . . . . . . . . . . . 13 80 4.5. Simplicity And Adaptability Vs. Complexity . . . . . . . 14 81 4.6. Performance And Scalability . . . . . . . . . . . . . . . 14 82 4.7. Risk Assessment . . . . . . . . . . . . . . . . . . . . . 15 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 86 8. Informative References . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 The Internet has become the federative network that supports a wide 92 range of service offerings. The delivery of network services such as 93 IP VPNs assumes the combined activation of various capabilities that 94 include (but are not necessarily limited to) forwarding and routing 95 capabilities (e.g., customer-specific addressing scheme management, 96 dynamic path computation to reach a set of destination prefixes, 97 dynamic establishment of tunnels, etc.), quality of service 98 capabilities (e.g., traffic classification and marking, traffic 99 conditioning and scheduling), security capabilities (e.g., filters to 100 protect customer premises from network-originated attacks, to avoid 101 malformed route announcements, etc.) and management capabilities 102 (e.g., fault detection and processing). 104 As these services not only grow in variety but also in complexity, 105 their design, delivery and operation have become a complex alchemy 106 that often requires various levels of expertise. This situation is 107 further aggravated by the wide variety of (network) protocols and 108 tools, as well as recent Any Time Any-Where Any Device 109 (ATAWAD)-driven convergence trends that are meant to make sure an 110 end-user can access the whole range of services he/she has subscribed 111 to, whatever the access and device technologies, wherever the end- 112 user is connected to the network, and whether this end-user is in 113 motion or not. 115 Yet, most of these services have been deployed for the past decade, 116 primarily based upon often static service production procedures that 117 are more and more exposed to the risk of erroneous configuration 118 commands. In addition, most of these services do not assume any 119 specific negotiation between the customer and the service provider or 120 between service providers besides the typical financial terms. 122 At best, five-year master plans are referred to as the network 123 planning policy that will be enforced by the service provider, given 124 the foreseen business development perspectives, manually-computed 125 traffic forecasts and the market coverage (fixed/mobile, residential/ 126 corporate). This so-called network planning policy may very well 127 affect the way resources are allocated in a network, but clearly 128 fails to be adequately responsive to highly dynamic customer 129 requirements in an "always-on" fashion. The need for improved 130 service delivery procedures (including the time it takes to deliver 131 the service once possible negotiation phase is completed) is even 132 more critical for corporate customers. 134 In addition, various tools are used for different, sometimes service- 135 centric, management purposes but their usage is not necessarily 136 coordinated for the sake of event aggregation, correlation and 137 processing. This lack of coordination may come at the cost of extra 138 complexity and possible customer's Quality of Experience degradation. 140 Multi-service, multi-protocol, multi-technology convergent and 141 dynamically-adaptive networking environments of the near future have 142 therefore become one of the major challenges faced by service 143 providers. 145 This document aims at clarifying the SDN landscape by providing a 146 perspective on the functional taxonomy of the techniques that can be 147 used in SDN, as seen from within a service provider environment. 149 2. Introducing Software-Defined Networking 151 2.1. A Tautology? 153 The separation of the forwarding and control planes (beyond 154 implementation considerations) have almost become a gimmick to 155 promote flexibility as a key feature of the SDN approach. 156 Technically, most of current router implementations have been 157 assuming this separation for decades. Routing processes (such as IGP 158 and BGP route computation) have often been software-based, while 159 forwarding capabilities are usually implemented in hardware. 161 As such, the current state-of-the-art tends to confirm the said 162 separation, which rather falls under a tautology. 164 But a somewhat centralized, "controller-embedded", control plane for 165 the sake of optimized route computation before FIB population is 166 certainly another story. 168 2.2. On Flexibility 170 Promoters of SDN have argued that it provides additional flexibility 171 in how the network is operated. This is undoubtedly one of the key 172 objectives that must be achieved by service providers. This is 173 because the ability to dynamically adapt to a wide range of 174 customer's requests for the sake of flexible network service delivery 175 is an important competitive advantage. But flexibility is much, much 176 more than separating the control and forwarding planes to facilitate 177 forwarding decision-making processes. 179 For example, the ability to accommodate short duration extra 180 bandwidth requirements so that end users can stream a video file to 181 their 4G terminal device is an example of that flexibility that 182 several mobile operators are currently investigating. 184 From this perspective, the ability to predict the network behavior as 185 a function of the network services to be delivered is of paramount 186 importance for service providers, so that they can assess the impact 187 of introducing new services or activating additional network features 188 or enforcing a given set of (new) policies from both a financial and 189 technical standpoints. This argues in favor of investigating 190 advanced network emulation engines, which can be fed with information 191 that can be derived from [I-D.ietf-idr-ls-distribution], for example. 193 Given the rather broad scope that the flexibility wording suggests: 195 o Current SDN-labeled solutions are claimed to be flexible although 196 the notion is hardly defined. The exact characterization of what 197 flexibility actually means is yet-to-be-provided. Further work 198 needs therefore to be conducted so that flexibility can be 199 precisely defined in light of various criteria such as network 200 evolution capabilities as a function of the complexity introduced 201 by the integration of SDN techniques, seamless capabilities (i.e., 202 the ability to progressively introduce SDN-enabled devices without 203 disrupting network and service operation, etc). 204 o The exposure of programmable interfaces is not a goal per se, 205 rather a means to facilitate configuration procedures for the sake 206 of improved flexibility. 208 2.3. A Tentative Definition 210 We define Software-Defined Networking as the set of techniques used 211 to facilitate the design, the delivery and the operation of network 212 services in a deterministic, dynamic, and scalable manner. The said 213 determinism refers to the ability to completely master the various 214 components of the service delivery chain, so that the service that 215 has been delivered complies with what has been negotiated and 216 contractually defined with the customer. 218 As such, determinism implies the ability to control how network 219 services are structured, designed and delivered, and where traffic 220 should be forwarded in the network for the sake of optimized resource 221 usage. Although not explicitly reminded in the following sections of 222 the document, determinism lies beneath any action that may be taken 223 by a service provider once service parameter negotiation is 224 completed, from configuration tasks to service delivery, fulfillment 225 and assurance (see Section 2.4 below). 227 Such a definition assumes the introduction of a high level of 228 automation in the overall service delivery and operation procedures. 230 Because networking is software-driven by nature, the above definition 231 does not emphasize the claimed "Software-Defined" properties of SDN- 232 labeled solutions. 234 2.4. Functional Meta-Domains 236 SDN techniques can be classified into the following functional meta- 237 domains: 239 o Techniques for the dynamic discovery of network topology, devices 240 and capabilities, along with relevant information and data models 241 that are meant to precisely document such topology, devices and 242 their capabilities. 243 o Techniques for exposing network services and their 244 characteristics, and for dynamically negotiating the set of 245 service parameters that will be used to measure the level of 246 quality associated to the delivery of a given service or a 247 combination thereof. For example, 248 [I-D.boucadair-connectivity-provisioning-profile]) . 249 o Techniques used by service requirements-derived dynamic resource 250 allocation and policy enforcement schemes, so that networks can be 251 programmed accordingly. Decisions made to dynamically allocate 252 resources and enforce policies are typically the result of the 253 correlation of various inputs, such as the status of available 254 resources in the network at any given time, the number of customer 255 service subscription requests that need to be processed over a 256 given period of time, the traffic forecasts and the possible need 257 to trigger additional resource provisioning cycles according to a 258 typical multi-year master plan, etc. 259 o Dynamic feedback mechanisms that are meant to assess how 260 efficiently a given policy (or a set thereof) is enforced from a 261 service fulfillment and assurance perspective. 263 3. Reality Check 265 The networking ecosystem has become awfully complex and highly 266 demanding in terms of robustness, performance, scalability, 267 flexibility, agility, etc. This means in particular that service 268 providers and network operators must deal with such complexity and 269 operate networking infrastructures that can evolve easily, remain 270 scalable, guarantee robustness and availability, and are resilient 271 against denial-of-service attacks. 273 The introduction of new SDN-based networking features should 274 obviously take into account this context, especially from a cost 275 impact assessment perspective. 277 3.1. Remember The Past 279 SDN techniques are not the next big thing per se, but rather a kind 280 of rebranding of proposals that have been investigated for several 281 years, like Active or Programmable Networks. As a matter of fact, 282 some of the claimed "new" SDN features have been already implemented 283 (e.g., NMS (Network Management System), PCE (Path Computation 284 Element, [RFC4655])), and supported by vendors for quite some time. 286 Some of these features have also been standardized (e.g., DNS-based 287 routing [RFC1383] that can be seen as an illustration of separated 288 control and forwarding planes or ForCES ([RFC5810][RFC5812])). 290 Also, the Policy-Based Management framework[RFC2753] introduced in 291 the early 2000's was designed to orchestrate available resources, by 292 means of a typical Policy Decision Point (PDP) which masters advanced 293 offline traffic engineering capabilities. As such, this framework 294 has the ability to interact with in-band software modules embedded in 295 controlled devices (or not). 297 The Policy Decision Point (PDP) is where policy decisions are made. 298 PDPs use a directory service for policy repository purposes. The 299 policy repository stores the policy information that can be retrieved 300 and updated by the PDP. The PDP delivers policy rules to the Policy 301 Enforcement Point (PEP) in the form of policy-provisioning 302 information that includes configuration information. 304 The Policy Enforcement Point (PEP) is where policy decisions are 305 applied. PEPs are embedded in (network) devices, which are 306 dynamically configured based upon the policy-formatted information 307 that has been processed by the PEP. PEPs request configuration from 308 the PDP, store the configuration information in the Policy 309 Information Base (PIB), and delegate any policy decision to the PDP. 311 SDN techniques as a whole are an instantiation of the policy-based 312 network management framework. Within this context, SDN techniques 313 can be used to activate capabilities on demand, to dynamically invoke 314 network and storage resources and to operate dynamically-adaptive 315 networks according to events (e.g., alteration of the network 316 topology) and triggers (e.g., dynamic notification of a link 317 failure), etc. 319 3.2. Be Pragmatic 321 SDN approaches should be holistic, i.e., global, network-wide. It is 322 not a matter of configuring devices one by one to enforce a specific 323 forwarding policy. SDN techniques are about configuring and 324 operating a whole range of devices at the scale of the network for 325 the sake of automated service delivery 326 ([I-D.boucadair-network-automation-requirements]), from service 327 negotiation and creation (e.g., [I-D.ietf-idr-sla-exchange]) to 328 assurance and fulfillment. 330 Because the complexity of activating SDN capabilities is largely 331 hidden to the end-user and software-handled, a clear understanding of 332 the overall ecosystem is needed to figure out how to manage this 333 complexity and to what extent this hidden complexity does not have 334 side effects on network operation. 336 As an example, SDN designs that assume a central decision-making 337 entity must avoid single points of failure. They must not affect 338 packet forwarding performances either (e.g., transit delays must not 339 be impacted). 341 SDN techniques are not necessary to develop new network services per 342 se. The basic service remains (IP) connectivity that solicits 343 resources located in the network. SDN techniques can thus be seen as 344 another means to interact with network service modules and invoke 345 both connectivity and storage resources accordingly in order to meet 346 service-specific requirements. 348 By definition, SDN technique activation and operation remain limited 349 to what is supported by embedded software and hardware. One cannot 350 expect SDN techniques to support unlimited customizable features. 352 3.3. Measure Experience Against Expectations 354 Because several software modules may be controlled by external 355 entities (typically a PDP), there is a need for a means to make sure 356 that what has been delivered complies with what has been negotiated. 357 Such means belong to the set of SDN techniques. 359 These typical policy-based techniques should interact with both 360 Service Structuring engines (that are meant to expose the service 361 characteristics and to possibly negotiate those characteristics) and 362 the network to continuously assess whether the experienced network 363 behavior is compliant with the objectives set by the Service 364 Structuring engine, and which may have been dynamically negotiated 365 with the customer (e.g., as captured in a CPP 366 [I-D.boucadair-connectivity-provisioning-profile], 367 [I-D.boucadair-connectivity-provisioning-protocol]). This 368 requirement applies to several regions of a network, including: 370 1. At the interface between two adjacent IP network providers. 371 2. At the access interface between a service provider and an IP 372 network provider. 373 3. At the interface between a customer and the IP network provider. 375 Ideally, a fully automated service delivery procedure from 376 negotiation and ordering, through order processing, to delivery, 377 assurance and fulfillment, should be supported, at the cost of 378 implications that are discussed in Section 4.1. This approach also 379 assumes widely adopted standard data and information models, let 380 alone interfaces. 382 3.4. Design Carefully 384 Exposing open and programmable interfaces has a cost, from both a 385 scalability and performance standpoints. 387 Maintaining hard-coded performance optimization techniques is 388 encouraged. So is the use of interfaces that allow the direct 389 control of some engines (e.g., routing, forwarding) without requiring 390 any in-between adaptation layer (generic objects to vendor-specific 391 CLI commands for instance). Nevertheless, the use of vendor-specific 392 access means to some engines could be beneficial from a performance 393 standpoint, at the cost of increasing the complexity of configuration 394 tasks. 396 SDN techniques will have to accommodate vendor-specific components 397 anyway. Indeed, these vendor-specific features will not cease to 398 exist mainly because of the harsh competition. 400 The introduction of new functions or devices that may jeopardize 401 network flexibility should be avoided, or at least carefully 402 considered in light of possible performance and scalability impacts. 403 SDN-enabled devices will have to coexist with legacy systems. 405 One single SDN, network-wide deployment is therefore very unlikely. 406 Instead, multiple instantiations of SDN techniques will be 407 progressively deployed and adapted to various network and service 408 segments. 410 3.5. On OpenFlow 412 Empowering networking with in-band controllable modules may rely upon 413 the OpenFlow protocol, but also use other protocols to exchange 414 information between a control plane and a data plane. 416 There are indeed many other candidate protocols that can be used for 417 the same or even broader purpose (e.g., resource reservation 418 purposes). The forwarding of the configuration information can for 419 example rely upon protocols like PCEP [RFC5440], NETCONF [RFC6241], 420 COPS-PR [RFC3084], Routing Policy Specification Language (RPSL, 421 [RFC2622]), etc. 423 There is therefore no 1:1 relationship between OpenFlow and SDN. 424 Rather, OpenFlow is one of the candidate protocols to convey specific 425 configuration information towards devices. As such, OpenFlow is one 426 possible component of the global SDN toolkit. 428 3.6. Non Goals 430 There are inevitable trade-offs to be found between operating the 431 current networking ecosystem and introducing some SDN techniques, 432 possibly at the cost of introducing new technologies. Operators do 433 not have to choose between the two as both environments will have to 434 coexist. 436 In particular, the following considerations cannot justify the 437 deployment of SDN techniques: 439 o Fully flexible software implementations, because the claimed 440 flexibility remains limited by the own software and hardware 441 limitations, anyway. 442 o Fully modular implementations are difficult to achieve (because of 443 the implicit complexity) and may introduce extra effort for 444 testing, validation and troubleshooting. 445 o Fully centralized control systems that are likely to raise some 446 scalability issues. Distributed protocols and their ability to 447 react to some events (e.g., link failure) in a timely manner 448 remains a cornerstone of scalable networks. This means that SDN 449 designs can rely upon a logical representation of centralized 450 features (an abstraction layer that would support inter-PDP 451 communications, for example). 453 4. Discussion 455 4.1. Implications Of Full Automation 457 The path towards full automation is paved with numerous challenges 458 and requirements, including: 460 o Make sure automation is well implemented so as to facilitate 461 testing (including validation checks) and troubleshooting. 463 * This suggests the need for simulation tools that accurately 464 assess the impact of introducing a high level of automation in 465 the overall service delivery procedure, so as to avoid a 466 typical "mad robot" syndrome whose consequences can be serious, 467 from a control and QoS standpoints among others. 468 * This also suggests careful management of human expertise, so 469 that network operators can use robust, flexible means to 470 automate repetitive or error-prone tasks, and then build on 471 automation or stringing together multiple actions to create 472 increasingly complex tasks that require less human interaction 473 (guidance, input) to complete. 474 o Simplify and foster service delivery, assurance and fulfillment, 475 as well as network failure detection, diagnosis and root cause 476 analysis, for the sake of cost optimization: 478 * Such cost optimization relates to improved service delivery 479 times as well as optimized human expertise (see above) and 480 global, technology-agnostic, service structuring and delivery 481 procedures. In particular, the ability to inject new functions 482 in existing devices should not assume a replacement of the said 483 devices, but rather allow smart investment capitalization. 485 * This can be achieved thanks to automation, possibly based upon 486 a logically centralized view of the network infrastructure (or 487 a portion thereof), yielding the need for highly automated 488 topology, device and capabilities discovery means as well as 489 operational procedures. 490 * The main intelligence resides in the PDP, which suggests that 491 an important part of the SDN-related development effort should 492 focus on a detailed specification of the PDP function, 493 including algorithms and behavioral state machineries, based 494 upon a complete set of standardized data and information 495 models. 496 * These information models and data need to be carefully 497 structured for the sakes of efficiency and flexibility. This 498 probably suggests a set of simplified pseudo-blocks that can be 499 assembled as per the nature of the service to be delivered. 500 o Need for abstraction layers: clear interfaces between business 501 actors, between layers, let alone cross-layer considerations, etc. 503 * For the sake of various service structuring and packaging. 504 * Need for IP connectivity service exposure to customers, peers, 505 applications, content/service providers, etc. (e.g., 506 [I-D.boucadair-connectivity-provisioning-profile]). 507 * Need for solutions that accommodate IP connectivity service 508 requirements with network engineering objectives. 509 * Need for dynamically-adaptive decision-making processes, which 510 can properly operate according to a set of input data and 511 metrics, such as current resource usage and demand, traffic 512 forecasts and matrices, etc., all for the sake of highly 513 responsive dynamic resource allocation and policy enforcement 514 schemes. 515 o Better accommodate technologically heterogeneous networking 516 environments: 518 * Need for vendor-independent configuration procedures, based 519 upon the enforcement of vendor-agnostic generic policies 520 instead of vendor-specific languages. 521 * Need for tools to aid manageability and orchestrate resources. 522 * Avoid proxies and privilege direct interaction with engines 523 (e.g., routing, forwarding). 525 4.2. Bootstrapping An SDN 526 Means to dynamically discover the functional capabilities of the 527 devices that will be steered by a PDP intelligence for the sake of 528 automated network service delivery need to be provided. This is 529 indeed because the acquisition of the information related to what the 530 network is actually capable of will help structuring the PDP 531 intelligence so that policy provisioning information can be derived 532 accordingly. 534 A typical example would consist in documenting a traffic engineering 535 policy based upon the dynamic discovery of the various functions 536 supported by the network devices, as a function of the services to be 537 delivered, thus yielding the establishment of different routes 538 towards the same destination depending on the nature of the traffic, 539 the location of the functions that need to be invoked to forward such 540 traffic, etc. 542 Such dynamic discovery capability can rely upon the exchange of 543 specific information by means of an IGP or BGP between network 544 devices or between network devices and the PDP. The PDP can also 545 send unsolicited commands towards network devices to acquire the 546 description of their functional capabilities in return and derive 547 network and service topologies accordingly. 549 Likewise, means to dynamically acquire the descriptive information 550 (including the base configuration) of any network device that may 551 participate to the delivery of a given service should be provided so 552 as to help the PDP structure the services that can be delivered, as a 553 function of the available resources, their location, etc. 555 SDN-related features can be grafted into an existing network 556 infrastructure. These features may not be enabled at once, but a 557 gradual approach can be adopted instead. A typical deployment 558 example would be to use an SDN decision-making process as an 559 emulation platform that would help in making appropriate technical 560 choices before their actual deployment in the network. 562 4.3. Operating An SDN 564 From an Operations And Management (OAM) standpoint [RFC6291], running 565 an SDN-capable network raises several issues such as those listed 566 below: 568 o How do SDN service and network management blocks interact? For 569 example, how the results of the dynamic negotiation of service 570 parameters with a customer or a set thereof over a given period of 571 time will affect the PDP decision-making process related to 572 resource allocation? 574 o What should be appropriate OAM tools for SDN network operation 575 (e.g., to check PDP or PEP reachability)? 576 o How performance (expressed in terms of service delivery time, for 577 example) can be optimized when the activation of software modules 578 is controlled by an external entity (typically a PDP)? 579 o To what extent an SDN implementation eases networks manageability, 580 including service and network diagnosis? 581 o Should the "control and data plane separation" principle be 582 applied to the whole network or a portion thereof, as a function 583 of the nature of the services to be delivered or taking into 584 account the technology that is currently deployed? 585 o What is the impact on the service provider's testing procedures 586 and methodologies (that are used during validation and pre- 587 deployment phases)? Particularly, (1) how test cases will be 588 defined and executed when the activation of customized modules is 589 supported? (2) what is the methodology to assess behavior of SDN- 590 controlled devices?, (3) how test regression will be conducted?, 591 (4) what is the impact on troubleshooting practices?, etc. 592 o How do SDN techniques impact service fulfillment and assurance? 593 How the resulting behavior of SDN devices (completion of 594 configuration tasks, for example) should be assessed against what 595 has been dynamically negotiated with a customer? How to measure 596 the efficiency of dynamically-enforced policies as a function of 597 the service that has been delivered? How to measure that what has 598 been delivered is compliant with what has been negotiated? What 599 is the impact of SDN techniques on troubleshooting practice? 600 o Is there any risk to operate frozen architectures because of 601 potential interoperability issues between a controlled device and 602 a SDN controller? 603 o How does the introduction of SDN techniques affect the lifetime of 604 legacy systems? Is there any risk of (rapidly) obsoleting 605 existing technologies because of their hardware or software 606 limitations? 608 The answers to the above questions are very likely to be service 609 provider-specific, depending on their technological and business 610 environments. 612 4.4. The Intelligence Resides In The PDP 614 The proposed SDN definition in Section 2.3 assumes an intelligence 615 that may reside in the control or the management planes (or both). 616 This intelligence is typically represented by a Policy Decision Point 617 (PDP), which is one of the key functional components of the Policy- 618 Based Management framework [RFC2753]. 620 SDN networking therefore relies upon PDP functions that are capable 621 of processing various input data (traffic forecasts, outcomes of 622 negotiation between customers and service providers, resource status 623 (as depicted in appropriate information models instantiated in the 624 PIB, etc.) to make appropriate decisions. 626 The design and the operation of such PDP-based intelligence in a 627 scalable manner remains of the major areas that needs to be 628 investigated. 630 To avoid centralized design schemes, inter-PDP communication is 631 likely to be required, and corresponding issues and solutions should 632 be considered. Several PDP instances may thus be activated in a 633 given domain. Because each of these PDP instances may be responsible 634 for making decisions about the enforcement of a specific policy 635 (e.g., one PDP for QoS policy enforcement purposes, another one for 636 security policy enforcement purposes, etc.), an inter-PDP 637 communication scheme is required for the sake of global PDP 638 coordination and correlation. 640 Inter-domain PDP exchanges may also be needed for specific usages. 641 Examples of such exchanges are: (1) During the network attachment 642 phase of a node to a visited network, the PDP operated by the visited 643 network can contact the home PDP to retrieve the policies to be 644 enforced for that node. (2) Various PDPs can collaborate together in 645 order to compute inter-domain paths which satisfy a set of traffic 646 performance guarantees. 648 4.5. Simplicity And Adaptability Vs. Complexity 650 The meta functional domains introduced in Section 2.4 assume the 651 introduction of a high level of automation, from service negotiation 652 to delivery and operation. Automation is the key to simplicity, but 653 must not be seen as a magic button that would be hit by a network 654 administrator whenever a customer request has to be processed or 655 additional resources need to be allocated. 657 The need for simplicity and adaptability thanks to automated 658 procedures generally assumes some complexity that lies beneath 659 automation. 661 4.6. Performance And Scalability 663 The combination of flexibility with software inevitably raises 664 performance and scalability issues as a function of the number and 665 the nature of the services to be delivered and their associated 666 dynamics. 668 For example: Networks deployed in Data Centers (DC) and which rely 669 upon OpenFlow switches are unlikely to raise important FIB 670 scalability issues. Conversely, DC interconnect designs that aim at 671 dynamically managing Virtual Machine (VM) mobility, possibly based 672 upon the dynamic enforcement of specific QoS policies, may raise 673 scalability issues. 675 The claimed flexibility of SDN networking in the latter context will 676 have to be carefully investigated by operators. 678 4.7. Risk Assessment 680 Various risks are to be assessed such as: 682 o Evaluating the risk of depending on a controller technology rather 683 than a device technology. 684 o Evaluating the risk of operating frozen architectures because of 685 potential interoperability issues between a controller and a 686 controlled device. 687 o Assessing whether SDN-labeled solutions are likely to obsolete 688 existing technologies because of hardware limitations: from a 689 technical standpoint, the ability to dynamically provision 690 resources as a function of the services to be delivered may be 691 incompatible with legacy routing systems because of their hardware 692 limitations, for example. Likewise, from an economical 693 standpoint, the use of SDN solutions for the sakes of flexibility 694 and automation may dramatically impact CAPEX (Capital Expenditure) 695 and OPEX (Operational Expenditure) budgets. 696 o Etc. 698 5. IANA Considerations 700 This document does not require any action from IANA. 702 6. Security Considerations 704 Security is an important aspect of any SDN design, because it 705 conditions the robustness and reliability of the interactions between 706 network and applications people, for the sake of efficient access 707 control procedures and optimized protection of SDN resources against 708 any kind of attack. In particular, SDN security policies should make 709 sure that SDN resources are properly safeguarded against actions that 710 may jeopardize network or application operations 711 [I-D.hartman-sdnsec-requirements]. 713 In particular, service providers should define procedures to assess 714 the reliability of software modules embedded in SDN nodes. Such 715 procedures should include means to also assess the behavior of 716 software components (under stress conditions), detect any exploitable 717 vulnerability, reliably proceed with software upgrades, etc. These 718 security guards should be activated during initial SDN node 719 deployment and activation, but also during SDN operation that implies 720 software upgrade procedures. 722 Although these procedures may not be SDN-specific (e.g., operators 723 are familiar with firmware updates with or without service 724 disruption), it is worth challenging existing practice in light of 725 SDN deployment and operation. 727 Likewise, PEP-PDP interactions suggest the need to make sure that (1) 728 a PDP is entitled to solicit PEPs so that they can apply the 729 decisions made by the said PDP, (2) a PEP is entitled to solicit a 730 PDP for whatever reason (request for additional configuration 731 information, notification about the results of a set of configuration 732 tasks, etc.), (3) a PEP can accept decisions made by a PDP and (4) 733 communication between PDPs within a domain or between domains is 734 properly secured (e.g., make sure a pair of PDPs are entitled to 735 communicate with each other, make sure the confidentiality of the 736 information exchanged between two PDPs can be preserved, etc.). 738 7. Acknowledgements 740 Many thanks to R. Barnes, S. Bryant, S. Dawkins, A. Farrel, S. 741 Farrell, W. George, J. Halpern, D. King, J. Hadi Salim, and T. Tsou 742 for their comments. Special thanks to P. Georgatos for the fruitful 743 discussions on SDNI (SDN Interconnection) in particular. 745 8. Informative References 747 [I-D.boucadair-connectivity-provisioning-profile] 748 Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 749 Connectivity Provisioning Profile", draft-boucadair- 750 connectivity-provisioning-profile-02 (work in progress), 751 September 2012. 753 [I-D.boucadair-connectivity-provisioning-protocol] 754 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 755 Negotiation Protocol (CPNP)", draft-boucadair- 756 connectivity-provisioning-protocol-01 (work in progress), 757 October 2013. 759 [I-D.boucadair-network-automation-requirements] 760 Boucadair, M. and C. Jacquenet, "Requirements for 761 Automated (Configuration) Management", draft-boucadair- 762 network-automation-requirements-01 (work in progress), 763 June 2013. 765 [I-D.hartman-sdnsec-requirements] 766 Hartman, S. and D. Zhang, "Security Requirements in the 767 Software Defined Networking Model", draft-hartman-sdnsec- 768 requirements-01 (work in progress), April 2013. 770 [I-D.ietf-idr-ls-distribution] 771 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 772 Ray, "North-Bound Distribution of Link-State and TE 773 Information using BGP", draft-ietf-idr-ls-distribution-04 774 (work in progress), November 2013. 776 [I-D.ietf-idr-sla-exchange] 777 Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. 778 Boucadair, "Inter-domain SLA Exchange", draft-ietf-idr- 779 sla-exchange-02 (work in progress), November 2013. 781 [RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 782 1383, December 1992. 784 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 785 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 786 "Routing Policy Specification Language (RPSL)", RFC 2622, 787 June 1999. 789 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 790 for Policy-based Admission Control", RFC 2753, January 791 2000. 793 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 794 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 795 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 796 3084, March 2001. 798 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 799 Element (PCE)-Based Architecture", RFC 4655, August 2006. 801 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 802 (PCE) Communication Protocol (PCEP)", RFC 5440, March 803 2009. 805 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 806 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 807 Control Element Separation (ForCES) Protocol 808 Specification", RFC 5810, March 2010. 810 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 811 Element Separation (ForCES) Forwarding Element Model", RFC 812 5812, March 2010. 814 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 815 Bierman, "Network Configuration Protocol (NETCONF)", RFC 816 6241, June 2011. 818 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 819 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 820 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 822 Authors' Addresses 824 Mohamed Boucadair 825 France Telecom 826 Rennes 35000 827 France 829 Email: mohamed.boucadair@orange.com 831 Christian Jacquenet 832 France Telecom 833 Rennes 834 France 836 Email: christian.jacquenet@orange.com