Subject: [rrg] Consensus call: Reject proposed strategy F?

From: "William Herrin" <[email-masked]>
Date: Tue, 23 Dec 2008 22:29:35 -0500

Hi Folks,

The Summary of Routing Architectures discussed in the RRG, posted at
http://bill.herrin.us/network/rrgarchitectures.html includes:

  Strategy F.

  Do nothing. (RFC 1887 § 4.4.1)

I propose that we REJECT strategy F.

As we use it now, BGP lacks sufficient scalability to see the Internet
into the coming decades. We constrain the growth of the BGP RIB by
disadvantaging small, innovative organizations when they seek IP
addresses from the regional registries. We constrain the growth of the
BGP RIB by refusing to offer consumer level broadband products capable
of multihoming. Then we spend some $2B per year getting the routes
that do make it into BGP to work. [Herrin BGP Cost]  This damages the
Internet, damages invention and ultimately damages us.

I ask you to post either, "I AGREE that we should reject strategy F"
or "I DISAGREE; strategy F should continue to be considered.". I'd
also appreciate a few words about why or why not.

If we have a strong consensus to reject strategy F, the Summary of
Routing Architectures will be updated to reflect that we have
considered and rejected it.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Dec 2008 09:13:08 +1300

Bill,

On 2008-12-24 16:29, William Herrin wrote:
> into the coming decades. 

