doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7149.txt b/doc/rfc/rfc7149.txt
new file mode 100644
index 0000000..52d12a0
--- /dev/null
+++ b/doc/rfc/rfc7149.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Boucadair
+Request for Comments: 7149                                  C. Jacquenet
+Category: Informational                                   France Telecom
+ISSN: 2070-1721                                               March 2014
+
+
+            Software-Defined Networking: A Perspective from
+                 within a Service Provider Environment
+
+Abstract
+
+   Software-Defined Networking (SDN) has been one of the major buzz
+   words of the networking industry for the past couple of years.  And
+   yet, no clear definition of what SDN actually covers has been broadly
+   admitted so far.  This document aims to clarify the SDN landscape by
+   providing a perspective on requirements, issues, and other
+   considerations about SDN, as seen from within a service provider
+   environment.
+
+   It is not meant to endlessly discuss what SDN truly means but rather
+   to suggest a functional taxonomy of the techniques that can be used
+   under an SDN umbrella and to elaborate on the various pending issues
+   the combined activation of such techniques inevitably raises.  As
+   such, a definition of SDN is only mentioned for the sake of
+   clarification.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7149.
+
+
+
+
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 1]
+
+RFC 7149                         On SDN                       March 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Introducing Software-Defined Networking .........................4
+      2.1. A Tautology? ...............................................4
+      2.2. On Flexibility .............................................4
+      2.3. A Tentative Definition .....................................5
+      2.4. Functional Metadomains .....................................6
+   3. Reality Check ...................................................6
+      3.1. Remember the Past ..........................................7
+      3.2. Be Pragmatic ...............................................8
+      3.3. Measure Experience against Expectations ....................8
+      3.4. Design Carefully ...........................................9
+      3.5. On OpenFlow ................................................9
+      3.6. Non-goals .................................................10
+   4. Discussion .....................................................11
+      4.1. Implications of Full Automation ...........................11
+      4.2. Bootstrapping an SDN ......................................12
+      4.3. Operating an SDN ..........................................14
+      4.4. The Intelligence Resides in the PDP .......................15
+      4.5. Simplicity and Adaptability vs. Complexity ................16
+      4.6. Performance and Scalability ...............................16
+      4.7. Risk Assessment ...........................................17
+   5. Security Considerations ........................................17
+   6. Acknowledgements ...............................................18
+   7. Informative References .........................................18
+
+
+
+
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 2]
+
+RFC 7149                         On SDN                       March 2014
+
+
+1.  Introduction
+
+   The Internet has become the federative network that supports a wide
+   range of service offerings.  The delivery of network services such as
+   IP VPNs assumes the combined activation of various capabilities that
+   include (but are not necessarily limited to) forwarding and routing
+   (e.g., customer-specific addressing scheme management, dynamic path
+   computation to reach a set of destination prefixes, dynamic
+   establishment of tunnels, etc.); Quality of Service (e.g., traffic
+   classification, marking, conditioning, and scheduling); security
+   (e.g., filters to protect customer premises from network-originated
+   attacks, to avoid malformed route announcements, etc.); and
+   management (e.g., fault detection and processing).
+
+   As these services not only grow in variety but also in complexity,
+   their design, delivery, and operation have become a complex alchemy
+   that often requires various levels of expertise.  This situation is
+   further aggravated by the wide variety of (network) protocols and
+   tools, as well as recent convergence trends driven by Any Time, Any
+   Where, Any Device (ATAWAD); ATAWADs are meant to make sure that an
+   end user can access the whole range of services he/she has subscribed
+   to whatever the access and device technologies, wherever the end user
+   is connected to the network, and whether or not this end user is in
+   motion.
+
+   Yet, most of these services have been deployed for the past decade,
+   primarily based upon often static service production procedures that
+   are more and more exposed to the risk of erroneous configuration
+   commands.  In addition, most of these services do not assume any
+   specific negotiation between the customer and the service provider or
+   between service providers, besides the typical financial terms.
+
+   At best, five-year master plans are referred to as the network
+   planning policy that will be enforced by the service provider given
+   the foreseen business development perspectives, manually computed
+   traffic forecasts, and market coverage (fixed/mobile and residential/
+   corporate).  This so-called network planning policy may very well
+   affect the way resources are allocated in a network, but it clearly
+   fails to be adequately responsive to highly dynamic customer
+   requirements in an "always-on" fashion.  The need for improved
+   service delivery procedures (including the time it takes to deliver
+   the service once the possible negotiation phase is completed) is even
+   more critical for corporate customers.
+
+
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 3]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   In addition, various tools are used for different, sometimes service-
+   centric, management purposes, but their usage is not necessarily
+   coordinated for event aggregation, correlation, and processing.  This
+   lack of coordination may come at the cost of extra complexity and
+   possible customer Quality-of-Experience degradation.
+
+   Multi-service, multi-protocol, multi-technology-convergent, and
+   dynamically adaptive networking environments of the near future have
+   therefore become one of the major challenges faced by service
+   providers.
+
+   This document aims to clarify the SDN landscape by providing a
+   perspective on the functional taxonomy of the techniques that can be
+   used in SDN, as seen from within a service provider environment.
+
+2.  Introducing Software-Defined Networking
+
+2.1.  A Tautology?
+
+   The separation of the forwarding and control planes (beyond
+   implementation considerations) has almost become a gimmick to promote
+   flexibility as a key feature of the SDN approach.  Technically, most
+   of the current router implementations have been assuming this
+   separation for decades.  Routing processes (such as IGP and BGP route
+   computation) have often been software based, while forwarding
+   capabilities are usually implemented in hardware.
+
+   As such, at the time of writing, what is considered to be state of
+   the art tends to confirm the said separation, which rather falls
+   under a tautology.
+
+   But, a somewhat centralized, "controller-embedded", control plane for
+   the sake of optimized route computation before the Forwarding
+   Information Base (FIB) population is certainly another story.
+
+2.2.  On Flexibility
+
+   Promoters of SDN have argued that it provides additional flexibility
+   in how the network is operated.  This is undoubtedly one of the key
+   objectives that must be achieved by service providers.  This is
+   because the ability to dynamically adapt to a wide range of customer
+   requests for flexible network service delivery is an important
+   competitive advantage.  But, flexibility is much, much more than
+   separating the control and forwarding planes to facilitate forwarding
+   decision-making processes.
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 4]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   For example, the ability to accommodate short duration extra
+   bandwidth requirements so that end users can stream a video file to
+   their 4G terminal device is an example of the flexibility that
+   several mobile operators are currently investigating.
+
+   From this perspective, the ability to predict the network behavior as
+   a function of the network services to be delivered is of paramount
+   importance for service providers, so that they can assess the impact
+   of introducing new services or activating additional network features
+   or enforcing a given set of (new) policies from both financial and
+   technical standpoints.  This argues in favor of investigating
+   advanced network emulation engines, which can be fed with information
+   that can be derived from [LS-DISTRIB], for example.
+
+   Given the rather broad scope that the term "flexibility" suggests:
+
+   o  Current SDN-labeled solutions are claimed to be flexible, although
+      the notion is hardly defined.  The exact characterization of what
+      flexibility actually means is yet to be provided.  Further work
+      needs, therefore, to be conducted so that flexibility can be
+      precisely defined in light of various criteria such as network
+      evolution capabilities as a function of the complexity introduced
+      by the integration of SDN techniques and seamless capabilities
+      (i.e., the ability to progressively introduce SDN-enabled devices
+      without disrupting network and service operation, etc.).
+
+   o  The exposure of programmable interfaces is not a goal per se;
+      rather, it is a means to facilitate configuration procedures for
+      improved flexibility.
+
+2.3.  A Tentative Definition
+
+   We define Software-Defined Networking as the set of techniques used
+   to facilitate the design, delivery, and operation of network services
+   in a deterministic, dynamic, and scalable manner.  The said
+   determinism refers to the ability to completely master the various
+   components of the service delivery chain, so that the service that
+   has been delivered complies with what has been negotiated and
+   contractually defined with the customer.
+
+   As such, determinism implies that the ability to control how network
+   services are structured, designed, and delivered and where traffic
+   should be forwarded in the network is for optimized resource usage.
+   Although not explicitly restated in the following sections of the
+   document, determinism lies beneath any action that may be taken by a
+   service provider once service parameter negotiation is completed,
+   from configuration tasks to service delivery, fulfillment, and
+   assurance (see Section 2.4 below).
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 5]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   Such a definition assumes the introduction of a high level of
+   automation in the overall service delivery and operation procedures.
+
+   Because networking is software driven by nature, the above definition
+   does not emphasize the claimed "software-defined" properties of SDN-
+   labeled solutions.
+
+2.4.  Functional Metadomains
+
+   SDN techniques can be classified into the following functional
+   metadomains:
+
+   o  Techniques for the dynamic discovery of network topology, devices,
+      and capabilities, along with relevant information and data models
+      that are meant to precisely document such topology, devices, and
+      their capabilities.
+
+   o  Techniques for exposing network services and their characteristics
+      and for dynamically negotiating the set of service parameters that
+      will be used to measure the level of quality associated with the
+      delivery of a given service or a combination thereof.  An example
+      of this can be seen in [CPP].
+
+   o  Techniques used by service-requirement-derived dynamic resource
+      allocation and policy enforcement schemes, so that networks can be
+      programmed accordingly.  Decisions made to dynamically allocate
+      resources and enforce policies are typically the result of the
+      correlation of various inputs, such as the status of available
+      resources in the network at any given time, the number of customer
+      service subscription requests that need to be processed over a
+      given period of time, the traffic forecasts, the possible need to
+      trigger additional resource provisioning cycles according to a
+      typical multi-year master plan, etc.
+
+   o  Dynamic feedback mechanisms that are meant to assess how
+      efficiently a given policy (or a set thereof) is enforced from a
+      service fulfillment and assurance perspective.
+
+3.  Reality Check
+
+   The networking ecosystem has become awfully complex and highly
+   demanding in terms of robustness, performance, scalability,
+   flexibility, agility, etc.  This means, in particular, that service
+   providers and network operators must deal with such complexity and
+   operate networking infrastructures that can evolve easily, remain
+   scalable, guarantee robustness and availability, and are resilient to
+   denial-of-service attacks.
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 6]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   The introduction of new SDN-based networking features should
+   obviously take into account this context, especially from a cost
+   impact assessment perspective.
+
+3.1.  Remember the Past
+
+   SDN techniques are not the next big thing per se but rather a kind of
+   rebranding of proposals that have been investigated for several
+   years, like active or programmable networks [AN] [PN].  As a matter
+   of fact, some of the claimed "new" SDN features have been already
+   implemented (e.g., Network Management System (NMS) and Path
+   Computation Element (PCE) [RFC4655]) and supported by vendors for
+   quite some time.
+
+   Some of these features have also been standardized (e.g., DNS-based
+   routing [RFC1383]) that can be seen as an illustration of separated
+   control and forwarding planes or Forwarding and Control Element
+   Separation (ForCES) [RFC5810] [RFC5812].
+
+   Also, the policy-based management framework [RFC2753] introduced in
+   the early 2000's was designed to orchestrate available resources by
+   means of a typical Policy Decision Point (PDP), which masters
+   advanced offline traffic engineering capabilities.  As such, this
+   framework has the ability to interact with in-band software modules
+   embedded in controlled devices (or not).
+
+   PDP is where policy decisions are made.  PDPs use a directory service
+   for policy repository purposes.  The policy repository stores the
+   policy information that can be retrieved and updated by the PDP.  The
+   PDP delivers policy rules to the Policy Enforcement Point (PEP) in
+   the form of policy-provisioning information that includes
+   configuration information.
+
+   PEP is where policy decisions are applied.  PEPs are embedded in
+   (network) devices, which are dynamically configured based upon the
+   policy-formatted information that has been processed by the PEP.
+   PEPs request configuration from the PDP, store the configuration
+   information in the Policy Information Base (PIB), and delegate any
+   policy decision to the PDP.
+
+   SDN techniques as a whole are an instantiation of the policy-based
+   management framework.  Within this context, SDN techniques can be
+   used to activate capabilities on demand, to dynamically invoke
+   network and storage resources, and to operate dynamically adaptive
+   networks according to events (e.g., alteration of the network
+   topology), triggers (e.g., dynamic notification of a link failure),
+   etc.
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 7]
+
+RFC 7149                         On SDN                       March 2014
+
+
+3.2.  Be Pragmatic
+
+   SDN approaches should be holistic, i.e., global and network wide.  It
+   is not a matter of configuring devices one by one to enforce a
+   specific forwarding policy.  Instead, SDN techniques are about
+   configuring and operating a whole range of devices at the scale of
+   the network for automated service delivery [AUTOMATION], from service
+   negotiation (e.g., [CPNP]) and creation (e.g., [SLA-EXCHANGE]) to
+   assurance and fulfillment.
+
+   Because the complexity of activating SDN capabilities is largely
+   hidden from the end user and is software handled, a clear
+   understanding of the overall ecosystem is needed to figure out how to
+   manage this complexity and to what extent this hidden complexity does
+   not have side effects on network operation.
+
+   As an example, SDN designs that assume a central decision-making
+   entity must avoid single points of failure.  They must not affect
+   packet forwarding performances either (e.g., transit delays must not
+   be impacted).
+
+   SDN techniques are not necessary to develop new network services per
+   se.  The basic service remains as (IP) connectivity that solicits
+   resources located in the network.  SDN techniques can thus be seen as
+   another means to interact with network service modules and invoke
+   both connectivity and storage resources accordingly in order to meet
+   service-specific requirements.
+
+   By definition, SDN technique activation and operation remain limited
+   to what is supported by embedded software and hardware.  One cannot
+   expect SDN techniques to support unlimited customizable features.
+
+3.3.  Measure Experience against Expectations
+
+   Because several software modules may be controlled by external
+   entities (typically, a PDP), there is a need for a means to make sure
+   that what has been delivered complies with what has been negotiated.
+   Such means belong to the set of SDN techniques.
+
+   These typical policy-based techniques should interact with both
+   Service Structuring engines (that are meant to expose the service
+   characteristics and possibly negotiate those characteristics) and the
+   network to continuously assess whether the experienced network
+   behavior is compliant with the objectives set by the Service
+   Structuring engine and those that may have been dynamically
+   negotiated with the customer (e.g., as captured in a CPP [CPP]
+   [CPNP]).  This requirement applies to several regions of a network,
+   including:
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 8]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   1.  At the interface between two adjacent IP network providers.
+
+   2.  At the access interface between a service provider and an IP
+       network provider.
+
+   3.  At the interface between a customer and the IP network provider.
+
+   Ideally, a fully automated service delivery procedure, from
+   negotiation, ordering, and order processing to delivery, assurance,
+   and fulfillment, should be supported at the cost of implications that
+   are discussed in Section 4.1.  This approach also assumes widely
+   adopted standard data and information models in addition to
+   interfaces.
+
+3.4.  Design Carefully
+
+   Exposing open and programmable interfaces has a cost from both
+   scalability and performance standpoints.
+
+   Maintaining hard-coded performance optimization techniques is
+   encouraged.  So is the use of interfaces that allow the direct
+   control of some engines (e.g., routing and forwarding) without
+   requiring any in-between adaptation layers (generic objects to
+   vendor-specific command line interfaces (CLIs), for instance).
+   Nevertheless, the use of vendor-specific access means to some engines
+   that it could be beneficial from a performance standpoint, at the
+   cost of increasing the complexity of configuration tasks.
+
+   SDN techniques will have to accommodate vendor-specific components
+   anyway.  Indeed, these vendor-specific features will not cease to
+   exist mainly because of the harsh competition.
+
+   The introduction of new functions or devices that may jeopardize
+   network flexibility should be avoided or at least carefully
+   considered in light of possible performance and scalability impacts.
+   SDN-enabled devices will have to coexist with legacy systems.
+
+   One single SDN network-wide deployment is, therefore, very unlikely.
+   Instead, multiple instantiations of SDN techniques will be
+   progressively deployed and adapted to various network and service
+   segments.
+
+3.5.  On OpenFlow
+
+   Empowering networking with in-band controllable modules may rely upon
+   the OpenFlow protocol but also use other protocols to exchange
+   information between a control plane and a data plane.
+
+
+
+
+Boucadair & Jacquenet         Informational                     [Page 9]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   Indeed, there are many other candidate protocols that can be used for
+   the same or even a broader purpose (e.g., resource reservation
+   purposes).  The forwarding of the configuration information can, for
+   example, rely upon protocols like the Path Computation Element (PCE)
+   Communication Protocol (PCEP) [RFC5440], the Network Configuration
+   Protocol (NETCONF) [RFC6241], COPS Usage for Policy Provisioning
+   (COPS-PR) [RFC3084], Routing Policy Specification Language (RPSL)
+   [RFC2622], etc.
+
+   There is, therefore, no 1:1 relationship between OpenFlow and SDN.
+   Rather, OpenFlow is one of the candidate protocols to convey specific
+   configuration information towards devices.  As such, OpenFlow is one
+   possible component of the global SDN toolkit.
+
+3.6.  Non-goals
+
+   There are inevitable trade-offs to be found between operating the
+   current networking ecosystem and introducing some SDN techniques,
+   possibly at the cost of introducing new technologies.  Operators do
+   not have to choose between the two as both environments will have to
+   coexist.
+
+   In particular, the following considerations cannot justify the
+   deployment of SDN techniques:
+
+   o  Fully flexible software implementations because the claimed
+      flexibility remains limited by the software and hardware
+      limitations, anyway.
+
+   o  Fully modular implementations are difficult to achieve (because of
+      the implicit complexity) and may introduce extra effort for
+      testing, validation, and troubleshooting.
+
+   o  Fully centralized control systems that are likely to raise some
+      scalability issues.  Distributed protocols and their ability to
+      react to some events (e.g., link failure) in a timely manner
+      remains a cornerstone of scalable networks.  This means that SDN
+      designs can rely upon a logical representation of centralized
+      features (an abstraction layer that would support inter-PDP
+      communications, for example).
+
+
+
+
+
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 10]
+
+RFC 7149                         On SDN                       March 2014
+
+
+4.  Discussion
+
+4.1.  Implications of Full Automation
+
+   The path towards full automation is paved with numerous challenges
+   and requirements, including:
+
+   o  Making sure automation is well implemented so as to facilitate
+      testing (including validation checks) and troubleshooting.
+
+      *  This suggests the need for simulation tools that accurately
+         assess the impact of introducing a high level of automation in
+         the overall service delivery procedure to avoid a typical "mad
+         robot" syndrome, whose consequences can be serious from control
+         and QoS standpoints, among others.
+
+      *  This also suggests careful management of human expertise, so
+         that network operators can use robust, flexible means to
+         automate repetitive or error-prone tasks and then build on
+         automation or stringing together multiple actions to create
+         increasingly complex tasks that require less human interaction
+         (guidance and input) to complete.
+
+   o  Simplifying and fostering service delivery, assurance, and
+      fulfillment, as well as network failure detection, diagnosis, and
+      root cause analysis for cost optimization.
+
+      *  Such cost optimization relates to improved service delivery
+         times as well as optimized human expertise (see above) and
+         global, technology-agnostic service structuring and delivery
+         procedures.  In particular, the ability to inject new functions
+         in existing devices should not assume a replacement of the said
+         devices but rather allow smart investment capitalization.
+
+      *  This can be achieved thanks to automation, possibly based upon
+         a logically centralized view of the network infrastructure (or
+         a portion thereof), yielding the need for highly automated
+         topology, device and capabilities discovery means, and
+         operational procedures.
+
+      *  The main intelligence resides in the PDP, which suggests that
+         an important part of the SDN-related development effort should
+         focus on a detailed specification of the PDP function,
+         including algorithms and behavioral state machineries that are
+         based upon a complete set of standardized data and information
+         models.
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 11]
+
+RFC 7149                         On SDN                       March 2014
+
+
+      *  These information models and data need to be carefully
+         structured for efficiency and flexibility.  This probably
+         suggests that a set of simplified pseudo-blocks can be
+         assembled as per the nature of the service to be delivered.
+
+   o  The need for abstraction layers -- clear interfaces between
+      business actors and between layers, let alone cross-layer
+      considerations, etc.  Such abstraction layers are invoked within
+      the context of service structuring and packaging and are meant to
+      facilitate the emergence of the following:
+
+      *  IP connectivity service exposure to customers, peers,
+         applications, content/service providers, etc.  (an example of
+         this can be seen in [CPP]).
+
+      *  Solutions that accommodate IP connectivity service requirements
+         with network engineering objectives.
+
+      *  Dynamically adaptive decision-making processes, which can
+         properly operate according to a set of input data and metrics,
+         such as current resource usage and demand, traffic forecasts
+         and matrices, etc., all for the sake of highly responsive
+         dynamic resource allocation and policy enforcement schemes.
+
+   o  Better accommodation of technologically heterogeneous networking
+      environments through the following:
+
+      *  Vendor-independent configuration procedures based upon the
+         enforcement of vendor-agnostic generic policies instead of
+         vendor-specific languages.
+
+      *  Tools to aid manageability and orchestrate resources.
+
+      *  Avoiding proxies and privileging direct interaction with
+         engines (e.g., routing and forwarding).
+
+4.2.  Bootstrapping an SDN
+
+   Means to dynamically discover the functional capabilities of the
+   devices that will be steered by a PDP intelligence for automated
+   network service delivery need to be provided.  This is because the
+   acquisition of the information related to what the network is
+   actually capable of will help structure the PDP intelligence so that
+   policy provisioning information can be derived accordingly.
+
+   A typical example would consist in documenting a traffic engineering
+   policy based upon the dynamic discovery of the various functions
+   supported by the network devices, as a function of the services to be
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 12]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   delivered, thus yielding the establishment of different routes
+   towards the same destination depending on the nature of the traffic,
+   the location of the functions that need to be invoked to forward such
+   traffic, etc.
+
+   Such dynamic discovery capability can rely upon the exchange of
+   specific information by means of an IGP or BGP between network
+   devices or between network devices and the PDP in legacy networking
+   environments.  The PDP can also send unsolicited commands towards
+   network devices to acquire the description of their functional
+   capabilities in return and derive network and service topologies
+   accordingly.
+
+   Of course, SDN techniques (as introduced in Section 2.4) could be
+   deployed in an IGP-/BGP-free networking environment, but the SDN
+   bootstrapping procedure in such an environment still assumes the
+   support of the following capabilities:
+
+   o  Dynamically discover SDN participating nodes (including the PDP)
+      and their respective capabilities in a resilient manner, assuming
+      the mutual authentication of the PDP and the participating devices
+      Section 5.  The integrity of the information exchanged between the
+      PDP and the participating devices during the discovery phase must
+      also be preserved;
+
+   o  Dynamically connect the PDP to the participating nodes and avoid
+      any forwarding loops;
+
+   o  Dynamically enable network services as a function of the device
+      capabilities and (possibly) what has been dynamically negotiated
+      between the customer and the service provider;
+
+   o  Dynamically check connectivity between the PDP and the
+      participating nodes and between participating nodes for the
+      delivery of a given network service (or a set thereof);
+
+   o  Dynamically assess the reachability scope as a function of the
+      service to be delivered;
+
+   o  Dynamically detect and diagnose failures, and proceed with
+      corrective actions accordingly.
+
+   Likewise, the means to dynamically acquire the descriptive
+   information (including the base configuration) of any network device
+   that may participate in the delivery of a given service should be
+   provided so as to help the PDP structure the services that can be
+   delivered as a function of the available resources, their location,
+   etc.
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 13]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   In IGP-/BGP-free networking environments, a specific bootstrap
+   protocol may thus be required to support the aforementioned
+   capabilities for proper PDP- and SDN-capable device operation, in
+   addition to the possible need for a specific additional network that
+   would provide discovery and connectivity features.
+
+   In particular, SDN design and operation in IGP-/BGP-free environments
+   should provide performances similar to those of legacy environments
+   that run an IGP and BGP.  For example, the underlying network should
+   remain operational even if connection with the PDP has been lost.
+   Furthermore, operators should assess the cost of introducing a new,
+   specific bootstrap protocol compared to the cost of integrating the
+   aforementioned capabilities in existing IGP/BGP protocol machineries.
+
+   Since SDN-related features can be grafted into an existing network
+   infrastructure, they may not be all enabled at once from a
+   bootstrapping perspective; a gradual approach can be adopted instead.
+
+   A typical deployment example would be to use an SDN decision-making
+   process as an emulation platform that would help service providers
+   and operators make appropriate technical choices before their actual
+   deployment in the network.
+
+   Finally, the completion of the discovery procedure does not
+   necessarily mean that the network is now fully operational.  The
+   operationality of the network usually assumes a robust design based
+   upon resilience and high availability features.
+
+4.3.  Operating an SDN
+
+   From an Operations and Management (OAM) standpoint [RFC6291], running
+   an SDN-capable network raises several issues such as those listed
+   below:
+
+   o  How do SDN service and network management blocks interact?  For
+      example, how the results of the dynamic negotiation of service
+      parameters with a customer or a set thereof over a given period of
+      time will affect the PDP decision-making process (resource
+      allocation, path computation, etc.).
+
+   o  What should be the appropriate OAM tools for SDN network operation
+      (e.g., to check PDP or PEP reachability)?
+
+   o  How can performance (expressed in terms of service delivery time,
+      for example) be optimized when the activation of software modules
+      is controlled by an external entity (typically a PDP)?
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 14]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   o  To what extent does an SDN implementation ease network
+      manageability, including service and network diagnosis?
+
+   o  Should the "control and data plane separation" principle be
+      applied to the whole network or a portion thereof, as a function
+      of the nature of the services to be delivered or by taking into
+      account the technology that is currently deployed?
+
+   o  What is the impact on the service provider's testing procedures
+      and methodologies (that are used during validation and pre-
+      deployment phases)?  Particularly, (1) how test cases will be
+      defined and executed when the activation of customized modules is
+      supported, (2) what the methodology is to assess the behavior of
+      SDN-controlled devices, (3) how test regression will be conducted,
+      (4) etc.
+
+   o  How do SDN techniques impact service fulfillment and assurance?
+      How the resulting behavior of SDN devices (completion of
+      configuration tasks, for example) should be assessed against what
+      has been dynamically negotiated with a customer.  How to measure
+      the efficiency of dynamically enforced policies as a function of
+      the service that has been delivered.  How to measure that what has
+      been delivered is compliant with what has been negotiated.  What
+      the impact is of SDN techniques on troubleshooting practice.
+
+   o  Is there any risk to operate frozen architectures because of
+      potential interoperability issues between a controlled device and
+      an SDN controller?
+
+   o  How does the introduction of SDN techniques affect the lifetime of
+      legacy systems?  Is there any risk of (rapidly) obsoleting
+      existing technologies because of their hardware or software
+      limitations?
+
+   The answers to the above questions are very likely to be service
+   provider specific, depending on their technological and business
+   environments.
+
+4.4.  The Intelligence Resides in the PDP
+
+   The proposed SDN definition in Section 2.3 assumes an intelligence
+   that may reside in the control or the management planes (or both).
+   This intelligence is typically represented by a Policy Decision Point
+   (PDP) [RFC2753], which is one of the key functional components of the
+   policy-based management framework.
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 15]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   SDN networking, therefore, relies upon PDP functions that are capable
+   of processing various input data (traffic forecasts, outcomes of
+   negotiation between customers and service providers, resource status
+   as depicted in appropriate information models instantiated in the
+   PIB, etc.) to make appropriate decisions.
+
+   The design and the operation of such PDP-based intelligence in a
+   scalable manner remains a part of the major areas that need to be
+   investigated.
+
+   To avoid centralized design schemes, inter-PDP communication is
+   likely to be required, and corresponding issues and solutions should
+   be considered.  Several PDP instances may thus be activated in a
+   given domain.  Because each of these PDP instances may be responsible
+   for making decisions about the enforcement of a specific policy
+   (e.g., one PDP for QoS policy enforcement purposes, another one for
+   security policy enforcement purposes, etc.), an inter-PDP
+   communication scheme is required for global PDP coordination and
+   correlation.
+
+   Inter-domain PDP exchanges may also be needed for specific usages.
+   Examples of such exchanges are as follows: (1) during the network
+   attachment phase of a node to a visited network, the PDP operated by
+   the visited network can contact the home PDP to retrieve the policies
+   to be enforced for that node, and (2) various PDPs can collaborate in
+   order to compute inter-domain paths that satisfy a set of traffic
+   performance guarantees.
+
+4.5.  Simplicity and Adaptability vs. Complexity
+
+   The functional metadomains introduced in Section 2.4 assume the
+   introduction of a high level of automation, from service negotiation
+   to delivery and operation.  Automation is the key to simplicity, but
+   it must not be seen as a magic button that would be hit by a network
+   administrator whenever a customer request has to be processed or
+   additional resources need to be allocated.
+
+   The need for simplicity and adaptability, thanks to automated
+   procedures, generally assumes some complexity that lies beneath
+   automation.
+
+4.6.  Performance and Scalability
+
+   The combination of flexibility with software inevitably raises
+   performance and scalability issues as a function of the number and
+   the nature of the services to be delivered and their associated
+   dynamics.
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 16]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   For example, networks deployed in Data Centers (DCs) and that rely
+   upon OpenFlow switches are unlikely to raise important FIB
+   scalability issues.  Conversely, DC interconnect designs that aim to
+   dynamically manage Virtual Machine (VM) mobility, possibly based upon
+   the dynamic enforcement of specific QoS policies, may raise
+   scalability issues.
+
+   The claimed flexibility of SDN networking in the latter context will
+   have to be carefully investigated by operators.
+
+4.7.  Risk Assessment
+
+   Various risks are to be assessed such as:
+
+   o  Evaluating the risk of depending on a controller technology rather
+      than a device technology.
+
+   o  Evaluating the risk of operating frozen architectures because of
+      potential interoperability issues between a controller and a
+      controlled device.
+
+   o  Assessing whether SDN-labeled solutions are likely to obsolete
+      existing technologies because of hardware limitations.  From a
+      technical standpoint, the ability to dynamically provision
+      resources as a function of the services to be delivered may be
+      incompatible with legacy routing systems because of their hardware
+      limitations, for example.  Likewise, from an economical
+      standpoint, the use of SDN solutions for the sake of flexibility
+      and automation may dramatically impact Capital Expenditure (CAPEX)
+      and Operational Expenditure (OPEX) budgets.
+
+5.  Security Considerations
+
+   Security is an important aspect of any SDN design because it
+   conditions the robustness and reliability of the interactions between
+   network and applications people for efficient access control
+   procedures and optimized protection of SDN resources against any kind
+   of attack.  In particular, SDN security policies [SDNSEC] should make
+   sure that SDN resources are properly safeguarded against actions that
+   may jeopardize network or application operations.
+
+   In particular, service providers should define procedures to assess
+   the reliability of software modules embedded in SDN nodes.  Such
+   procedures should include the means to also assess the behavior of
+   software components (under stress conditions), detect any exploitable
+   vulnerability, reliably proceed with software upgrades, etc.  These
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 17]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   security guards should be activated during initial SDN node
+   deployment and activation but also during SDN operation that implies
+   software upgrade procedures.
+
+   Although these procedures may not be SDN-specific (e.g., operators
+   are familiar with firmware updates with or without service
+   disruption), it is worth challenging existing practice in light of
+   SDN deployment and operation.
+
+   Likewise, PEP-PDP interactions suggest the need to make sure that (1)
+   a PDP is entitled to solicit PEPs, so that they can apply the
+   decisions made by the said PDP, (2) a PEP is entitled to solicit a
+   PDP for whatever reason (request for additional configuration
+   information, notification about the results of a set of configuration
+   tasks, etc.), (3) a PEP can accept decisions made by a PDP, and (4)
+   communication between PDPs within a domain or between domains is
+   properly secured (e.g., make sure a pair of PDPs are entitled to
+   communicate with each other, make sure the confidentiality of the
+   information exchanged between two PDPs can be preserved, etc.).
+
+6.  Acknowledgements
+
+   Many thanks to R. Barnes, S. Bryant, S. Dawkins, A. Farrel, S.
+   Farrell, W. George, J. Halpern, D. King, J. Hadi Salim, and T. Tsou
+   for their comments.  Special thanks to P. Georgatos for the fruitful
+   discussions on SDN Interconnection (SDNI) in particular.
+
+7.  Informative References
+
+   [AN]       Tennenhouse, D. and D. Wetherall, "Towards an Active
+              Network Architecture", Multimedia Computing and Networking
+              (MMCN), January 1996.
+
+   [AUTOMATION]
+              Boucadair, M. and C. Jacquenet, "Requirements for
+              Automated (Configuration) Management", Work in Progress,
+              January 2014.
+
+   [CPNP]     Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
+              Negotiation Protocol (CPNP)", Work in Progress, October
+              2013.
+
+   [CPP]      Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS
+              Connectivity Provisioning Profile", Work in Progress,
+              September 2012.
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 18]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   [LS-DISTRIB]
+              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
+              Ray, "North-Bound Distribution of Link-State and TE
+              Information using BGP", Work in Progress, November 2013.
+
+   [PN]       Campbell, A., De Meer, H., Kounavis, M., Kazuho, M.,
+              Vincente, J., and D. Villela, "A Survey of Programmable
+              Networks", ACM SIGCOMM Computer Communication Review,
+              April 1999.
+
+   [RFC1383]  Huitema, C., "An Experiment in DNS Based IP Routing", RFC
+              1383, December 1992.
+
+   [RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
+              Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
+              "Routing Policy Specification Language (RPSL)", RFC 2622,
+              June 1999.
+
+   [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
+              for Policy-based Admission Control", RFC 2753, January
+              2000.
+
+   [RFC3084]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
+              K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
+              Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC
+              3084, March 2001.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655, August 2006.
+
+   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
+              (PCE) Communication Protocol (PCEP)", RFC 5440, March
+              2009.
+
+   [RFC5810]  Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
+              W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
+              Control Element Separation (ForCES) Protocol
+              Specification", RFC 5810, March 2010.
+
+   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
+              Element Separation (ForCES) Forwarding Element Model", RFC
+              5812, March 2010.
+
+   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
+              Bierman, "Network Configuration Protocol (NETCONF)", RFC
+              6241, June 2011.
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 19]
+
+RFC 7149                         On SDN                       March 2014
+
+
+   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
+              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
+              Acronym in the IETF", BCP 161, RFC 6291, June 2011.
+
+   [SDNSEC]   Hartman, S. and D. Zhang, "Security Requirements in the
+              Software Defined Networking Model", Work in Progress,
+              April 2013.
+
+   [SLA-EXCHANGE]
+              Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M.
+              Boucadair, "Inter-domain SLA Exchange", Work in Progress,
+              November 2013.
+
+Authors' Addresses
+
+   Mohamed Boucadair
+   France Telecom
+   Rennes  35000
+   France
+
+   EMail: mohamed.boucadair@orange.com
+
+
+   Christian Jacquenet
+   France Telecom
+   Rennes
+   France
+
+   EMail: christian.jacquenet@orange.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair & Jacquenet         Informational                    [Page 20]
+