GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7920

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7920.txt · Last modified: 2016/06/30 17:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki