Subject: [rrg] 2 Possible Consensus Items

From: RJ Atkinson <[email-masked]>
Date: Tue, 9 Mar 2010 14:38:13 -0500

All,

I'd like to probe for consensus on 2 general statements,
which are listed below.

NOTE WELL:
1)  This is a personal note, so results are neither official 
    nor binding on anyone.

2)  Edits, corrections, and discussion are all out-of-scope.
    (The RG Chairs might choose to hold an official poll later,
    on this or some other set of statements; that choice is theirs.)

3)  This is a call for an up/down unofficial & non-binding straw poll.  
    - "Yes" to a statement means "I agree this is approximately true"
    - "No" to a statement means "I think this is entirely 100% wrong."
   
   For now, "waffle" votes of the form that this is partly true and 
   partly wrong just aren't helpful.

STATEMENTS & BALLOT:

A) "The Internet continuing down the current architectural path,
    whereby site multi-homing increases the size/entropy of the 
    DFZ RIB/FIB is not believed to be scalable or viable."

    [  ]  YES
    [  ]  NO

B) "There is no reason to believe that a scalable solution for
    site multi-homing will appear in the future so long as the 
    Internet proceeds with current architectural approach to 
    site multi-homing."

    [  ]  YES
    [  ]  NO

Yours,

Ran

PS: 
(I believe both A and B are approximately true, of course.)

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 9 Mar 2010 17:01:20 -0500

Someone more clever than I suggested setting up a Doodle poll
for this.  I've done so at the URL below.  Please use that
instead, as it makes counting more obvious.  

With Doodle, please only select the box if you are voting "YES" 
on that statement.  If one disagrees with both, select the box 
under "Disagree with both A & B".

	<http://www.doodle.com/25wqrrsdd6wr6ait>

Thanks !

Ran

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 11 Mar 2010 01:58:09 -0500

On Tue, Mar 9, 2010 at 2:38 PM, RJ Atkinson <[email-masked]> wrote:
>    [ x ]  YES
>    [ x ]  YES
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Robin Whittle <[email-masked]>
Date: Thu, 11 Mar 2010 18:26:12 +1100

Hi Ran,

Can you explain what you mean by Q2, and what you think are the
logical implications of agreeing with both statements?

>     DFZ RIB/FIB is not believed to be scalable or viable."

I understand this clearly and agree - as I guess everyone else does.

>     Internet proceeds with current architectural approach to 

This may be nonsensical.  The condition is:

  so long as the Internet proceeds with current architectural
  approach to site multi-homing

where I guess "proceeds" means continues to use the current
unscalable approach (multihoming end-user networks advertising their
individual PI prefixes in the DFZ), either exclusively or at least as
much as now, with the potential addition of some other approach.

The the question is whether, under these circumstances, in the future:

  a scalable solution for site multi-homing will appear

If "appear" means "be adopted widely enough to make a difference"
then that can't happen with the condition of "proceeding", if
"proceeding" means "using exclusively".

If "appear" means that an architecture will be designed, at least to
the stage where people could imagine how might work, then I would say
this has already happened:

  CES architectures:  LISP and Ivip could solve the scalable routing
  problem, for IPv4 and IPv6 - though I reckon Ivip could do it
  better.  Both could also support the TTR Mobility system for IPv4
  and IPv6.  Maybe IRON-RANGER could solve the routing scalability
  problem too, though I think some of its mechanisms are IPv6-based.

  The CEE (AKA Locator / Identifier Separation) architectures:

     GLI-Split
     ILNP - Identifier-Locator Network Protocol
     Name-Based Sockets
     RANGI

  could all solve the problem for IPv6 if they worked as planned.  I
  don't yet fully understand how they would work, but I suspect they
  would not be as good for Mobility as the TTR Mobility approach -
  which none of them support.  If any of these did work as planned,
  they could in principle solve the routing scalability problem in
  terms of portability, multihoming and inbound TE for non-mobile
  IPv6 networks.  However, this requires full adoption by all hosts
  in all networks, and the extra delays and burdens on hosts which I
  object to: (msg06250).

I don't think the continued usage of the current unscalable approach
has inhibited the development of new scalable routing architectures.

