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

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 2 Jan 2009 16:17:06 +0200

Hello Bill 

Thank you for a good and concise summary of the various strategies for
routing scalability.

Related to your question about other BGP solutions, I am wondering how
well strategy D covers the proposals by Paul Francis and others:

- mapped BGP and
- virtual aggregation.

The former requires some extensions to BGP, in terms of announcing the
proper attributes for the maps and also its own RIBs. Rephrasing
strategy D to "Use plain old BGP with extensions" would capture the
mentioned BGP based solutions as well. (Notice that Paul's presentation
in the last meeting starts with "tries to minimize changes to BGP", is
not the same as "use the old BGP".)

Best regards
Hannu  

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext William Herrin
>Sent: Tuesday, December 30, 2008 17:33
>To: Ross Callon
>Cc: RRG
>Subject: Re: [rrg] Consensus call: Reject proposed strategy F?
>
>On Tue, Dec 30, 2008 at 12:55 AM, Ross Callon 
><[email-masked]> wrote:
>>> > 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?
>>>
>>> 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.
>>
>> I agree with Joel that it would be seriously inappropriate to tell 
>> GROW (or IDR) to stop thinking about engineering improvements to BGP.
>
>
>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
>
>
>--
>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
>
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Scott Brim <[email-masked]>
Date: Fri, 2 Jan 2009 09:30:14 -0500

Bill, I just got back from extended time away from mail.  Does "do
nothing" mean do nothing at lower layers?  Does "do nothing" include
the possibility of doing something compensatory at higher layers?

swb

Excerpts from William Herrin on Tue, Dec 23, 2008 10:29:35PM -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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 5 Jan 2009 13:30:10 -0800

>From: Brian E Carpenter [mailto:[email-masked]] 
>>From: William Herrin
 
>> As we use it now, BGP lacks sufficient scalability to see the
Internet 
>> 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. 

Yes and no... BGP has scaled remarkably well in supporting Internet
growth since 1994 from a pure routing growth perspective but the
resulting high-human-management care-and-feeding requirement of the
current infrastructure system combined with site hijacking and other
fundamental security challenges paint an entirely different picture of
its adequacy. I fear that BGP weaknesses have resulted in the Internet
being currently held together by bailing wire so that the system can be
readily subverted by accidental administrative mistakes or purposeful
cyber attacks. 
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Scott Brim <[email-masked]>
Date: Wed, 7 Jan 2009 10:59:58 -0500

Excerpts from Joel M. Halpern on Mon, Dec 29, 2008 04:39:04PM -0500:
> 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.

F says "solve the problems by means outside of routing and
addressing architecture".  This is a reasonable thing to do if we can.
The activity might mainly be focused outside of RRG, but RRG's job
would be to discover that activity and show how it either helps or
doesn't.  We do this already.

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

C isn't necessarily just 'geographic' aggregation.  It can include
creation of "superprefix" aggregates which are advertised in place of
longer prefixes but not tied to geography.  (Business-wise that
doesn't work either.)

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

Agree.