Re: [irs-discuss] Thoughts on draft-ward-irs-framework

Susan Hares <> Wed, 01 August 2012 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AC6511E809B for <>; Wed, 1 Aug 2012 12:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.177
X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DvaExfIaw+8Q for <>; Wed, 1 Aug 2012 12:40:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8955011E80A3 for <>; Wed, 1 Aug 2012 12:40:48 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.2.3-GA FastPath) with ESMTP id AII48369; Wed, 01 Aug 2012 11:40:48 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 12:38:06 -0700
Received: from ([]) by ([]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 12:38:00 -0700
From: Susan Hares <>
To: Russ White <>, "" <>
Thread-Topic: [irs-discuss] Thoughts on draft-ward-irs-framework
Thread-Index: AQHNb36MjASCLFSBKk6d1/vhypXJiJdFQeBA
Date: Wed, 1 Aug 2012 19:38:00 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Aug 2012 19:40:49 -0000


-----Original Message-----
From: [] On Behalf Of Russ White
Sent: Tuesday, July 31, 2012 5:42 PM
Subject: [irs-discuss] Thoughts on draft-ward-irs-framework

This framework is well put together, but I'd like to make a couple of
suggestions/comments/put some ideas forward.

1. I think the draft struggles somewhat with describing something that's
already in all routers today because it's attempting to describe an
interface into the RIB that's somehow separate, or stands beside, the
existing interfaces into the RIB. I would gently suggest that describing
this entire idea as an "off board routing process," much like a BGP
process on an existing implementation, might clarify things a bit, and
make the model easier to understand.

Consider --any given routing process already installs routes into the
routing table, including the concept of preference. BGP routing
processes, specifically, also have import and export capabilities into
various VRFs. All routing processes also have redistribution capabilities.

What if you modeled this entire thing as two types of "off board routing
processes," one that only imports data from the RIB for northbound
consumption (topology information), and one that interacts with the RIB
like any other routing process would for southbound control as well as
northbound consumption?

----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN.  And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important. 

It's going to be much easier to interact with the other routing
protocols on the box without a lot of "special pleading" if IRS is a
process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of
link down notifications --all the implementations I know of process link
downs in the RIB, and the RIB then notifies the routing protocol... If
you're hooking into the RIB locally, then, you need to hook into link
down detection specifically and intentionally. If IRS is a routing
process, the RIB will notify the northbound interface as a matter of
course in processing link down notifications.

I hope that makes sense, but I'm glad to sit and discuss if it doesn't.

2. There needs to be a way to mark routes inserted in the RIB with a
process ID of some sort. This would come naturally if the entire IRS
idea were to put an "off board routing process" on the box that
interacts with existing on board processes (see #1 above), but as the
draft stands, there's no way to insert a process id into the RIB. This
is crucial for redistribution, and I suspect redistribution is going to
be a huge problem to address in the long term, since the routes injected
by IRS, however they're injected, will need to interact with the dynamic
protocols running on the box.

[Sue] See our work on Route servers (1990-1995) and current work - for an example.
This is what I mentioned above. 

3. There are a ton of other possible use cases, if more are
needed/wanted to support the reasoning behind the draft. Choosing the
optimal exit from any given edge (OER in cisco lingo), a superset of
Flowspec to combat DDoS is another (mentioned tangentially, but not as a
use case), live/live is another (packet replication and choosing the
best of two identical streams) --and there are others... Some of these
might actually be more interesting use cases than are currently
described in the draft.

More if I get the chance to reread it in a little more depth later.

Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.


irs-discuss mailing list