Nor do I think its continued use would inhibit the adoption of a
suitably attractive scalable routing architecture.  I think the most
attractive is Ivip, with LISP second.  I don't think there are any
other scalable routing architectures which would be attractive enough
to have widely adopted on a voluntary basis.

I think it is good seek agreement/consensus, but I will sit out this
vote because I regard the second question to be ambiguous, confusing
and/or nonsensical.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Thu, 11 Mar 2010 23:26:25 +1100

Since Chris Morrow ([email-masked]) and I wrote to the list,
I see two votes have been added to the poll:

  http://www.doodle.com/25wqrrsdd6wr6ait

   "morrowc.lists"  [OK]  [OK]

   "rw"             [OK]  [  ]

I have not voted in this poll.  There's only one person I can see who
has written to the RRG with initials "RW" - Rolf Winter in August
2008.  I am inclined to think that based on my last message, someone
added this vote and used my email account name.

I would only vote in something like this if I understood the second
question and was sure that everyone else who voted and who will vote
understands the question in the same way.  Without this, the results
for the second question are not a test of agreement at all.

Didn't anyone else think the second question was ambiguous,
nonsensical or whatever?  What did people think they were agreeing or
disagreeing with by answering Yes or No to the second question?

Ran, can you explain the second question in a more detailed manner,
with an example?

What implications do you see from some or many people agreeing to the
first question and agreeing to the second?

What implications follow from agreeing with the first but not the second?

  - Robin

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Mar 2010 15:52:38 +0200 (EET)

> disagreeing with by answering Yes or No to the second question?

FWIW, yes, it certainly was ambiguous, but it was apparent that lots 
of folks interpreted it their own way.  You made good points about 
different interpretations in your previous post.  In the end, it is 
not critical to know why folks made the assumptions and 
interpretations they did.  However, in order to build consensus, it 
would not hurt to have more precise questions but this is not an 
absolute requirement, and as Ran wrote, this seemed like an 
intentional approach.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Scott Brim <[email-masked]>
Date: Thu, 11 Mar 2010 09:06:48 -0500

Pekka Savola allegedly wrote on 03/11/2010 08:52 EST:
> FWIW, yes, it certainly was ambiguous, but it was apparent that lots of
> folks interpreted it their own way.  

I never got around to responding because of the ambiguities.  Also I
don't see how it really matters.  If it means what I think it means,
it's a truism.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Mar 2010 17:17:24 +0200 (EET)

On Thu, 11 Mar 2010, Pekka Savola wrote:
> FWIW, yes, it certainly was ambiguous, but it was apparent that lots of folks 
> interpreted it their own way.  You made good points about different 
> interpretations in your previous post.  In the end, it is not critical to 
> know why folks made the assumptions and interpretations they did.  However, 
> in order to build consensus, it would not hurt to have more precise questions 
> but this is not an absolute requirement, and as Ran wrote, this seemed like 
> an intentional approach.

Let me expand this a bit on why I thought so.  The question was:

I interpreted this to mean that while a scalable solution for site 
multihoming may appear or has appeared, I do not believe it will gain 
sufficient momentum as long as the current architectural approach to 
site multihoming persists. And I don't see a solution appearing that 
would be better to the end-user POV than the current model. So I voted 
"no".  But based on different interpretation, e.g. just focusing on 
technical solution, you might also vote yes.

So you can interpret this also differently, e.g.:
  - "no reason to believe" is a rather strong wording.  if you think
    there is (only) 10% chance of this appearing, should you still vote
    yes?
  - "will appear" -- does it imply use (to significant degree)? As one
    example, one might mention e.g. shim6.

---

From: Tom Vest <[email-masked]>
Date: Thu, 11 Mar 2010 11:32:42 -0500

> don't see how it really matters.  If it means what I think it means,

I'm not sure how to respond because the "current path" antecedent in both questions is a non-possibility.

More important still, I suspect that the scalability of any/every conceivable site multihoming mechanism will ultimately be contingent on the bounding conditions that dictate what a "site" is, and what features/advantages "sites" enjoy that distinguish them from "non-sites."

