[rrg] Consensus call: Reject proposed strategy F?

[Joel M. Halpern]

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

Brian E Carpenter wrote:
> Hi Bill,
> 
> 
> On 2008-12-30 09:35, William Herrin wrote:
>> On Mon, Dec 29, 2008 at 3:13 PM, Brian E Carpenter
>> <brian.e.carpenter at gmail.com> wrote:
>>> 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.
>> 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?
> 
> 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
> _______________________________________________
> rrg mailing list
> rrg at irtf.org
> https://www.irtf.org/mailman/listinfo/rrg
>