[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] IPv4/6/ngng or IPv4-map-encap then IPngng
I don't really want to wade into this debate but I want to set the record
straight on one point:
> That was my way of improving LISP, to create the beginnings of my
> Ivip proposal, on 2007-06-15:
>
> http://www.ietf.org/mail-archive/web/ram/current/msg01518.html
>
> Before that LISP had no way of being introduced with multihoming of
> communications from non-upgraded networks. (Late last year LISP
> became able to do this, by adopting Proxy Tunnel Routers which do
> the same job as my poorly named "anycast ITRs in the core" - now
> "Open ITRs in the DFZ".)
Not correct. The first documentation of what was later fleshed-out as LISP+ALT
and LISP PTRs (proxy tunnel routers) occurred on a Cisco-internal mailing
list in April, 2007. This discussion was later opened to the RAM list in
June, 2007 (see attached email message, which includes both references).
The terminology has changed somewhat since these discussions by the basic
ideas remain the same.
The concepts originated during a lunch conversation at IETF-67 in November,
2006 but were not written down or propagated beyond the LISP co-authoers
until much later.
Just wanted to set the record straight.
--Vince
Date: Wed, 20 Jun 2007 11:35:47 -0700
From: Vince Fuller <vaf@cisco.com>
To: ram@iab.org
Subject: [RAM] Preliminary thoughts on LISP 1.5
Message-ID: <20070620183547.GA24174@cisco.com>
Since there seems to be some ongoing discussion of LISP and whether or not it
is incrementally deployable, I thought I'd share the following message which
I wrote to a smaller discussion group about two months ago; it sketches out
some ideas on how a LISP 1.5 infrastructure might offer a hybrid push/pull
model, where highly-aggregated EID prefixes would be "pushed" into a global
infrastructure while information about specific destinations of interest to
a particular source would be "pulled" in a data-triggered manner using LISP 1.0
protocol machinery.
The LISP authors plan to write-up a more complete Internet Draft describing
this approach but here are some conceptual ideas.
--Vince
--------------------
Date: Wed, 4 Apr 2007 09:54:41 -0700
From: Vince Fuller <vaf@cisco.com>
Subject: Re: Cache
...
> > The thinking here was that the ITR could be co-located with a local
> > DNS caching server, and have all of the hosts served by an ITR use
> > that same system for DNS lookups.
>
> That strikes me as a set of extremely unrealistic deployment constraints.
Note that this approach is specific to LISP 2 and resresents some thinking
on how one would improve EID-to-RLOC setup latency when a mapping doesn't
exist for a particular destination.
> > There are obvious ways of attacking the rate * state product. You
> > can decrease the rate by distribution. You can decrease the state
> > by going to a pull model.
>
> The most obvious way of reducing the amount of data is by aggregation, of
> course. I guess we're looking for alternative methods that don't introduce
> enormous amounts of complexity. Well, I hope we're wishing ourselves luck
> ;-)
>
> Certainly if you distribute the data so that it is never all in one place,
> you improve the per-box scalability, since each box has less to worry
> about. Of course, you might end up needing more boxes. It's never been
> clear to me whether a solution which increases the number of boxes rather
> than the size of each box would be considered as "solving the problem".
>
> To first order, I don't think that "pull vs. push" is an important
> distinction, since it leaves open the question of where you're pulling from
> and whether that is scalable. Also, if you distribute the data, you don't
> necessarily need a pull model, you just need to make sure that the data
> paths take each packet through a place where the appropriate data can be
> found (i.e., if the addressing doesn't follow the topology, make the
> topology follow the addressing).
This approach is similar to some thoughts that I've had on how an EID-to-RLOC
overlay topology might be structured for LISP 1.5. The idea is roughly as
follows:
1. Assign EID prefixes according to some hierarchy that bears only rough
resemblence to the actual Internet topology. An RIR, exchange-point, or
geographic hierarchy is probably good enough here. One that approximately
follows DNS delegations would also work. It is probably even possible to
construct a hybrid of more than one of these, at a cost of requiring a
larger number of "top level" EID prefixes.
2. Build an overlay topology of EID-to-RLOC "LISP translation aggregators"
(LTAs) which matches the hierarchy in (1). This topology may contain one
or more layers of aggregation, depending on size and scope. LTAs are
interconnected by tunnels in a topology that is isomorphic with the
prefix assignment hierarchy, with redundancy.
3. For each ETR that holds an authorative EID-to-RLOC mapping for a
prefix, configure one or more tunnels to the LTAs which can aggregate
that prefix with others at the same point in the assignment hierarchy.
The ETR advertises the existance of that EID-to-RLOC mapping using some
protocol (BGP, with a separate AFI/SAFI for LISP would work).
4. LTAs aggregate and propagate mappings "upward" toward the root of the
assignment hierarchy.
5. For each ITR, confgure one or more tunnels to LTAs. The LTAs advertise
the aggregated EID-to-RLOC mappings to the ITR over the tunnel(s). Exactly
which LTAs a particular ITR uses depends on the level of detail about
the global EID-to-RLOC mapping database that it wishes to have "pushed"
to it (again, consider BGP with a separate AFI/SAFI for LISP). The LTAs
may advertise (or an ITR may/could/should confgure) a "default" mapping
if it wishes to be able to do EID-to-RLOC lookups for any destination
in the global routing system.
6. For backward-compatibility with non-LISP-speakers, some set of LTAs can
advertise their aggregated EID-to-RLOC mappings into into the existing
global routing table. This will draw traffic for those mappings to those
LTAs, which serve as "LISP proxies" for non-LISP-capable devices.
7. When an ITR receives a packet for which it has no EID-to-RLOC mapping,
it forwards that packet according to the aggregated information it
received over its LTA connections. Note that as an implementation detail,
this information, along with its cached EID-to-RLOC mappings, can simply
be stored in the ITR's FIB, perhaps with some special marking to indicate
"EID-to-RLOC mapping" rather than "RLOC forwarding entry". The packet is
forwarded through the LTA/overlay topology until it reaches the ETR that
originally advertised it; that ETR both forwards the packet to the end
system and sends back a specific, cachable EID-to-RLOC mapping to the
ITR which received the original packet and encpsulated it in LISP.
A few things to note:
- This approach does posit the creation of a new, hierarchical LTA
infrastructure which will have associated capital and ongoing operational
costs. Who would build that infrastructure and how they would recover those
costs would depend on where its root achor points are located. Fortunately,
there are existing organizations (with existing cost-recovery mechanisms)
in place for those achors: IANA and the RIRs, the major global exchange
points, etc.
- The exact mechanism for data exchange between and throughout the LTA
infrastructure is an area that needs a lot more thought, experimentation,
etc. One could imagine a number of different approaches: BGP with separate
AFI/SAFI (mentioned above), something DNS-like or using DNS protocols
(think about zone transfer for "push" and DNS queries for "pull"), DHTs,
et alia.
- The LTA infrastructure, the ETR-to-LTA, and ITR-to-LTA protocol exchanges
are the points at which authentication of the EID-to-RLOC database would
most naturally be performed. Adding machinery at those points could address
some of the open issues with LISP security.
All of this is only partially thought-out at this point (not even half-baked
enough to send to the RAM list) and obviously needs more work, perhaps as a
successor to the LISP draft that describes the specifics of LISP 1.5.
Comments? Thoughts?
--Vince
_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram