On Fri, 2008-06-20 at 08:39 -0700, Tony Li wrote: > Yes, the transition to this is not smooth, but unless we create a new > namespace, we are effectively endorsing the semantic overload that we > have > today and will have to live with it in perpetuity.
I'm not sure about everybody else, but lately I have had a lot of trouble determining the constraints of our proposal. I'll write what I think is going on, and let me know if I made any mistakes. We need an architecture that solves the scalability problem in routers, while simultaneously providing easy multihoming and easy connectivity change for customer networks. The architecture must be made compatible with v6. For any proposal that requires any change(basically any proposal), there is an apparent constraint that some driver must be present to ensure that these changes occur. I'll call it the 'driver constraint'. Since Tony wants a long-term solution, we can wait 30(more?) years for this driver to appear or grow naturally. We can even do things in that time to encourage the growth of drivers. But it still must be present, so economic issues ARE relevant to us, correct? Technical issues are also relevant, of course. But at some point, some network operator needs to be motivated to make the changes necessary for the proposal. The RRG has not yet been able to agree on what motivations are possible in the long term (have we even decided on the duration of this 'long term'? 1000 years? 50 years? 10 years?). An example of this lack of agreement is that Bill Herrin just made arguments for the need for PI space due to some current operational practices. Tony Li rebutted that these practices can change over time. Is it safe to assume that any proposal requiring these changes must come with some reasoning that these changes will indeed occur over time? Robin suggests that instead of trying to develop a general driver constraint, we should recommend specific proposals and discuss them. For any particular proposal, we know the changes proposed. We can argue about the feasibility of the changes and evaluate the proposal based on this as well as the proposal's effectiveness, security, etc. However, Tony doesn't think this is a good course of action. Currently, we are trying to nail down a detailed description of the driver constraint that will serve as a guideline for any proposal. The driver constraint will be a long list of conditionals going 'if we did action set X, in Y years, change set Z will be possible.' The purpose of this post is not to take a position. I'm just trying to make sure that I'm following what's going on. Maybe this post will generate discussion that gives me(and hopefully some others) a clearer understanding of what everyone is currently trying to do here. Thanks. Dan Jen -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
