[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Thoughts on the RRG/Routing Space Problem
Thus spake "Robin Whittle" <rw@firstpr.com.au>
I hadn't considered the cost of equipment. I figure the ITRs are
paid for, in general, by the ISPs where they are located - tunneling
packets originating from the ISP's customers' hosts.
That's one option. See below for my take.
For an end-user who gains some of the new kind of address
space provided by the ITR-ETR (AKA map&encap) system, the
ETR(s) their traffic flows through would be owned and operated
by the ISP(s) which they connect to the net with. ETRs are going
to be pretty simple compared to ITRs - they don't need an FIB, a
database or a feed of mapping data (or access to a query
server, if they are caching ITRs).
Now that's interesting... ISPs seemingly have little motivation to operate
ETRs because they defeat customer lock-in.
I'd rather run my own ETR(s). Since it's a brain-dead simple function, I
expect to see that make its way into even the cheapest CPE. Ideally, I'd
set my ETR(s) up with RLOCs from each upstream ISP (perhaps obtained via PPP
or DHCP), set the mappings in the database, and be ready to rock. My ISPs
wouldn't necessarily even realize I was using one.
So the end-user doesn't need to purchase or run ITRs or ETRs in
order to use the new kind of address space.
Their network may well include ITRs - to ensure the tunneling work
on outgoing packets is done locally and doesn't depend on anything
upstream, which is shared by others. But that would be the case
irrespective of whether the end-user's network uses the new kind of
address space.
We need some way to make sure that either (a) every default-free entity
(including, but not limited to, ISPs) runs an ITR, or (b) there are EID
aggregates in the DFZ (most likely anycasted, but perhaps not). The latter
seems more achievable, but the question is who pays to install and run them.
The most logical answer answer is "whoever issues EID space", which for the
sake of argument let's call the RIRs. However, those "ITRs of last resort"
are going to be overwhelmed if map&encap is even moderately successful, and
ISPs would be motivated to provide their own (presumably closer and more
robust) ITRs to improve performance and keep customers happy.
Customers running caching ITRs may happen, but I'm doubtful we'll see
full-database ITRs at many customer sites. The largest may get the latter,
but it's too much to ask for Linksys et al to put that in $50 consumer
boxes; even a caching ITR may be too much complexity.
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