To put this in more generalizable terms, I think of the "current path" as combining: 

1. A protocol-level architecture that links some (potentially) universally advantageous capabilities -- "multihoming" being just one of many possible examples -- to particular non-universal properties, e.g., "site" status,  

2. Hardware technology-imposed limits on collective DFZ RIB/FIB carrying capacity, which is incrementally encumbered by each additional "site" and each instance of multihoming, 

3. Formal, collectively imposed (institutionalized) limits on "site" definition, implemented through consistent but contingent (i.e., not unique but not arbitrary) policies and administrative practices,

4. Informal, individually and collectively imposed back-pressure on per-"site" multihoming (ala the CIDR report, bilateral inter-provider bargaining, etc.), and

5. Enough protocol resources (IPv4) to sustain all of the above, at least for "a few more years."

If (5) continued to be true, I suspect that the overall "current architectural path" (1-5) would in fact continue to be scalable and viable, perhaps indefinitely. But given that (5) is no longer true, and one response to that development has been the weakening/abandonment of (3), reference to the "current architectural path" in Question A doesn't seem to me to be coherent. Granted, some may not feel that (3) should be considered an "architectural" element -- but then that would imply the equally incoherent position that the now very large and still-expanding Internet has been equally nonviable and non-scalable for the last twenty years ago, if not from day one. 

That view would also seem to invalidate Question B as leading. But setting that point aside for the moment, I think that the real challenge for the foreseeable future -- including all of the candidate solutions under discussion -- is reconciling (1), and the possibility of unbounded demand for whatever advantageous features distinguish certain participants, sites, or whatever from others, with the existence of whatever hard limits the future system imposes, i.e., that the future architecture cannot eliminate.

My own view, biased, impressionistic, and under-informed though it may be, is that much time and effort has been spent on rationalizing (or alternately avoiding) the question of whether, how, and why demand for certain potentially advantageous roles/capabilities in the future arch will be (and will remain, indefinitely) low and bounded by exogenous factors, so that scalability problems at that particular level could never arise. I would personally feel much more confident (or at least much less skeptical) about candidate solutions if they gave equal time, space, and consideration to fallback mechanisms that might preserve scalability *even if such assumptions about externally imposed constraints turn out to be wrong.* 

One lesson that we've learned -- or should have learned -- from the last decade-plus of experience is that so long as the Internet continues to be supported and maintained primarily by competing commercial entities, *no* role, feature, or capability that might provide one network operator with a competitive advantage over another will remain immune to endogenously-generated scalability pressures for very long.

TV

---

From: Robin Whittle <[email-masked]>
Date: Fri, 12 Mar 2010 11:54:03 +1100

Short version:   Q2 clearly means different things to different
                 people - so the poll should be re-run once there
                 are questions which everyone understands in the
                 same way.

Scott Brim (msg06255) and Pekka Savola (msg06254) regard Q2 as
ambiguous.  My understanding of Tom Vest's message (msg06257) is that
 he didn't know how to respond to the questions.

(BTW, Tom, your "Apple Mail (2.1077)" mail client sends each
paragraph as a long line, which makes your message difficult to read
in the archives.)

I think the results of this poll would only be of any value if it
could be limited to the subset of people whose stated understanding
of the questions were all the same.  The vote attributed to "rw"
should be discounted, and I suggest the one attributed to Pekka also
be discounted since he regards Q2 as ambiguous.  (Unless it can be
shown that everyone else who voted understood the question the same
as he did.)

Scott wrote:

> I never got around to responding because of the ambiguities.

I think abstaining is the correct response.  If the questions are
presented in different poll in a manner I regard as unambiguous and
which I think are relevant to the field, I will vote.

> Also I don't see how it really matters.  If it means what I think
> it means, it's a truism.

This would work for Eckhart Tolle attending the Mad Hatter's Tea
Party.  But for demonstrating consensus in the RRG, it needs to be
established that all respondents understand the questions in the same
way.

Pekka wrote:

> In the end, it is not critical to know why folks made the
> assumptions and interpretations they did.

It depends on what the "end" is.

