[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Idea for shooting down
Scott,
On 2007-12-06 15:40, Scott Brim wrote:
Excerpts from Brian E Carpenter on Fri, Nov 23, 2007 09:59:59AM +1300:
On 2007-11-23 01:13, Iljitsch van Beijnum wrote:
On 19 nov 2007, at 22:59, Brian E Carpenter wrote:
http://www.cs.auckland.ac.nz/~brian/DFZng.pdf
I don't understand how this works... Would ISPs at each level aggregate
the address prefixes used at the level below, or would addressing be
completely separate from the hierarchy so some kind of
mapping/encapsulation would need to happen?
The second case. There would not only be a separate instantiation of
BGP4 in each region, but also a separate instantiation of (e.g.)
LISP-ALT. The idea is to recurse the whole model (EGP and locator-locator
mapping). ((Er, LISP EIDs are a special case of locator as far as
I'm concerned.))
Brian, I believe the goal is to reduce the number of map entries that
an ETR might want to cache. However, the lookup key for a cache entry
is the ultimate prefix. Reducing the number of ETRs doesn't help. If
I understand your scheme, reducing the number of entries depends on
prefixes being more aggregatable as you bring in your higher levels of
ETRs. There will certainly be some aggregation if "regional" IRs
continue to allocate address blocks, but there will always be
outliers, for example when a USA oil company relocates to Kazakhstan.
So your scheme helps if address allocation is constrained to follow
topology ... but if that's true then the problem I think you solve
doesn't arise.
Firstly, it certainly doesn't make the map smaller; in fact the
entries get slightly bigger and there will be a small proportion
of additional entries at the higher levels of the hierarchy.
However, it doesn't assume a rigid correspondence between
the topology of the regions and the addressing structure;
by recursing the LISP (or equivalent) model at each level,
you avoid that.
So based on what you say above, I no longer think I understand what
problem you solve.
It seems pretty clear to me that just as pollution/entropy has arisen
naturally in the current DFZ, the same thing will happen in the
cleaned-up DFZ that LISP will initially create. And as we grow
the network to billions of nodes and many thousands of RLOCs, that
problem may need solving. Recursing the model seems to be the
only way to do so.
I like the PTR model you mention below, but what happens when
you need PTRs to clean up mess among the RLOCs? You recurse.
Brian
Excerpts from Iljitsch van Beijnum on Sat, Nov 24, 2007 10:47:50PM +0100:
Since you ask: what I would like to see is a combination of something from
the LISP family combined with a hierarchical mechanism like CRIO that
allows packets for which there is no mapping yet to be delivered through
increased stretch.
Take a look at the LISP interworking draft.
http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt
Does that do what you want?
CRIO had "destination-side" default routers (my terminology), serving
particular destination prefixes on behalf of all sources. The other
model is to be more "source-side", serving all destinations on behalf
of a particular set of sources. An intermediary like you want can be
either, depending on deployment optimizations. The LISP interworking
draft calls them proxy tunnel routers.
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
--
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