Before we take this as revealed truth, let's not forget that BGP4 has
in fact scaled amazingly well since 1994. I assert that we still do not
have anything like a scientifically adequate projection for the next
five or ten years (as we didn't at the Amsterdam IAB workshop). That goes
for both projected RIB growth and projected growth in the UPDATE load,
and it goes for the engineering of core routers. So we *cannot* exclude
that the BGP4 system will continue to scale if we do nothing.

I'm not in fact advocating a 'do nothing' strategy. On the contrary,
I advocate that the RRG makes the best recommendations that it can.
But I suggest that we should neither accept nor reject strategy F;
I think we should just set it aside. It's out of our control anyway.

   Brian

> We constrain the growth of the BGP RIB by

---

From: "William Herrin" <[email-masked]>
Date: Mon, 29 Dec 2008 15:35:53 -0500

> I think we should just set it aside. It's out of our control anyway.

Hi Brian,

My worry is that by retaining strategy F, we signal that the problem
isn't ripe yet. If plain BGP is not recommended but is still
acceptable, what's the need for working groups or a concerted
engineering effort?

My thought was that strategy D, E or both should remain as controls
while F should be discarded. D involves scaling up how BGP is
processed while E involves suppressing BGP growth.

Do you want to keep F in addition to D and E, or do D and E provide a
sufficient fallback position as methods for expanding and/or
controlling BGP?

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Dec 2008 10:10:16 +1300

Hi Bill,

> sufficient fallback position as methods for expanding and/or

No, because I think D and E are lost causes anyway.

I think we should just say something like:

It is not known with any scientific or engineering accuracy when
vanilla BGP4 will reach an economic or technical scaling limit (i.e.
when it becomes financially or physically impossible to continue
beefing up core BGP4 routers to cope with growth in the size or
update frequency of the BGP4 routing table). Therefore the RRG
has not considered a "do nothing" strategy, since it is essential
to be ready for this limit well befre it arrives.

         Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Dec 2008 16:39:04 -0500

I have been refraining from participating in this, because when all is 
said and done it does not seem to tell us much.  But what the heck.

Working backwards:
G says "constrain what people are allowed to do, even if they are 
prepared to pay.  Not going to happen.
F says "we give up."  Well, we may.  But if we are trying to get to a 
useful conclusion, that isn't it.
E says that economic factors may help.  They may.  They won't change the 
architecture.  They will not stave off the problems forever.  Given that 
this is an economic / business issue, it is not something the IETF (or 
IRTF) is in a good position to influence.  We tried in the past.
D says that we can be more clever.  And we can.  It will buy us some 
runway.  Being more clever is engineering.  it takes good engineering, 
but it is engineering.  Folks are looking at it.  We sure should not say 
anything that tells them not to work on doing a better job for now. 
(The more runway they can give us, the better chance we have of getting 
to a good answer.)

C is geographic aggregation, if I read your document right.  The 
solutions I have seen to that tend to fall into three very different 
camps, with very different problems.  While I personally find all three 
kinds undesirable, we should be careful about how we comment on their 
workability.  (Note, one of the strategies I have seen does line up with 
the description in the web page.  One of the alternatives may or may not 
line up, as I have not been able to read an understandble description of 
how it would work.  And the third one is opportunistic.  The issue with 
an opportunistic approach is that it is hard to evaluate how much good 
we would get out of it.  But that is very different from undeployablity 
or incomprehensibility as a concern.)

B (host based) and A (border-box based tunnels) are the primary areas we 
tend to focus on.  While network-centric solutions using selective 
placement looks more tractable to deploy, there are difficulties and 
benefits for any of these strategies.  There are also hybrids which may 
allow evolution driven by functionality increases.  It would seem quite 
extreme to declare one side of this to be worth exploring, and the other 
side to be a bad idea.  So I would hate to see either A or B declared 
out of bounds for this community.

Yours,
Joel M. Halpern

---

From: "William Herrin" <[email-masked]>
Date: Mon, 29 Dec 2008 17:29:17 -0500

On Mon, Dec 29, 2008 at 4:39 PM, Joel M. Halpern <[email-masked]> wrote:
> F says "we give up."  Well, we may.  But if we are trying to get to a useful
> conclusion, that isn't it.

Hi Joel,

What, then, is your opinion? Is "give up" an acceptable next step? Or
should we reject it?

> I have been refraining from participating in this, because when all is said
> and done it does not seem to tell us much.  But what the heck.

It hopefully tells us what working groups we want the IETF to create
in order to write protocols and code. With a little luck it lets us
make that statement to the rest of the IETF as a cohesive group
instead of as individuals or as obviously biased cliques.

Or maybe we don't get to consensus this way either. But if we don't
try, we surely won't succeed.

No participation is a vote for no working groups. We'll just kick
around here the research group for a while longer. You paying
attention Dino? No participation is a vote for no LISP working group
too.

Anyway, I'm trying to break the strategies into three sets:

1. Ideas which show significant promise.
2. Ideas that it's time to stop taking seriously.
3. All the rest, which we can reconsider if #1 doesn't pan out.

I'm tackling #2 first in the hopes of focusing the discussion when we
look at #1.

I say we should tell the folks in GROW that it's time to stop
seriously entertaining the idea that vanilla BGP (strategy F) will
work out ok. What do you say?

Regards,
Bill Herrin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Dec 2008 17:38:10 -0500

Just commenting on one point on the list.

> work out ok. What do you say?

Firstly, given that there are useful things to do with BGP, that will 
extend its life, I don't think it would at all be appropriate to tell 
GROW not to put energy into engineering improvements.  They are focussed 
on what the short term problems are, and the easily engineerable fixes 
(often just in terms of BCPs, such as Paul's FIB tricks.)

Secondly, "give up" (strategy F) is largely orthogonal to the question 
of what GROW does about the immediate problems  The question in that 
regard is whether there are useful longer term things for us to be 
working on (whether those are LISP, Six/One, or Host based communication 
identities, or something else.)  I personally think that there are 
definitely still avenues worth exploring, and still things to be learned 
by such exploration.  But whether there are or not has nothing to do 
with any "message" we "tell the folks in GROW".

Thirdly, it is almost never effective to tell some other group "stop." 
So I am glad I don't think that is a useful activity.

Joel

---

From: Ross Callon <[email-masked]>
Date: Tue, 30 Dec 2008 00:55:21 -0500

> > seriously entertaining the idea that vanilla BGP (strategy F)
> > will work out ok. What do you say?
>
> Firstly, given that there are useful things to do with BGP,
> that will extend its life, I don't think it would at all be
> appropriate to tell GROW not to put energy into engineering
> improvements.  They are focussed on what the short term
> problems are, and the easily engineerable fixes (often just
> in terms of BCPs, such as Paul's FIB tricks.)

I agree with Joel that it would be seriously inappropriate to tell GROW
(or IDR) to stop thinking about engineering improvements to BGP. 

I can still remember quite well a comment from a "Gateway Algorithms and
Data Structures" meeting (the group that preceded the IETF) in the mid
1980's to the effect that "obviously IP routers will not work when the
IP forwarding table gets to 10,000 entries". I have similarly been
hearing about the imminent failure of BGP for nearly 20 years. Thus I
was originally tempted to just ignore this email exchange as "another
prediction of doom". However, I think that it is important to point out
that the predictions of failure are neither new nor universally
believed. 

The fact that the RRG is exploring other options seems useful to me, and
if nothing else can increase our understanding of what other options
might be possible. However, I am certainly not ready to confuse
"exploring" with either confidence that we want to change the
architecture, or consensus on how or whether to do so. 

Ross

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 30 Dec 2008 10:59:33 +0100

Such engineering recommendation coming from a research group would be
rather difficult to defend against these communities. Indeed, BGP/path
vector protocols limitations being known, these WGs are actually seeking
for understanding their impact (GROW) and advise BGP improvements to
mitigate them (IDR). Imho, the main challenge for these WGs is to assess
whether a proposed improvement has or not hidden negative impact(s).

In this respect, the reply would be "WHY" such recommendation ? and one
would fall short on the answer because 1) it is difficult to prove that
no workaround could ever be found that would (at least partially) solve
some of these limitations and 2) afaik, RRG never actively worked on
such issues (do we have experimental results arguing in favor of this
recommendation). 

Note: this thread is imho representative of an RRG looking at protocol
engineering recommendations instead of looking at
experimentation/exploration of alternatives, their associated challenges
(such as loc.reach, caching, mapping, impact on upper layers/traffic,
etc.) and documenting them. 

-d.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ross Callon
> Sent: Tuesday, December 30, 2008 6:55 AM
> To: Joel M. Halpern; William Herrin
> Cc: RRG
> Subject: Re: [rrg] Consensus call: Reject proposed strategy F?
> 
> 
>

---

From: "William Herrin" <[email-masked]>
Date: Tue, 30 Dec 2008 10:32:39 -0500

On Tue, Dec 30, 2008 at 12:55 AM, Ross Callon <[email-masked]> wrote:
>> improvements.

Ross,

Are there BGP improvements for which consideration is ripe, yet which
aren't described in the solutions summary? They should have been
mentioned in the months this document was open to casual additions but
for the rest of this week I'm willing to cut a little slack.

Strategy F is not "continue researching BGP improvements." Strategy F
is "BGP is good enough already."

Do you accept the claim that BGP can be expected to remain viable for
the foreseeable future even if none of the improvements we've
considered pan out? If not, you should reject strategy F.

Regards,
Bill Herrin

---

From: "William Herrin" <[email-masked]>
Date: Wed, 31 Dec 2008 00:27:12 -0500

On Mon, Dec 29, 2008 at 4:10 PM, Brian E Carpenter
<[email-masked]> wrote:
> update frequency of the BGP4 routing table).

