Skip to main content

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

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 2012-12-23
State Start Chartering/Rechartering (Internal Steering Group/IAB Review)
WG State Proposed
IESG Responsible AD Martin Vigoureux
Charter edit AD Adrian Farrel
Send notices to (None)

charter-ietf-i2rs-00-03

Working Group Name:
Interfaces to the Routing System (I2RS)

IETF Area:
Routing Area

Chair(s):
TBD
Routing Area Director(s):
Adrian Farrel
Routing Area Advisor:
Adrian Farrel
Operations Area Advisor:
TBD

Mailing Lists:
General Discussion: i2rs@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/i2rs
Archive: http://www.ietf.org/mail-archive/web/i2rs/current/maillist.html

Description of Working Group:

A routing system is all or part of a routing network. A part of a routing network may be a
single router or a collection of routers. The routing system may be further divided to be
an interface over which data traffic is forwarded, or a collection of such interfaces. The
routing system also includes the control plane protocols that operate the routers.

I2RS facilitates real-time or event driven interaction with the routing system through a
collection of control or management interfaces. These allow information, policies, and
operational parameters to be injected into and retrieved (as read or 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 working group works to develop a framework and architecture that will
enable specific use cases, and lead to an understanding of the informational models
and requirements for encodings and protocols. 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 successfully. Initial work within the working group will be limited to
within a single administrative domain.

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

  • Architecture and framework for I2RS including considerations of policy and security

  • Tightly scoped key use cases for operational use of I2RS. These use cases will include
    at least:
    o Interactions with the RIB. Allowing read and write access to the RIB and to the
    policies used to construct the FIB, but no direct access to the FIB.
    o Control and analysis of the operation of 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 quickly modification of the
    control plane behavior to reroute traffic for one destination while leaving a 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. 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 after milestones have been added
    to the charter page.

  • Abstract information 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.

The working group is not currently chartered to develop protocols, encoding languages, or
data models. The objective of this work effort is to arrive at common standards for these
items, but these items are dependent on the progress of the topics listed above. Work for
these items will be conducted in this working group only after a re-charter, and/or may be
carried out in another working group with specific responsibility for the protocol or encoding
language.

Goals and Milestones:

Jul 2013 : Request publication of an Informational document defining the problem statement
Jul 2013 : Request publication of an Informational document defining the architecture framework
Aug 2013 : Request publication of Informational documents describbing use cases
Sep 2013 : Request publication of an Informational document defining the protocol requirements
Sep 2013 : Request publication of an Informational document defining encoding language requirements
Nov 2013 : Request publication of Standards Track documents specifying information models
Nov 2013 : Request publication of an Informational document providing an analysis of existing IETF
and other protocols and encoding languages against the requirements
Dec 2013 : Consider re-chartering