Re: [RRG] Thoughts on the RRG/Routing Space Problem

[Scott Brim <swb@employees.org>]

Excerpts from Stephen Sprunk on Tue, Dec 04, 2007 07:39:19PM -0600:
> Now that's interesting...  ISPs seemingly have little motivation to
> operate ETRs because they defeat customer lock-in.

First, if a customer is numbered out of a prefix allocated to an ISP,
it can't just up and move its sub-prefix arbitrarily, with or without
an ETR.  So I don't think what you say is true.  Second, it can be the
other way around (idea from Eliot).  If an ISP offers a customer the
chance to connect via an ETR, then the customer can multihome without
having to negotiate about injecting a longer prefix.

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

Me too.

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

Do you mean "EID aggregator", like a proxy tunnel router?

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

As for being overwhelmed, a particular "DFZ ITR" (PTR) need not handle
the entire EID address domain.  How to split things up, and where to
place them, should depend on real operation considerations.

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

Very very very few houses would need a full cache.

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