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

Russ White <russw@riw.us> Wed, 01 August 2012 00:42 UTC

Return-Path: <russw@riw.us>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6F62A21F8907 for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 17:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SmeDuo7ka6Vm for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 17:42:24 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net []) by ietfa.amsl.com (Postfix) with ESMTP id 96A9C21F8900 for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 17:42:24 -0700 (PDT)
Received: from dhcp-4151.meeting.ietf.org ([]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <russw@riw.us>) id 1SwN0z-0007aI-W2 for irs-discuss@ietf.org; Tue, 31 Jul 2012 17:42:18 -0700
Message-ID: <50187B55.407@riw.us>
Date: Tue, 31 Jul 2012 20:41:57 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: irs-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Subject: [irs-discuss] Thoughts on draft-ward-irs-framework
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 00:42:25 -0000

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?

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.

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.