Brian,

I've been chewing on this one. Is it correct? Are we unable to say
with scientific or engineering certainty that BGP4 has an technical or
financial upper bound somewhere prior to 10M entries?

If not, what's the case in favor of focusing any efforts on non-BGP
solutions at this point? And what's the justification for maintaining
the IETF recommendation that the RIRs impose artificial restrictions
on the minimum allocation size? Or for that matter any restrictions at
all on IPv6 assignment in multihomed environments?

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Tue, 30 Dec 2008 22:30:34 -0800

Bill,

|<[email-masked]> wrote:
|> It is not known with any scientific or engineering accuracy when
|> vanilla BGP4 will reach an economic or technical scaling limit (i.e.
|> when it becomes financially or physically impossible to continue
|> beefing up core BGP4 routers to cope with growth in the size or
|> update frequency of the BGP4 routing table).
|
|I've been chewing on this one. Is it correct? Are we unable to say
|with scientific or engineering certainty that BGP4 has an technical or
|financial upper bound somewhere prior to 10M entries?

That's correct.  We know of no hard upper bound to BGP or (more importantly)
the routing architecture as it currently exists.  It is apparent that unless
there is some significant progress somehow, the cost and/or complexity of
running the current architecture is going to start to climb.

|If not, what's the case in favor of focusing any efforts on non-BGP
|solutions at this point? 