> However, in order to build consensus, it would not hurt to have
> more precise questions but this is not an absolute requirement, and
> as Ran wrote, this seemed like an intentional approach.

I am sure it is an absolute requirement.  Consensus concerns people
agreeing to the one thing.  Just because people ticked "Yes" to the
one question means nothing in this respect if people's understanding
of the question varied significantly.

Pekka wrote:

> "no".  

I am confident that, if implemented well, both Ivip and LISP would
provide benefits which would make widespread adoption possible.  This
is primarily for the large number of end-user networks which lack the
resources to gain address space and advertise it as PI prefixes in
the DFZ.

I am especially confident of the TTR Mobility extensions to Ivip (or
in principle, LISP) as being commercially attractive, right now, for
IPv4 global mobility.  This doesn't compete with anything, since
there is no other way of attaining a global unicast address for a MN,
which is retained irrespective of its one or more connections to the
Net, including behind NAT.  For an overview and pointers to the IDs etc.:

  Recommendation suggestion from RW (v2)
  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

On this interpretation of Q2, I would vote "No".  But I am not voting
in this poll because Q2 is far too ambiguous.

> But based on different interpretation, e.g. just focusing on

I agree - it is unclear what "no reason to believe" means.

>    example, one might mention e.g. shim6.

Exactly - what does "appear" mean?

Ran - can you provide a fuller explanation and re-run your poll once
it appears that people all agree what it is you are asking?

  - Robin

---

From: Paul Jakma <[email-masked]>
Date: Sat, 13 Mar 2010 00:14:51 +0000 (GMT)

>    DFZ RIB/FIB is not believed to be scalable or viable."

I'd have liked to have been able to vote

      [  ] Insufficient evidence either way, at this time.

(e.g. Geoff Huston's more recent BGP reports seem to show evidence 
that BGP is more stable than expected in the face of how the internet 
is growing).

So am voting "No" in lieu of that option.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Trying to be happy is like trying to build a machine for which the only
specification is that it should run noiselessly.

---

From: Tony Li <[email-masked]>
Date: Fri, 12 Mar 2010 17:18:10 -0800

Hi Paul,

> that BGP is more stable than expected in the face of how the internet

Are you referring to Geoff's recent APRICOT talk on "BGP in 2009"?  If so,
that would seem to indicate convergence times for single prefixes are
relatively stable and seem to be proportional to AS path length.  It is not
terribly surprising that these are constant, as a significant fraction of
changes are due to tail circuit changes where only a small number of
prefixes are actually going to shift paths.  Since BGP convergence at a
single node is going to take time that is linear in the number of affected
prefixes, and only a few prefixes are changing, there would seem to be
nearly a constant amount of work to do.

That same talk reinforces the fact that we're still on a quadratic growth
curve, for both v4 and v6.  ;-(

What I didn't see in there was any discussion of the convergence time when
there is a point failure in the network, such as when a router reboots.
These are the cases where the BGP convergence time is going to be linear in
the number of prefixes.

Or, put another way, Geoff's work suggests that routers in the middle of the
net aren't rebooting frequently.  Whew.  ;-)

Regards,
Tony

---

From: Paul Jakma <[email-masked]>
Date: Sat, 13 Mar 2010 02:16:06 +0000 (GMT)

On Fri, 12 Mar 2010, Tony Li wrote:

> Are you referring to Geoff's recent APRICOT talk on "BGP in 2009"?

Yes.

> If so, that would seem to indicate convergence times for single 
> prefixes are relatively stable and seem to be proportional to AS 
> path length.

Maybe. Though I also got the following from his presentation:

- the diameter of the internet is fairly stable (not unexpected,
   given we know the internet topology tends to be scale-free in
   distribution)

- despite the continued growth in the number of the ASes, the
   convergence time has been fairly stable too

This latter point is very interesting as, if I'm understanding 
Geoff's results and the previous academic work on BGP convergence 
correctly (Labovitz, Griffin), it means that the common-case 
convergence of BGP+internet topology scales a lot more nicely than 
the (worst-case) scaling predicted by academic work.

I could be completely misunderstanding stuff maybe, and I guess we'd 
also need more data beyond Geoff's too, however Geoff's presentation 
seemed to say "the BGP sky isn't falling anywhere like we thought it 
should" and based on his charts I'd have to agree.

> It is not terribly surprising that these are constant, as a 
> significant fraction of changes are due to tail circuit changes 
> where only a small number of prefixes are actually going to shift 
> paths.

>  Since BGP convergence at a single node is going to take
> time that is linear in the number of affected prefixes, and only a 
> few prefixes are changing, there would seem to be nearly a constant 
> amount of work to do.

Well, the per-prefix work ought to be increasing as the number of 
prefixes advertised were increasing, surely? Unless somehow the 
growth in new prefixes is not distributed evenly - i.e. all the new 
prefixes are in the core, while the failures are mostly at the edges 
(tail circuits).

However, I wonder if Geoff is measuring per-UPDATE alone and not 
breaking out UPDATE activity out by the number of NLRIs? That would 
be consistent with what you say.

Whatever, his findings are that there isn't any evidence of a BGP 
meltdown, surely? To the contrary, internet routing is doing 
surprisingly well.

> That same talk reinforces the fact that we're still on a quadratic 
> growth curve, for both v4 and v6.  ;-(

I can't remember where I saw it (another one of Geoff's lovely 
graph-filled presentations maybe?? :) ) but didn't someone do a 
comparison of growth in memory/CPU resources versus growth in DFZ 
prefixes? Iirc they found RAM/compute resources were increasing at a 
sufficient rate to keep ahead of DFZ growth.

