Traditionally, routing protocols running on a router will perform calculations to determine the best forwarding path. The RIB with be then populated with next-hop information. Ultimately, that information will be populated into the FIB (forwarding information base), the FIB taking the guesswork of how to get to the next hop and easing CPU utilization on routers in the case of recursive lookups.
But what if there’s some unusual forwarding requirement you have on your network? What if you want to do influence traffic direction beyond the normal scope of your routing protocols’ computations? There are a number of ways to skirt routing protocol behavior – policy based routing, for instance. But how well do these workarounds scale? And in what ways can they be automated, or react to changing circumstances on the network? There is no scalable, ready solution in this space, and this is where I2RS comes in.
I2RS is an IETF draft that stands for “Interface to the Routing System.” The general idea is to provide a interface that shims in between routing protocols such BGP & OSPF and the RIB (routing information base) on a router, influencing the routing table in a programmatic way.
Joel Halpern, Distinguished Engineer at Ericsson and Russ White, CiscoPress author and Principal Engineer also at Ericsson have been closely tied to the development of I2RS, and join hosts Ethan Banks & Greg Ferro in this discussion about I2RS. We explore just what I2RS hopes to accomplish, the drivers for I2RS, and some potential use cases.
- I2RS Problem Statement
- I2RS Traceability: Framework & Model Information
- I2RS Protocol Independent Use Cases
- I2RS Topology API Use Cases
- RIBs & FIBs (Ivan Pepelnjak)