[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] LISP and IP Interworking



Everyone,

Scott and I had a chat about this today over some software
quaintly referred to as "the telephone."

I don't disagree with anything below. My concern is that
in the long term, we might see a swamp appearing in the
LISP-based DFZ, just as we've seen a swamp appearing in the
pure-BGP-based DFZ in the past (and as the large scale usage
of IPv6 "PI" prefixes would cause in the pure-BGP4+-based
IPv6 DFZ). So I'm suggesting, somewhat clumsily, that we
need to design things in a way that would allow us to recurse
the whole model if and when a swamp appears. Conceptually,
I find that easier to think about in terms of multiple DFZs.
I could be quite wrong, of course.

That being said, it still appears that a complete map is
needed in any case, so the problems that have been discussed
wrt distribution and caching of maps are not significantly
affected.

    Brian

On 2007-12-12 08:42, Scott Brim wrote:
Excerpts from Brian E Carpenter on Sun, Dec 09, 2007 01:14:54PM +1300:
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.

Well, clearly you're not confused by it :-).
If you look in the definition of EID in the LISP draft ...

  The host obtains a destination EID the same way it obtains an
  destination address today, for example through a DNS lookup or SIP
  exchange.  The source EID is obtained via existing mechanisms used
  to set a hosts "local" IP address.

... the overlap is clear.  If we called it an "address", we've seen
that that causes more confusion!  And I don't think you really meant
to imply it, but an EID doesn't refer to a prefix, it's a single
identifier.  "EID Prefix" is what you want to compare there.

The fundamental difference between EIDs and current "addresses" is
routing scope.  In Lixia's terms, EIDs are globally *deliverable* in
the DFZ but not globally *routed* in it.  Therefore the current
Internet is not "nothing but EIDs" in the LISP sense.  Addresses used
now are globally routed.

The point of this whole effort is to enable things like more
multihoming while also making Internet routing work better, for
example by taking prefixes out of global routing.
I think that might be the disconnect.  I suspect you are thinking of
the current Internet and thinking we are sticking a new DFZ in the
middle of it.  Rather, we are taking current Internet routing and
limiting it.  There is and will only be one (public) DFZ.  The
proposal is to take routes out of it.  That doesn't create a new DFZ.

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.

The prefix that is being PTRed is removed from direct DFZ routing, and
is available via PTRs.  It's just as if I changed my site's
connectivity from one AS to another.  Of course this can be done
carefully, so I'm available via PTRs and also via my current
provider, so I don't understand your concern about loss of
connectivity..

Does any of this help?

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