[41210] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: multi-homing fixes

daemon@ATHENA.MIT.EDU (Alex Bligh)
Fri Aug 31 11:34:37 2001

Date: Fri, 31 Aug 2001 16:32:17 +0100
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: "Sean M. Doran" <smd@clock.org>, alex@alex.org.uk
Cc: nanog@merit.edu, Alex Bligh <alex@alex.org.uk>
Message-ID: <81446704.999275537@[10.132.112.53]>
In-Reply-To: <20010831151128.ADF7FC7901@cesium.clock.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Errors-To: owner-nanog-outgoing@merit.edu


--On Friday, August 31, 2001 8:11 AM -0700 "Sean M. Doran" <smd@clock.org> 
wrote:

> See what I mean by it being a compression system for more specifics?

Sure, if the supernet & more specifics update atomically, you get
a processing gain as well as a space / b/w gain, as you process a
set of identical NLRI's in one shot (and heh, processing a
route flap of ^701$ in one shot, can't be a bad thing, and
a sh ip b pat or equivalent will demonstrate most routers
carry tables of unique attribute sets anyway).

However, I had rather assumed the point of these so-called TE
more-specifics (where there are some) is that they don't all
update atomically. Then you need code to split them out and
put them back together again, and though you are doing better
on bandwidth for the updates (which is not a problem anyway)
you are doing worse on space & processor power.

I may be missing something.

--
Alex Bligh
Personal Capacity

home help back first fref pref prev next nref lref last post