[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Thoughts on the RRG/Routing Space Problem
Excerpts from Robin Whittle on Tue, Dec 04, 2007 11:52:43AM +1100:
> The MAB, UAB and micronet terminology I use here is discussed in:
> http://psg.com/lists/rrg/2007/msg00533.html
> http://psg.com/lists/rrg/2007/msg00535.html
iirc a MAB is an aggregate of addresses that are not globally routed,
a "micronet" is a chunk of addresses within that, which need not be on
a power-of-2 boundary, and a UAB is somewhere in the middle. For MAB,
I think it's just as easy to say what you mean. For "UAB" and
"micronet", we have tried non-power-of-2 alignment in the past and it
has been a big problem. We ended up with CIDR on power-of-2
boundaries for a good reason. The term for a chunk of addresses
aligned on a power-of-2 boundary is a prefix. We've been using this
for over 20 years. Finally, the labels "M" and "U" unnecessarily
assume a simple two-tier system. So just use "prefix". It's
established, it's easier, it's more general purpose where we need it
to be and more specific where we need it to be.
> Scott Brim wrote:
> > While core routing/forwarding is untouched by granularity, there
> > will be more prefix mappings in ITRs. There are several things
> > that mitigate that. First, if there is any "pull" at all in the
> > mapping system, an ITR only has mappings it uses, so small sites
> > that only connect to a few places can have small ITRs. Second,
> > an ITR need not cache everything if there is a mapping node
> > nearby that will do the caching for it. Third ... well, I just
> > woke up with melatonin in my brain, so it isn't quite working
> > 100% yet, but there are mitigation techniques in all the various
> > schemes.
>
> Another mitigation technique is a full database (push) ITR reducing
> the cost of handling every mapping update in the world by updating
> its RIB with only those updates which are required by the current
> traffic.
So the full database is pushed to start with, and incremental updates
follow based on observed traffic? To start with, we should assume at
least hundreds of millions of prefix mappings. Second, regarding the
incremental updates, how is the incremental update triggered? Does
the ITR ask for an update when it notices it is sending packets to a
prefix for which it has a stale mapping entry? If so, how is this
different from an LRU cache? Does some upstream router notice, and
tell the mapping system to push an update? If so, why bother when the
ITR itself knows best what it needs?
> A MAB is advertised by many ITRs - I think "anycast" is an
> appropriate term for this:
The appropriate term is "routing" :-). Common use of anycast
overwhelmingly refers to routing and forwarding to an endpoint.
> But that doesn't require any new distinction beyond the fact that
> there would be some list or database in the ITR-ETR system listing
> all the MABs.
This is not required either.
swb
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg