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

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

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

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

Copyright Rudra Dutta, CSC, NCSU, Spring 2017

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

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

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

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