Skip to main content

Interface to the Routing System
charter-ietf-i2rs-01-00

The information below is for an older proposed charter
Document Proposed charter Interface to the Routing System WG (i2rs) Snapshot
Title Interface to the Routing System
Last updated 2015-03-06
State Start Chartering/Rechartering (Internal Steering Group/IAB Review)
WG State Active
IESG Responsible AD Martin Vigoureux
Charter edit AD Alia Atlas
Send notices to i2rs-chairs@tools.ietf.org

charter-ietf-i2rs-01-00

In an IP routed network, the routing system:

  • Distributes topology and other state (network metadata)
  • Uses this network metadata to determine the best paths to each given
    reachable destination attached to the network
  • Communicates these decisions to the forwarding plane of each
    forwarding device in the network.

That is, the routing system is the collection of entities, protocols and
processes that collectively build the forwarding tables that are
exported into the entities that constitute the network's forwarding
plane.

While processes participating in the routing system are often colocated
with the local forwarding elements, this isn't a necessary condition.
Thus, the routing system includes control plane protocols and processes
that compute routes and paths for data packets, wherever the processes
implementing those protocols and processes may be running.

I2RS facilitates real-time or event driven interaction with the routing
system through a collection of protocol-based control or management
interfaces. These allow information, policies, and operational
parameters to be injected into and retrieved (as read or by
notification) from the routing system while retaining data consistency
and coherency across the routers and routing infrastructure, and among
multiple interactions with the routing system. The I2RS interfaces will
co-exist with existing configuration and management systems and
interfaces.

It is envisioned that users of the I2RS interfaces will be management
applications, network controllers, and user applications that make
specific demands on the network.

The I2RS working group works to develop a high-level architecture that
describes the basic building-blocks necessary to enable the specific use
cases, and that will lead to an understanding of the abstract
informational models and requirements for encodings and protocols for the I2RS interfaces. Small and well-scoped use cases are critical to
constrain the scope of the work and achieve sufficient focus for the
working group to deliver successful outcomes. Initial work within the
working group will be limited to a single administrative domain.

The working group is chartered to work on the following items:

  • High-level architecture for I2RS including considerations of policy
    and security.

  • Tightly scoped key use cases for operational use of I2RS as follows:
    o Interactions with the Routing Information Base (RIB). Allowing read
    and write access to the RIB, but no direct access to the Forwarding
    Information Base (FIB).
    o Filter-based RIBs include a match of fields in IP header plus other IP
    packet format fields. The matches in the filter-based RIBs may be ordered
    to allow appropriate sequencing of the filter. Each match contains an action
    which may be forwarding to a next hop address or other actions. I2RS will
    coordinate this work with appropriate working groups in routing, security and
    operations & management areas
    o Control and analysis of the operation of the Border Gateway Protocol
    (BGP) including the setting and activation of policies related to
    the protocol.
    o Control, optimization, and choice of traffic exit points from
    networks based on more information than provided by the dynamic
    control plane.
    o Distributed reaction to network-based attacks through rapid
    modification of the control plane behavior to reroute traffic for
    one destination while leaving standard mechanisms (filters, metrics,
    and policy) in place for other routes.
    o Service layer routing to improve on existing hub-and-spoke traffic.
    o The ability to extract information about topology from the network. These
    models will be based on a generic topology model to support multiple uses.
    Injection and creation of topology will not be considered as an initial work item.

Other use cases may be adopted by the working group only through
rechartering.

  • Abstract information models and Yang Data Models consistent with the use cases.

  • Requirements for I2RS protocols and encoding languages.

  • An analysis of existing IETF and other protocols and encoding
    languages against the requirements.