[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] LISP and IP Interworking
Darrel,
On 2007-12-06 10:59, Darrel Lewis (darlewis) wrote:
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
<snip>
There's something I don't understand about your model.
You assert that the DFZ only contains routes for RLOCs.
But today the DFZ only contains routes for EIDs, in reality.
Don't you need to either operate with two co-existing DFZs
(DFZ-old with EID routes, and DFZ-new with RLOC routes), or
distinguish the two kinds of routes within a single DFZ?
I'm not sure I completely follow the above. There is only one DFZ, this
is the global routing table of today. When LISP sites are added, their
EIDs may not be found in the DFZ. The draft defines those as LISP-Non
Routable, or 'LISP-NR' sites.
I think there's inevitable confusion caused by LISP's use of the term
"EID" to refer to addresses (or rather prefixes) that are in fact
locators, but ones that it is desired not to route globally. The fact
is that the current Internet uses such prefixes for global routing.
That's what I mean by saying that today's DFZ contains nothing but
EIDs in the LISP sense of the term. In the LISP theory, tomorrow's
DFZ contains nothing but RLOCs, i.e. locators that it is desired
to route globally. I'm trying to understand how your model allows
a highly stepwise change from today's DFZ to LISP's DFZ without
any connectivity failures along the way (and we're presumably talking
about a process that will take at least ten years, overlapping
with IPv6 deployment).
One way to provide reachability to those LISP-NR sites is to have Proxy
Tunnel Routers that take LISP-NR EIDs, summarize them, and announce
these summaries into the DFZ.
Which DFZ? The DFZ starts out containing 100% EID prefixes, summarized
as much as BGP4 policies allow. I can only interpret your statement as
referring to some new DFZ running in parallel to that old one.
This should lead to far fewer routing
entries compared to just having LISP-NR sites redistribute their EIDs
into the DFZ themselves. Note that this will increase stretch to
connections between non-LISP sites and LISP-NR sites - depending on how
widespread PTRs are deployed.
Lets say for example new LISP sites are allocated prefixes (EIDs) from
223.0.0.0/8. Hundreds of sites have subnets of various lengths are
allocated from within this range. The PTR, however, only has to
announce 223.0.0.0/8. Traffic engineering to LISP-NR sites is handled
via the LISP system. PTRs encapsulate then send towards those site's
RLOCs.
The PTRs will act as interworking units between DFZ-old and
DFZ-new, and I guess that as this gets deployed, DFZ-old will
fragment and be reduced to stubs.
I think your DFZ-new above is the LISP mapping system.
No, it's the DFZ that the LISP map points into. I don't understand
how that can fail to be logically disjoint from the existing DFZ,
which contains routes to unmapped prefixes.
Brian
So there is the
global routing table, the DFZ, and a mapping system. The Mapping System
does not follow topology, it follows allocations. The mapping system
does not imply reachability, it merely holds subscription time
interconnection mapping data. Thus the mapping system should have much
different scaling characteristics than the current global DFZ (your
DFZ-old above).
Hmm. It's beginning to seem familiar. Change the captions and
it's page 7 of http://www.cs.auckland.ac.nz/~brian/layers.pdf,
or I have misunderstood your model completely.
I think we've not reached an understanding yet! Thanks for your
comments.
-Darrel
--
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