I.e. the exponential Moore's law growth in transistors-per-device 
beats the quadratic DFZ growth.

The growth in prefixes is simply to be expected, obviously - to some 
extent its natural and good.

> What I didn't see in there was any discussion of the convergence 
> time when there is a point failure in the network, such as when a 
> router reboots. These are the cases where the BGP convergence time 
> is going to be linear in the number of prefixes.

I think what Geoff was suggesting is that it's linear in the diameter 
of the internet, which is a lot better than the "linear in the size 
of the internet topology" O(|V|+|E|) worst-scaling from the 
literature - particularly when the internet topology grows in such a 
way as to keep diameter-growth very limited.

> Or, put another way, Geoff's work suggests that routers in the 
> middle of the net aren't rebooting frequently.  Whew.  ;-)

Maybe :)

FWIW, I'm not claiming that BGP scalability should not be improved. 
However I don't see evidence for any terrible scaling problem that 
must urgently be solved. Without evidence of such a problem, I would 
argue we should be careful about picking too extreme solutions 
(extreme in the disruptive sense).

I.e., in trying to find a way to insulate the core of the internet 
from growth at the edges we should be careful that we do not rush 
towards a solution that is less good than the null-solution (e.g. 
because it has a mapping system that adds latency and/or 
instability).

It's possible that the current architecture of the internet is 
holding back growth that should otherwise be there. I guess we could 
test for that by comparing growth today to growth in earlier days. If 
it's significantly slowed down then that must be the case. I havn't 
checked, but my vague memory of the address-space reports is that 
this is not the case and that the internet is growing normally (how 
this will change as/when v4 runs out and v6 is the only space that 
allows growth will be interesting to see).

In short, I havn't seen compelling evidence to suggest that the 
current routing architecture can not cope with the historical and 
current modes of growth.

Anyway, I could be completely under- and/or mis- informed, in which 
case apologies in advance :).

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
According to the latest official figures, 43% of all statistics are
totally worthless.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Mar 2010 14:33:30 +1300

I've been mulling this over for days, and have concluded that
my only option is to abstain.

>     DFZ RIB/FIB is not believed to be scalable or viable."

I regard it as quite plausible that if we do nothing (modulo
deploying IPv6) the BGP4 table size will eventually stabilise at
about 1 million entries, and it's very plausible that this will
not be a technological problem.

>     Internet proceeds with current architectural approach to 

I can't say No to that, but I can't say Yes either, because
there is no issue unless the demand for multihoming expands
*disproportionately* to the general growth of the network. I
have no reason to believe that it will expand disproportionately.

Neither of these abstentions means that we shouldn't look for
a scalable solution, of course.

     Brian