Subject: Re: [rrg] moving towards recommendation: the current plan

From: [email-masked] (Noel Chiappa)
Date: Fri, 4 Dec 2009 15:17:30 -0500 (EST)

> From: Dan Jen <[email-masked]>

    > All of the recent proposals and rrg discussion seem to focus on
    > re-empowering aggregation by attempting to pinpoint the reasons for
    > deaggregation and dealing with them. A lot of reasons have been brought
    > up, such as PI usage, ingress TE, avoiding renumbering, etc. Yet, it is
    > unclear how much each 'cause' contributes to overall deaggregation.

Does it matter? As long as the solution handles all (or most) of them, that
should be all that's needed. Are there significant causes of expansion that
aren't handled by separation of location and identity? If so, I think we need
to hear about them ASAP.

    > I wonder if it would be preferred to have a solution that allows
    > networks to shield themselves from routing table bloat, regardless of
    > the causes behind long-prefix announcements - a cause-agnostic solution.

A terminology nit here: when you say "routing table" do you really mean the
routing table (strictly defined), or the RIB, or the FIB (since many
implementations now include all three as separate databases).

I ask because to the extent that a solution downsizes one of these (e.g. the
FIB reduction work), but not the others, it may not help with the overall
growth of 'routing tables' (in the generic sense), since I think a lot of the
concern is that the stability and robustness of the routing overall (i.e. the
global distributed computation) is negatively impacted by 'routing table
growth'.

Not that I'm against things like FIB reduction - I welcome its deployment, in
parallel with other things; it's sort of a 'the more the merrier' situation.

    > why do you consider VA a short-term solution? ... VA allows networks to
    > scale down their tables to any arbitrary size by re-enabling
    > aggregation within the network.

I wouldn't even consider it a short term solution to the larger problem,
because it's only local - it doesn't really have any impact on the global
distributed computations which currentlt produce end-end paths, and it's
that larger, overall situation which I thought (perhaps mistakenly) was
a major focus.

Again, though, I don't see any problem with deploying it in parallel - as
long as it's realized what its limitations are.

	Noel

---

From: Dan Jen <[email-masked]>
Date: Fri, 04 Dec 2009 22:09:11 -0800

Hello,

> aren't handled by separation of location and identity? If so, I think we need

Here's why it might matter.  Some proposals address some, but not all of
the alleged causes of expansion.  Imagine if we knew how much each cause
contributed to expansion, and realized that one or some of those causes
didn't really contribute much to expansion at all.  Proposals that
didn't address these 'problems' wouldn't be subject to such a criticism
anymore.

On the flipside, if one of these causes was the found to be the main
contributor of expansion, we certainly would make solving this problem a
MUST.

> implementations now include all three as separate databases).

I mean the RIB and FIB.   

> parallel with other things; it's sort of a 'the more the merrier' situation.

I agree that a solution that does not reduce both RIB and FIB should not
be considered complete.

> that larger, overall situation which I thought (perhaps mistakenly) was

If all local parties that suffer from a scalability problem are given a
solution, isn't this a global fix?  A patch for a program needn't go to
everyone, but just those users that ever use the program.  

I also don't CLEARLY understand what you mean by "larger, overall
situation" and what additional ground that covers.  Can you spell that
out a bit more?

Dan Jen

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Dec 2009 09:29:57 +1300

Dan,

> contributor of expansion, we certainly would make solving this problem a

I'm not sure that follows. Although there is some long term smoothness
in DFZ growth vs Internet size, this conceals many non-linear effects
of the way the topology has evolved. That makes predicting the future
from the past very hard; as the recent Internet Observatory report
shows, the topology is still changing in nature (and the causes are
economic as much as they are technical, so even harder to predict).

If you can't predict quantitatively the effect of each cause, it's
hard to prioritize which causes to tackle.

That said, do you have any ideas on how to analyze the historical data
to clearly separate and quantify the effect of each cause of DFZ growth?

My personal view is that we should focus on quite high level goals
that don't depend on topological or business details. Quoting myself:
"in addition to ... minimising the number of prefixes originated
by each AS, it is also highly desirable that the large majority of
ASes should continue to be origin-only systems providing no transit."

    Brian

---

From: Dan Jen <[email-masked]>
Date: Sat, 05 Dec 2009 18:02:19 -0800

Hey Brian,

I actually agree with you that it is difficult to predict the reasons
behind deaggregation, and how much each reason has contributed to
overall expansion.  I also agree that even if we could somehow discover
this, the past is not certain to properly predict the future.  Which is
why in my original message, i said:

"I wonder if it would be preferred to have a solution that allows
networks to shield themselves from routing table bloat, regardless of
the causes behind long-prefix announcements - a cause-agnostic
solution."

My last message meant to convey that IF we knew of a set of reasons
that, were they eliminated, would solve our scaling problems forever,
then it might help us formulate a strategy to scale the Internet.  But
since, as you pointed out, we cannot, we should consider more
cause-agnostic solutions.

Many rrg proposals are not of this flavor.  I see a lot that point to
TE, or PI addressing, and focus on enabling parties to receive the
benefits in other ways, then claiming it solves our scalability
problems.  There is an underlying presupposition that if you eliminate
these causes, the routing tables will scale again, and that supposition
is exactly what you and I are a bit uneasy about.

Dan Jen