I don't know of a good one.  Until we have an architecture that allows us to
carry fewer prefixes, simply replacing BGP will not be a net win.

|And what's the justification for maintaining
|the IETF recommendation that the RIRs impose artificial restrictions
|on the minimum allocation size? Or for that matter any restrictions at
|all on IPv6 assignment in multihomed environments?

Adding more prefixes will hasten the inevitable.

Tony

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 31 Dec 2008 10:10:13 -0500

> financial upper bound somewhere prior to 10M entries?

I would suggest that this is not quite the point. I feel quite  
comfortable
predicting that companies will make and sell routers capable of handling
any size BGP table necessary. There are pretty smart people and
strong financial incentives to make this happen.

The real question is, who will be able to afford them ? The current  
Internet "ecosystem" has a mix
of players of different sizes, and it seems to me that the real goal  
here
is to continue to allow that to be possible.

> solutions at this point?

Look at Vince Fuller's talks on this subject. Growth trends in BGP  
table size, computer speed,
etc., seem unfavorable for keeping BGP affordable. If you disagree, or  
see a solution to this, this
IMHO would be a good place to discuss it.

> And what's the justification for maintaining

That is another question, but at least in IPv4 it has the benefit of  
clarity.

Regards
Marshall

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Jan 2009 09:05:04 +1300

Bill,

On 2008-12-31 19:30, Tony Li wrote:

<snip>

> Adding more prefixes will hasten the inevitable.

Exactly. Thus far, since BGP4 was deployed, the size of the DFZ has
grown one order of magnitude less than the public Internet as a whole.
That's mainly a result of policy constraints on prefix length and
utilisation. If selfishness had ruled, we'd be vastly worse off by now.

   Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 31 Dec 2008 13:31:16 -0800

Brian,

> grown one order of magnitude less than the public Internet as a whole.

I'm curious: how do you measure the size of the public Internet as a  
whole?

> utilisation. If selfishness had ruled, we'd be vastly worse off by  

As much as I'd like to attribute a lack of selfishness to Internet  
service providers and their customers, I suspect a more accurate  
answer is that most folks haven't felt a need to multi-home (or  
couldn't justify the cost/complexity).  Yet.  I have a sneaking  
suspicion that will change when folks discover that all their  
communications, business and/or home monitoring, entertainment, etc.  
services are critically dependent on their Internet service and new  
products/services are made available that make multi-homing easier/ 
more cost effective.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Jan 2009 12:25:27 +1300

On 2009-01-01 10:31, David Conrad wrote:
> I'm curious: how do you measure the size of the public Internet as a whole?

We can be pretty sure it's between 500M and 1B active IP addresses.

> service providers and their customers, I suspect a more accurate answer
> is that most folks haven't felt a need to multi-home (or couldn't
> justify the cost/complexity).  Yet.  I have a sneaking suspicion that
> will change when folks discover that all their communications, business
> and/or home monitoring, entertainment, etc. services are critically
> dependent on their Internet service and new products/services are made
> available that make multi-homing easier/more cost effective.

Well, indeed, that is why there is cause for concern, even if we don't
have any hard scientific data.

    Brian