[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



Excerpts from Joel M. Halpern on Fri, Feb 08, 2008 10:10:06AM -0500:
> I am not following what you are suggesting.

I'm going to take this step by step.  I think changing one assumption
changes your question a lot.

> As I understand it, the ALT hierarchy is a strict delegation
> hierarchy.  

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.  

> A given ALT node can only connect upwards to the node (or duplicate
> nodes, but they will be under a common administration) 

There is no reason for ALT nodes jointly responsible for reachability
of mapping information in a particular prefix to be under a joint
administration.  They need to behave according to the rules -- accept
information from all authorized nodes below them and pass it on to all
authorized nodes above them -- but they can be run by completely
different organizations.

> that handles the block from which the EIDs it is handling were
> delegated.  As such, an end site is locked into the ALT nodes run by
> the EID manager from whom it received its EID.  And if that provider
> is not a top level EID provider, then it is locked in to a higher
> level aggregation provider.

Provision of EIDs is independent of ALT.  ALT is a mechanism for
finding EID-RLOC mappings.  This isn't like PA address allocation
today.

> Remember that one of the goals was to remove lock-in, since lock-in
> encourages price increases.  We have removed RLOC lock-in.  But we
> seem to be creating EID lock-in.

The possible lock-in problem is not about EID allocation, but about
ALT connection.  Suppose I have a PI allocation that I got from an RIR
independently from the ISPs I am connected to.  One of those ISPs just
happens to also be a so-called "ALT provider", meaning my ETRs connect
to an ALT node run by that ISP and that ALT node is willing to claim
to be able to reach mapping information for my prefix and forward
Map-Queries to my ETRs.  Then I want to change where I connect and no
longer buy service from that ISP ... but 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 a related question, with both CONS and ALT, why would an EID
> provider be anywhere but at the top of the tree?  That is, the
> discussion assumes reasonable delegation and a reasonably small
> number of players at the top of the tree.  

Nope :-).  See above.  Not related to EID allocation.


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