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

Re: [RRG] incrementally deployable

Thus spake "David Williamson" <dlw+rrg@tellme.com>

On Fri, Nov 09, 2007 at 08:57:08AM -0800, Darrel Lewis (darlewis) wrote:

What if a 3rd party provides a proxy between the two systems,
then incremental deployment is possible. Then networks who
are not LISP capable can reach EIDs that are not in the global
Routing table.
Technically, if there were anycast ITRs, then all EIDs would be in the DFZ, albeit in aggregated form. For instance, say we decided v6 EIDs would be in 4000::/3; every anycast ITR would advertise that prefix, providing reachability from sites without their own ITR. Or, if each set of ITRs only handled part of the EID range (say, each RIR maintained a separate database), then they'd provide an anycast advertisement for their part. 


That's certainly a form of incremental deployment, and I alluded to
it in my original message.  The real question is if that's sufficient for
a wide majority of business models.  I'll take my own org as an
example: we run an extremely reliable service, but we have
dependencies on reaching customers and partners for content of
various types.  Much of that runs across direct private connections,
so there's really no impact from LISP.  Some of it, however, is over
the Internet.

Would a 3rd party proxy be sufficiently robust and reliable to permit
me to make my site LISP capable and still have the level of
connectivity my business requires to those customers?  That's a very
hard quesiton to answer.  I'm not saying it's out of the question, but
it's a very troublesome additional piece of complexity for a service
provider to contemplate.  I honestly don't know the answer right now.
The concept is palatable, but it would depend on the business features
of a 3rd party product.
And that, in turn, depends on who is providing those public ITRs. Logically, the RIRs are the best folks to be keeping copies of the EID-to-RLOC mappings since they already maintain all sorts of databases about RLOCs and would probably be the folks handing out EIDs as well. The RIRs, then, are the logical providers of ITRs-of-last-resort. They might provide the public ITRs themselves, or contract with a large number of default-free ISPs -- or CDNs -- to provide ITRs. That's up to them to figure out. 


Alternatively, what if an xTR performs NAT between PA space
and EID space?


Where would PI fit in this?  Renumbering into PA space isn't a viable
option at the moment.  I don't think I quite see the entire implications
here, yet.
PI is still new in v6; ARIN has only handed out ~100 blocks as of last month, all out of an easily-identified prefix (2620:0000::/23). It'd be easy enough to redefine that as an EID block, or to deprecate assignments from that block and give them a different block (out of a top-level IANA block) designated for EIDs. 

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking 


--
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