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