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
<[email protected]> 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
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
