1. Interface to Routing System (I2RS)
Special Topic: Software Defined Networks
Rudra Dutta
Computer Science, NCSU
Some slides from IETF WG, OldDog, Raj Jain

2. Perspective IETF function: standardize enablement Standardize
Make possible re-use, re-purpose
Not re-invent wheel many ways
Ecosystem for all comers (and newcomers), not only silo’d incumbents
Enablement
If something is desired to be done by a lot of folks, one or few standardized ways to do it is desirable
If a use case is desired by a small group, not necessarily priority
Not smart solutions, but general-purpose solution enablement (simpler is better)  can be built on
Copyright Rudra Dutta, CSC, NCSU, Spring 2017

3. IETF SDN What is the main problem (/usecase/desire) ?
“Programmable agile routing plane”
I2RS community do not see enhanced forwarding engine as part of the (or this) problem
Can be done with labels, or tunnels
Accordingly, “network-level policy” becomes essentially “routing policy”
(What about smarter, flow-/application-specific logic on intermediate nodes?
Possibly not the domain of SDN  NFV or SFC)
Copyright Rudra Dutta, CSC, NCSU, Spring 2017

4. The Problem
Facilitate (enable) real-time or event driven interaction with the routing system
Need control / management interfaces
Need standardized collection of protocols
Question becomes:
What should the interfaces be?
What should it “talk to”, what should be able to “say”?
What should the protocol “vocabulary” be?
What should the wire format embedding be?
Copyright Rudra Dutta, CSC, NCSU, Spring 2017

5. Copyright Rudra Dutta, CSC, NCSU, Spring 2017

6. I2RS Evolution Working group created late 2012
Initially called IRS, later change of name
Early emphasis on having a minimal (frequently used) usecase set
Drafts and RFCs targeted to:
Problem Statement
Use Cases
High level Arch
Protocol Requirements
Encoding Language Reqs
Information Models
Analysis of Existing Protocols...
Drafts as early as 2012, first RFCs mid-2016
Copyright Rudra Dutta, CSC, NCSU, Spring 2017

7. Orientation and Usecases
Early set of usecases
Programming the Routing Information Base
For example, adding static routes
Setting routing policy
Control how the FIB is built
Other router policies
Modify BGP import/export policies
Topology extraction
Pull routing information (including SRLGs) from network
Topology management
Create virtual links by making connections in lower layers
Service management
Request LSPs, connections, pseudowires
Bandwidth scheduling
“Set up a VPN”
Orientation: largely as previous
Major user is the NMS applications, controllers
Specific use: applications that want to interact with network
Copyright Rudra Dutta, CSC, NCSU, Spring 2017

8. Problem Statement (RFC 7920)
Must provide data-model-driven interface to routing system
I2RS agent in NE, I2RS client in NMS
Must provide framework for applications to register for asynchronous notification
Learn router information, topology
Interface should provide:
Multiple Simultaneous Asynchronous Operations
Very Fine Granularity of Data Locking for Writing
Multi-Headed Control
Duplex
High Throughput
Low Latency
Multiple Channels
Scalable, Filterable Information Access
Secure Control and Access
Extensibility and Interoperability
Copyright Rudra Dutta, CSC, NCSU, Spring 2017

9. Summary - Still in Early Process
An architecture (RFC 7921) has been proposed
Yang has been chosen as a data-model platform
Topology description in Yang is being negotiated in drafts
Hopefully by late 2017 or early 2018 these may become RFCs
Realizations will follow
Copyright Rudra Dutta, CSC, NCSU, Spring 2017