Subject: Aggregation Implies Provider Dependence // Re: [RRG] ALT's strong aggregation often leads to *very* long paths

From: Christian Vogt <[email-masked]>
Date: Thu, 31 Jan 2008 21:23:33 +0200

Robin,

I agree with you that ALT's aggregation of provider-independent (hence
expectedly very scattered) EID space leads to longer-than-optimal paths.
I would like to address another adverse side-effect of aggregation:

ALT-style aggregation IMO violates the design objective of provider
independence.  It binds an edge network owning a piece of provider-
independent EID space to a particular lowest-level router in the ALT
hierarchy.  The edge network thereby gets tied to the "ALT provider"
operating this router, very similar to how edge networks with provider-
allocated address space are nowadays tied to their (physical) provider.

As a result, while address mapping solutions (such as Six/One, APT,
LISP) yield independence from physical providers, ALT introduces a new
dependence on "ALT providers".

- Christian

Robin Whittle wrote:
> Even assuming a global query server (and initial packet delivery) 
> network was desirable, which I think it is not, ALT suffers from the 
> problem that many paths from ITR to ETR will be extremely long - 
> longer than half-way round the Earth.
> 
> [...]

--
to unsubscribe send a message to [email-masked] 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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Feb 2008 13:42:50 +0100

> dependence on "ALT providers".

We discussed this at the IST-RING workshop, as you may recall, 
Christian, and I believe that it was Jari who coined the term at the RRG 
meeting.  While it is true in the abstract that you might have some 
dependence on your ALT provider, and while it is also true in the 
abstract that if you wish to change ALT providers, you may be forced to 
renumber, I think there are a number of mitigating possibilities here.

First of all, I could easily imagine partnerships forming between ALT 
providers that share portions of the address space and allow their 
customers to renumber from one partner to another.  This isn't pure 
independence, but it is something.

Second, the degenerate scenario that you describe is that we are fully 
disaggregated.  That means that there is a lot of STATE.  It says 
nothing about RATE.  This will depend very much on how the LAT is 
managed.  If the LAT is extended to the last mile link without any 
static announcements, we would have precisely what we have today.  
However, if LAT announcements are relatively static, then the question 
is this: who cares?

Eliot

---

From: Christian Vogt <[email-masked]>
Date: Fri, 01 Feb 2008 20:14:46 +0200

Eliot -

> independence, but it is something.

The question is whether ALT operators would be willing to engage in such
a cooperation with their competitors.  They could do the very same thing
already today in order to make renumbering a less frequent event without
sacrificing routing scalability.  But they are NOT doing it -- which is
why we are looking for alternative solutions here in RRG...

> However, if LAT announcements are relatively static, then the question 

I am assuming that you are suggesting the following.  Please clarify if
I understood you incorrectly:

- Relax the requirement for aggregation in the LAT.

- The cost of such disaggregation will be a larger LAT routing table.
   But since the LAT won't be used for traffic engineering purposes (as
   BGP is in today's single Internet topology), the update rate of the
   LAT routing table won't necessarily go up.

This is certainly a valid observation.

I believe the important point here is that there is a trade-off between
aggregation within the LAT and provider-independence of EID space.  The
compromise affected by the ALT specification is in favor of aggregation
-- and as I have said in my previous email, this makes EID space
provider-dependent.  Your suggestion above affects a compromise in favor
of provider-independence -- at the cost of larger LAT routing tables.

Both compromises have their pros and cons.  Important is that we are
aware that we would have to make this trade-off if we went for ALT.

- Christian

---

From: <[email-masked]>
Date: Sun, 3 Feb 2008 12:43:04 +0200

Hello Christian and others

You wrote

>The question is whether ALT operators would be willing to 
>engage in such a cooperation with their competitors.  They 
>could do the very same thing already today in order to make 
>renumbering a less frequent event without sacrificing routing 
>scalability.  But they are NOT doing it -- which is why we are 
>looking for alternative solutions here in RRG...

The reason why we do not see such co-operation among the operators/ISPs
is not competition, but rather that there are no sufficient tools.
Currently if you wish to implement address aggregation and address
portability between two adjacent operators (adjacency in terms of
address space), would amount to a lot of manual configuration and
tweaking BGP.  The address aggregation and related address portability
(within the aggregation) would benefit the operators, customers and the
industry as a whole if proper tools just existed. 

