[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Aggregation Implies Provider Dependence // Re: [RRG] ALT's strong aggregation often leads to *very* long paths
> From: Scott Brim <swb@employees.org>
> ALT has nothing to do with delegation, it's about reachability of
> mapping information. EID prefixes are allocated by some means, which
> could (probably will) be completely independent of the ALT
> infrastructure.
I think Joel understood that...
> The possible lock-in problem is not about EID allocation, but about ALT
> connection. ... the ISP says "well, you were a customer and you're
> leaving, so I'm going to make it hard for you to do so by refusing to
> accept connections from your new ETRs".
As I understand him, this is what Joel was concerned about: given that
someone has a chunk of EID namespace allocated to them, how can they avoid
'lock-in' to those entities which are providing bindings for that part of the
namespace (to the network as a whole)?
I'm not sure how significant a problem this will be; right now people are
'locked in' to whoever it is serves up the records for entries in the .COM
domain (which is of course separate from the many entities which are allowed
to *sell* names in that namespace - AFAIK, there's a single authoritative
registry), but that doesn't seem to be a colossal issue.
Sure, it's not hard to provide for multiple alternatives at any pseudo-node
in the binding-provision hierarchy (e.g. CONS already allows a pseudo-node to
be composed of multiple machines, which could potentially be run by different
entities). But is it worth the extra complexity?
I don't have *any* axe to grind here; whatever the user community decides is
the 'right thing' is fine with me. If people think 'lock-in' is enough of an
issue that we need to make provision for competition, fine - just realize
there may be some additional complexity as a result..
Noel
--
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