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

Russ White <> Thu, 02 August 2012 05:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FBA721F8A0A for <>; Wed, 1 Aug 2012 22:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iZR-1qUGJYFF for <>; Wed, 1 Aug 2012 22:25:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA36821F8A09 for <>; Wed, 1 Aug 2012 22:25:58 -0700 (PDT)
Received: from ([]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1Swnv4-0003lT-Ku; Wed, 01 Aug 2012 22:25:58 -0700
Message-ID: <>
Date: Thu, 02 Aug 2012 01:26:06 -0400
From: Russ White <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Susan Hares <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Cc: "" <>
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: Thu, 02 Aug 2012 05:25:59 -0000

> ----> [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. 

If we just insert the information into "yet another process" parallel
with the already existing routing processes on the hardware, I think we
shunt aside the problems with insertion speed, etc. Routes installed in
this "off board interface routing process" would be handled just like
routes learned through other sources. Any improvements in the speed of
route insertion from, say, OSPF running on the box would be reflected in
speed improvements for IRS. IMHO, this is a huge win overall.

> One
> difference, though, is the idea that different static routes installed
> by IRS may want to have different preference values.

All the implementations I've worked with have the ability to install
routes from a single process with different preferences. If no
preference is specifically stated, the process' preference is used.
Specific per route preferences override these, though --see, for
instance, the EIGRP distance command in IOS. I suspect all
implementations have the ability to handle this sort of thing in the API
between each routing process and the RIB, but it's just not used a lot.