As a reference to similar problem, the address portability in the 3G and
GSM networks works fine even between the competitors. This didn't happen
because of the altruism of mobile operators, but because of regulation
that promoted competition. I could even go so far to claim that it was
exactly the hyper competition between the mobile operators that lead to
the implementation of address portability (with the help of regulation).

Regards 
Hannu Flinck   

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Christian Vogt
>Sent: Friday, February 01, 2008 20:15
>To: Eliot Lear
>Cc: Robin Whittle; Routing Research Group; Dino Farinacci; 
>Scott Brim; Vince Fuller; David Meyer
>Subject: Re: Aggregation Implies Provider Dependence // Re: 
>[RRG] ALT's strong aggregation often leads to *very* long paths
>
>Eliot -
>
>The question is whether ALT operators would be willing to 
>engage in such a cooperation with their competitors.  They 
>could do the very same thing already today in order to make 
>renumbering a less frequent event without sacrificing routing 
>scalability.  But they are NOT doing it -- which is why we are 
>looking for alternative solutions here in RRG...
>
>I am assuming that you are suggesting the following.  Please 
>clarify if I understood you incorrectly:
>
>I believe the important point here is that there is a 
>trade-off between aggregation within the LAT and 
>provider-independence of EID space.  The compromise affected 
>by the ALT specification is in favor of aggregation
>-- and as I have said in my previous email, this makes EID 
>space provider-dependent.  Your suggestion above affects a 
>compromise in favor of provider-independence -- at the cost of 
>larger LAT routing tables.
>
>Both compromises have their pros and cons.  Important is that 
>we are aware that we would have to make this trade-off if we 
>went for ALT.
>
>- Christian
>
>
>
>
>
>--

---

From: Scott Brim <[email-masked]>
Date: Fri, 8 Feb 2008 09:28:07 -0500

The whole scenario still feels specious to me.  To start with, for
redundancy a particular ALT infrastructure node will be
multiply-connected to the aggregation level above it.  This will be
true for sites as well -- they will be multiply-connected to
first-level ALT nodes, whether those ALT nodes are provided by a
site's access provider or not.  There is no single point of ALT
connectivity to hold hostage.  

However, because of aggressive aggregation of routing information,
each node needs to attempt to connect to all next-level aggregators
(above it), or packets might be lost if sent to the "wrong"
aggregator.  So there is some potential vulnerability ... 

... but an ALT node that pretended to have routes to all active EIDs
within a prefix, while simultaneously refusing a connection to a valid
holder of an EID prefix and intentionally blackholing packets to it,
would be seen as a disruptor of the entire system.  However, because
of redundancy, the system can easily defend itself -- higher level ALT
nodes can stop depending on the misbehaving node to route any packets
at all, at least for the including prefix.  This is not an
architecture issue, it's an operations issue.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 08 Feb 2008 10:10:06 -0500

I am not following what you are suggesting.
As I understand it, the ALT hierarchy is a strict delegation hierarchy. 
  A given ALT node can only connect upwards to the node (or duplicate 
nodes, but they will be under a common administration) 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.

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.
With NERD, that is not much of a big deal.  There is no serious 
aggregation, so changing what "EID advertiser" advertises your EID into 
the system is sufficiently simple that there is little lock in power. 
So folks probably won't even need to change often.
With CONS, there is a need for an aggregation hierarchy for 
advertisement / resolution.  It is a bit of a lock-in issue.
With ALT, where that is also a early packet forwarding infrastructure, 
it is more of an issue.

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.  We tried to enforce that early on for IPv6, and gave 
up.  Why would it work for EIDs?  (An EID provider might use delegation 
within his own organization to make deployment more flexible, but that 
is very different from an assumption of multiple players working at 
different aggregation layers.)

Yours,
Joel

---

From: Scott Brim <[email-masked]>
Date: Sat, 9 Feb 2008 09:29:57 -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

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.  

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

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

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 9 Feb 2008 11:56:33 -0500 (EST)

> From: Scott Brim <[email-masked]>

    > could (probably will) be completely independent of the ALT

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