Re: [i2rs] I2RS Implementation

["Susan Hares" <[e-mail]>]

Edwin: 

 

Thank you for your patience. I am thrilled that you have decided to make an I2RS implementation.



Did you find the slides that I attached on the hackathon site?   

1.       What means “Most helpful failure” that I2RS won at IETF94 hackathon 

2.        Why it failed? – we did not get the ODL environment up.  Initial input had been that the ODL environment had RESTCONF, Topology models, and RIB, 

3.        We are considering to implement it for BIRD (or Quagga). Do you know any other implementation effort?

 

I would suggest that the most important thing is to setting the ODL environment, Linux OS, and then pick the routing work.  I believe that ODL is using Quagga, but that BIRD can also be used. 

 

Since the I2RS RIB, I2RS Topology models, and I2RS FB can be directly implement as calls to a kernel directly (route/add)  or as extended static, we might want to start by setting on Quagga. 

 

Details on the Hackathon 

 

The I2RS protocol hack-a-thon team won a prize for its hack-a-thon work.  The members of the hack-a-thon team were Susan Hares (Huawei, lead) Jie Dong (Huawei), Alia Atlas, Hariharan Ananthakrishnan (Packet-design), and Ignas Bagdonas (consultant).  

 

Goal: The goal of the I2RS protocol hack-a-thon project was to create an application with 2 I2RS Clients which communicated with an I2RS Agent.  I2RS Client 1 would set a route in the I2RS RIB in the I2RS Agent, and request publication of route change information from the I2RS Agent to be sent to I2RS Client 2.   (see the diagram below) 

 

Code base: 

The code base for this hack-a-thon project was the ODL project.  The I2RS project was able to create Yang modules, but failed to create an ODL environment.   The reason we choose ODL is that the Cisco team (Jan Medved and others) have done considerable instrumentation of the Topology Data models in ODL.  We hope to leverage their work. 

 

Next steps: The I2RS project for hack-a-thon at IETF 95 will need to spend time creating the ODL environment ahead of time.  

 

Insights gained: The group’s work at the IETF 94 hackathon caused the I2RS project team to realize that the I2RS protocol work has two components: configuration and reporting of analytical data such as “route changes”.  The I2RS protocol work to-date has focused on the RESTCONF/NETCONF capabilities for configuration, query/poll information, and subscription configuration.  It has not focused on the reporting of route changes via other publication methods (ipfix, google protocol buffers, or other mechanisms).  The I2RS team realized that the secondary pathways to send analytical data (such as topology or route changes) need to be included in the first round of the protocol and data models.

 

We would really like to have you consider working on configuration (RESTCONF/NETCONF) with the ODL, Quagga/Bird, and an analytic tools.   For example, let’s try developing a DOS that is based on detection of a bad prefix and then installing a static route.  

 

Why the win: 

The I2RS team won an award for gaining this understanding that we had not paid enough attention to the analytical channel.  The I2RS WG will solicit WG drafts with these application notes in order to provide a “hand-book” for creating I2RS applications. 

 

Details on the I2RS Steps to Create Application 

In order to create this application, the I2RS hack-a-thon project needed to:  

1.       Compile all the I2RS modules (RIB, Topology (L1/L2) and FB-RIB) with web-compile (successfully completed) 

2.       Create an ODL environment and place the I2RS modules in the ODL environment (failed) 

3.       Create an ODL-based I2RS client (Client 1) that can send an I2RS RIB Route Add, and subscription for I2RS Route Change via RESTCONF, 

4.       Create an I2RS Agent that receives the I2RS RIB Route Add and I2RS RIB Route Change notification from I2RS Client 1.  The I2RS agent then adds routes to the I2RS RIB and the Ubuntu Linux kernel.  The I2RS agent saves subscription information.   

5.        A route change is triggered by configuring the interface down that the I2RS RIB route is associated with. 

•                                 The I2RS Agent should send the route change information over the grpc. .   Note: Alternatives to google protocol buffers are google protocol buffers, IPFIX, NETFLOW and other protocols. 

                                    Next Step 

•                                 Prior to IETF-95 Hack-a-thon, a prototype of this work should be created on an ODL platform, 

•                                 Cisco, Juniper, Packet-design, and others are interested in an I2RS project in ODL. 

•                                 Expand the route change information to include IPFIX or other high-bandwidth protocols that 

 


	
	 	
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I look forward to your feedback and comments. 

 

Sue Hares 

 

From: i2rs [mailto:[e-mail]] On Behalf Of Edwin Cordeiro
Sent: Wednesday, December 16, 2015 10:44 AM
To: [e-mail]
Subject: [i2rs] I2RS Implementation

 

Hello all,

 

A couple weeks ago, I sent a message asking about the IETF 94 Hackaton results related to I2RS, but got no reply. As I was also unable to find any implementation, we decided to make one here at TU Munich.

 

In order to avoid the same known problems discovered at the Hackaton, could anyone please clarify what happened:

1. What means “Most Helpful Failure” that I2RS won IETF 94 Hackaton?

2. Why it failed?

3. We are considering to implement it for BIRD (or Quagga). Do you know any other implementation effort?

 

Thank you all,


Edwin Cordeiro