doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc7920.txt b/doc/rfc/rfc7920.txt
new file mode 100644
index 0000000..bfafb5b
--- /dev/null
+++ b/doc/rfc/rfc7920.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     A. Atlas, Ed.
+Request for Comments: 7920                              Juniper Networks
+Category: Informational                                   T. Nadeau, Ed.
+ISSN: 2070-1721                                                  Brocade
+                                                                 D. Ward
+                                                           Cisco Systems
+                                                               June 2016
+
+
+       Problem Statement for the Interface to the Routing System
+
+Abstract
+
+   Traditionally, routing systems have implemented routing and signaling
+   (e.g., MPLS) to control traffic forwarding in a network.  Route
+   computation has been controlled by relatively static policies that
+   define link cost, route cost, or import and export routing policies.
+   Requirements have emerged to more dynamically manage and program
+   routing systems due to the advent of highly dynamic data-center
+   networking, on-demand WAN services, dynamic policy-driven traffic
+   steering and service chaining, the need for real-time security threat
+   responsiveness via traffic control, and a paradigm of separating
+   policy-based decision-making from the router itself.  These
+   requirements should allow controlling routing information and traffic
+   paths and extracting network topology information, traffic
+   statistics, and other network analytics from routing systems.
+
+   This document proposes meeting this need via an Interface to the
+   Routing System (I2RS).
+
+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 7841.
+
+   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/rfc7920.
+
+
+
+
+
+
+Atlas, et al.                 Informational                     [Page 1]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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. I2RS Model and Problem Area for the IETF ........................4
+   3. Standard Data Models of Routing State for Installation ..........6
+   4. Learning Router Information .....................................7
+   5. Aspects to be Considered for an I2RS Protocol ...................8
+   6. Security Considerations .........................................9
+   7. References .....................................................10
+      7.1. Normative References ......................................10
+      7.2. Informative References ....................................10
+   Appendix A.  Existing Management Interfaces .......................11
+   Acknowledgements ..................................................12
+   Authors' Addresses ................................................12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al.                 Informational                     [Page 2]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+1.  Introduction
+
+   Traditionally, routing systems have implemented routing and signaling
+   (e.g., MPLS) to control traffic forwarding in a network.  Route
+   computation has been controlled by relatively static policies that
+   define link cost, route cost, or import and export routing policies.
+   The advent of highly dynamic data-center networking, on-demand WAN
+   services, dynamic policy-driven traffic steering and service
+   chaining, the need for real-time security threat responsiveness via
+   traffic control, and a paradigm of separating policy-based decision-
+   making from the router itself has created the need to more
+   dynamically manage and program routing systems in order to control
+   routing information and traffic paths and to extract network topology
+   information, traffic statistics, and other network analytics from
+   routing systems.
+
+   As modern networks continue to grow in scale and complexity and
+   desired policy has become more complex and dynamic, there is a need
+   to support rapid control and analytics.  The scale of modern networks
+   and data centers and the associated operational expense drives the
+   need to automate even the simplest operations.  The ability to
+   quickly interact via more complex operations to support dynamic
+   policy is even more critical.
+
+   In order to enable network applications to have access to and control
+   over information in the different vendors' routing systems, a
+   publicly documented interface is required.  The interface needs to
+   support real-time, asynchronous interactions using efficient data
+   models and encodings that are based on and extend those previously
+   defined.  Furthermore, the interface must be tailored to provide a
+   solid base on which a variety of use cases can be supported.
+
+   To support the requirements of orchestration software and automated
+   network applications to dynamically modify the network, there is a
+   need to learn topology, network analytics, and existing state from
+   the network as well as to create or modify routing information and
+   network paths.  A feedback loop is needed so that changes made can be
+   verifiable and so that these applications can learn and react to
+   network changes.
+
+   Proprietary solutions to partially support the requirements outlined
+   above have been developed to handle specific situations and needs.
+   Standardizing an interface to the routing system will make it easier
+   to integrate use of it into a network.  Because there are proprietary
+   partial solutions already, the standardization of a common interface
+   should be feasible.
+
+
+
+
+
+Atlas, et al.                 Informational                     [Page 3]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+   It should be noted that during the course of this document, the term
+   "applications" is used.  This is meant to refer to an executable
+   program of some sort that has access to a network, such as an IP or
+   MPLS network, via a routing system.
+
+2.  I2RS Model and Problem Area for the IETF
+
+   Managing a network of systems running a variety of routing protocols
+   and/or providing one or more additional services (e.g., forwarding,
+   classification and policing, firewalling) involves interactions
+   between multiple components within these systems.  Some of these
+   systems or system components may be virtualized, co-located within
+   the same physical system, or distributed.  In all cases, it is
+   desirable to enable network applications to manage and control the
+   services provided by many, if not all, of these components, subject
+   to authenticated and authorized access and policies.
+
+   A data-model-driven interface to the routing system is needed.  This
+   will allow expansion of what information can be read and controlled
+   and allow for future flexibility.  At least one accompanying protocol
+   with clearly defined operations is needed; the suitable protocol(s)
+   can be identified and expanded to support the requirements of an
+   Interface to the Routing System (I2RS).  These solutions must be
+   designed to facilitate rapid, isolated, secure, and dynamic changes
+   to a device's routing system.  These would facilitate wide-scale
+   deployment of interoperable applications and routing systems.
+
+   The I2RS model and problem area for IETF work is illustrated in
+   Figure 1.  This document uses terminology defined in [RFC7921].  The
+   I2RS agent is associated with a routing element, which may or may not
+   be co-located with a data plane.  The I2RS client could be integrated
+   in a network application or controlled and used by one or more
+   separate network applications.  For instance, an I2RS client could be
+   provided by a network controller or a network orchestration system
+   that provides a non-I2RS interface to network applications and an
+   I2RS interface to I2RS agents on the systems being managed.  The
+   scope of the data models used by I2RS extends across the entire
+   routing system and the selected protocol(s) for I2RS.
+
+   As depicted in Figure 1, the I2RS client and I2RS agent in a routing
+   system are objects with in the I2RS scope.  The selected protocol(s)
+   for I2RS extend between the I2RS client and I2RS agent.  All other
+   objects and interfaces in Figure 1 are outside the I2RS scope for
+   standardization.
+
+
+
+
+
+
+
+Atlas, et al.                 Informational                     [Page 4]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+        +***************+   +***************+   +***************+
+        *  Application  *   *  Application  *   *  Application  *
+        +***************+   +***************+   +***************+
+        |  I2RS Client  |           ^                  ^
+        +---------------+           *                  *
+                 ^                  *   ****************
+                 |                  *   *
+                 |                  v   v
+                 |           +---------------+         +-------------+
+                 |           |  I2RS Client  |<------->| Other I2RS  |
+                 |           +---------------+         | Agents      |
+                 |                   ^                 +-------------+
+                 |________________   |
+                                  |  |  <== I2RS Protocol
+                                  |  |
+       ...........................|..|..................................
+       .                          v  v                                 .
+       . +*************+     +---------------+      +****************+ .
+       . *  Policy     *     |               |      *   Routing  &   * .
+       . * Database    *<***>|  I2RS Agent   |<****>*   Signaling    * .
+       . +*************+     |               |      *   Protocols    * .
+       .                     +---------------+      +****************+ .
+       .                        ^   ^     ^                  ^         .
+       . +*************+        *   *     *                  *         .
+       . *  Topology   *        *   *     *                  *         .
+       . *  Database   *<*******+   *     *                  v         .
+       . +*************+            *     *         +****************+ .
+       .                            *     +********>*  RIB Manager   * .
+       .                            *               +****************+ .
+       .                            *                        ^         .
+       .                            v                        *         .
+       .                 +*******************+               *         .
+       .                 * Subscription &    *               *         .
+       .                 * Configuration     *               v         .
+       .                 * Templates for     *      +****************+ .
+       .                 * Measurements,     *      *  FIB Manager   * .
+       .                 * Events, QoS, etc. *      *  & Data Plane  * .
+       .                 +*******************+      +****************+ .
+       .................................................................
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al.                 Informational                     [Page 5]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+     <-->  interfaces inside the scope of I2RS Protocol
+
+     +--+  objects inside the scope of I2RS-defined behavior
+
+     <**>  interfaces NOT within the scope of I2RS Protocol
+
+     +**+  objects NOT within the scope of I2RS-defined behavior
+
+     <==   used to point to the interface where the I2RS Protocol
+           would be used
+
+     ....  boundary of a router supporting I2RS
+
+                   Figure 1: I2RS Model and Problem Area
+
+   The protocol(s) used to carry messages between I2RS clients and I2RS
+   agents should provide the key features specified in Section 5.
+
+   I2RS will use a set of meaningful data models for information in the
+   routing system and in a topology database.  Each data model should
+   describe the meaning and relationships of the modeled items.  The
+   data models should be separable across different features of the
+   managed components, versioned, and extendable.  As shown in Figure 1,
+   I2RS needs to interact with several logical components of the routing
+   element: policy database, topology database, subscription and
+   configuration for dynamic measurements/events, routing and signaling
+   protocols, and its Routing Information Base (RIB) manager.  This
+   interaction is both for writing (e.g., to policy databases or RIB
+   manager) as well as for reading (e.g., dynamic measurement or
+   topology database).  An application should be able to combine data
+   from individual routing elements to provide network-wide data
+   model(s).
+
+   The data models should translate into a concise transfer syntax, sent
+   via the I2RS protocol, that is straightforward for applications to
+   use (e.g., a web services design paradigm).  The information transfer
+   should use existing transport protocols to provide the reliability,
+   security, and timeliness appropriate for the particular data.
+
+3.  Standard Data Models of Routing State for Installation
+
+   As described in Section 1, there is a need to be able to precisely
+   control routing and signaling state based upon policy or external
+   measures.  One set of data models that I2RS should focus on is for
+   interacting with the RIB layer (e.g., RIB, Label Information Base
+   (LIB), multicast RIB, policy-based routing) to provide flexibility
+   and routing abstractions.  As an example, the desired routing and
+   signaling state might range from simple static routes to policy-based
+
+
+
+Atlas, et al.                 Informational                     [Page 6]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+   routing to static multicast replication and routing state.  This
+   means that, to usefully model next hops, the data model employed
+   needs to handle next-hop indirection and recursion (e.g., a prefix X
+   is routed like prefix Y) as well as different types of tunneling and
+   encapsulation.
+
+   Efforts to provide this level of control have focused on
+   standardizing data models that describe the forwarding plane (e.g.,
+   Forwarding and Control Element Separation (ForCES) [RFC3746]).  I2RS
+   recognizes that the routing system and a router's OS provide useful
+   mechanisms that applications could usefully harness to accomplish
+   application-level goals.  Using routing indirection, recursion, and
+   common routing abstractions (e.g., tunnels, Label Switched Paths
+   (LSPs), etc.) provides significant flexibility and functionality over
+   collapsing the state to individual routes in the Forwarding
+   Information Base (FIB) that need to be individually modified when a
+   change occurs.
+
+   In addition to interfaces to control the RIB layer, there is a need
+   to dynamically configure policies and parameter values for the
+   various routing and signaling protocols based upon application-level
+   policy decisions.
+
+4.  Learning Router Information
+
+   A router has information that applications may require so that they
+   can understand the network, verify that programmed state is
+   installed, measure the behavior of various flows, and understand the
+   existing configuration and state of the router.  I2RS should provide
+   a framework so that applications can register for asynchronous
+   notifications and can make specific requests for information.
+
+   Although there are efforts to extend the topological information
+   available, even the best of these (e.g., BGP-LS [RFC7752]) still only
+   provide the current active state as seen at the IGP and BGP layers.
+   Detailed topological state that provides more information than the
+   current functional status (e.g., active paths and links) is needed by
+   applications.  Examples of missing information include paths or links
+   that are potentially available (e.g., administratively down) or
+   unknown (e.g., to peers or customers) to the routing topology.
+
+   For applications to have a feedback loop that includes awareness of
+   the relevant traffic, an application must be able to request the
+   measurement and timely, scalable reporting of data.  While a
+   mechanism such as IP Flow Information Export (IPFIX) [RFC5470] may be
+   the facilitator for delivering the data, providing the ability for an
+   application to dynamically request that measurements be taken and
+   data delivered is important.
+
+
+
+Atlas, et al.                 Informational                     [Page 7]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+   There is a wide range of events that applications could use to
+   support verification of router state before other network state is
+   changed (e.g., that a route has been installed) and to allow timely
+   action in response to changes of relevant routes by others or to
+   router events (e.g., link up/down).  While a few of these (e.g., link
+   up/down) may be available via MIB notifications today, the full range
+   is not (e.g., route installed, route changed, primary LSP changed,
+   etc.)
+
+5.  Aspects to be Considered for an I2RS Protocol
+
+   This section describes required aspects of a protocol that could
+   support I2RS.  Whether such a protocol is built upon extending
+   existing mechanisms or requires a new mechanism requires further
+   investigation.
+
+   The key aspects needed in an interface to the routing system are:
+
+   Multiple Simultaneous Asynchronous Operations:   A single application
+      should be able to send multiple independent atomic operations via
+      I2RS without being required to wait for each to complete before
+      sending the next.
+
+   Very Fine Granularity of Data Locking for Writing:   When an I2RS
+      operation is processed, it is required that the data locked for
+      writing be very granular (e.g., a particular prefix and route)
+      rather than extremely coarse, as is done for writing
+      configuration.  This should improve the number of concurrent I2RS
+      operations that are feasible and reduce blocking delays.
+
+   Multi-Headed Control:   Multiple applications may communicate to the
+      same I2RS agent in a minimally coordinated fashion.  It is
+      necessary that the I2RS agent can handle multiple requests in a
+      well-known policy-based fashion.  Data written can be owned by
+      different I2RS clients at different times; data may even be
+      overwritten by a different I2RS client.  The details of how this
+      should be handled are described in [RFC7921].
+
+   Duplex:   Communications can be established by either the I2RS client
+      (i.e., that resides within the application or is used by it to
+      communicate with the I2RS agent) or the I2RS agent.  Similarly,
+      events, acknowledgements, failures, operations, etc., can be sent
+      at any time by both the router and the application.  The I2RS is
+      not a pure pull model where only the application queries to pull
+      responses.
+
+
+
+
+
+
+Atlas, et al.                 Informational                     [Page 8]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+   High Throughput:   At a minimum, the I2RS agent and associated router
+      should be able to handle a considerable number of operations per
+      second (for example, 10,000 per second to handle many individual
+      subscriber routes changing simultaneously).
+
+   Low Latency:   Within a sub-second timescale, it should be possible
+      to complete simple operations (e.g., reading or writing a single
+      prefix route).
+
+   Multiple Channels:   It should be possible for information to be
+      communicated via the interface from different components in the
+      router without requiring going through a single channel.  For
+      example, for scaling, some exported data or events may be better
+      sent directly from the forwarding plane, while other interactions
+      may come from the control plane.  One channel, with authorization
+      and authentication, may be considered primary; only an authorized
+      client can then request that information be delivered on a
+      different channel.  Writes from a client are only expected on
+      channels that provide authorization and authentication.
+
+   Scalable, Filterable Information Access:  To extract information in a
+      scalable fashion that is more easily used by applications, the
+      ability to specify filtering constructs in an operation requesting
+      data or requesting an asynchronous notification is very valuable.
+
+   Secure Control and Access:   Any ability to manipulate routing state
+      must be subject to authentication and authorization.  Sensitive
+      routing information also may need to be provided via secure access
+      back to the I2RS client.  Such communications must be integrity
+      protected.  Most communications will also require confidentiality.
+
+   Extensibility and Interoperability:   Both the I2RS protocol and
+      models must be extensible and interoperate between different
+      versions of protocols and models.
+
+6.  Security Considerations
+
+   Security is a key aspect of any protocol that allows state
+   installation and extracting of detailed router state.  The need for
+   secure control and access is mentioned in Section 5.  More
+   architectural security considerations are discussed in [RFC7921].
+   Briefly, the I2RS agent is assumed to have a separate authentication
+   and authorization channel by which it can validate both the identity
+   and the permissions associated with an I2RS client.  Mutual
+   authentication between the I2RS agent and I2RS client is required.
+   Different levels of integrity, confidentiality, and replay protection
+   are relevant for different aspects of I2RS.
+
+
+
+
+Atlas, et al.                 Informational                     [Page 9]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC7921]  Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
+              Nadeau, "An Architecture for the Interface to the Routing
+              System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
+              <http://www.rfc-editor.org/info/rfc7921>.
+
+7.2.  Informative References
+
+   [RFC3746]  Yang, L., Dantu, R., Anderson, T., and R. Gopal,
+              "Forwarding and Control Element Separation (ForCES)
+              Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,
+              <http://www.rfc-editor.org/info/rfc3746>.
+
+   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
+              "Architecture for IP Flow Information Export", RFC 5470,
+              DOI 10.17487/RFC5470, March 2009,
+              <http://www.rfc-editor.org/info/rfc5470>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <http://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
+              S. Ray, "North-Bound Distribution of Link-State and
+              Traffic Engineering (TE) Information Using BGP", RFC 7752,
+              DOI 10.17487/RFC7752, March 2016,
+              <http://www.rfc-editor.org/info/rfc7752>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al.                 Informational                    [Page 10]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+Appendix A.  Existing Management Interfaces
+
+   This section discusses as a single entity the combination of the
+   abstract data models, their representation in a data language, and
+   the transfer protocol commonly used with them.  While other
+   combinations of these existing standard technologies are possible,
+   the ways described are ones that have significant deployment.
+
+   There are three basic ways that routers are managed.  The most
+   popular is the command-line interface (CLI), which allows both
+   configuration and learning of device state.  This is a proprietary
+   interface resembling a UNIX shell that allows for very customized
+   control and observation of a device, and, specifically of interest in
+   this case, its routing system.  Some form of this interface exists on
+   almost every device (virtual or otherwise).  Processing of
+   information returned to the CLI (called "screen scraping") is a
+   burdensome activity because the data is normally formatted for use by
+   a human operator and because the layout of the data can vary from
+   device to device and between different software versions.  Despite
+   its ubiquity, this interface has never been standardized and is
+   unlikely to ever be standardized.  CLI standardization is not
+   considered as a candidate solution for the problems motivating I2RS.
+
+   The second most popular interface for interrogation of a device's
+   state, statistics, and configuration is the Simple Network Management
+   Protocol (SNMP) and a set of relevant standards-based and proprietary
+   Management Information Base (MIB) modules.  SNMP has a strong history
+   of being used by network managers to gather statistical and state
+   information about devices, including their routing systems.  However,
+   SNMP is very rarely used to configure a device or any of its systems
+   for reasons that vary depending upon the network operator.  Some
+   example reasons include complexity, the lack of desired configuration
+   semantics (e.g., configuration rollback, sandboxing, or configuration
+   versioning) and the difficulty of using the semantics (or lack
+   thereof) as defined in the MIB modules to configure device features.
+   Therefore, SNMP is not considered as a candidate solution for the
+   problems motivating I2RS.
+
+   Finally, the IETF's Network Configuration Protocol (NETCONF)
+   [RFC6241] has made many strides at overcoming most of the limitations
+   around configuration that were just described.  However, as a new
+   technology and with the initial lack of standard data models, the
+   adoption of NETCONF has been slow.  As needed, I2RS will identify and
+   define information and data models to support I2RS applications.
+   Additional extensions to handle multi-headed control may need to be
+   added to NETCONF and/or appropriate data models.
+
+
+
+
+
+Atlas, et al.                 Informational                    [Page 11]
+
+RFC 7920                 I2RS Problem Statement                June 2016
+
+
+Acknowledgements
+
+   The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,
+   Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ
+   Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah
+   Brungard, and Sarah Banks for their suggestions and review.
+
+Authors' Addresses
+
+   Alia Atlas (editor)
+   Juniper Networks
+
+   Email: akatlas@juniper.net
+
+
+   Thomas D. Nadeau (editor)
+   Brocade
+
+   Email: tnadeau@lucidvision.com
+
+
+   Dave Ward
+   Cisco Systems
+
+   Email: wardd@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al.                 Informational                    [Page 12]
+