Let me see if I can understand your concerns better. It seems to me that your main objection to the hain/templin draft is that you see it as implying a particular solution genre, that being a limited range addressing scheme to replace site-locals. If this is what you find objectionable, then may I assume you are of the opinion that site locals don't *need* to be replaced? If so, then it seems you would favor an IPv6 addressing architecture that contains only link-local and global unicast addresses, i.e., nothing in between?
The hain/templin draft discusses requirements for sites that frequently change provider points of attachment, sites that are disconnected or intermittently-connected to providers, sites that merge with other sites, etc. In these cases, we require local application stability independent of any provider-assigned addressing. This requirement is not satisfied by link-locals for medium/large sites that comprise multiple links. Thus, all we have left are globals and the only way the "active" sites I described above could use these would be if the global prefixes could be obtained independent of any provider. Fine; so this just means that the sites would get their own prefixes and tell providers which prefixes to advertise instead of the other way around - right?
This would all be fine were it not for the fact that it would lead to immediate global routing table explosion on the order of the number of sites that procure their own prefixes which could be quite large. I'm willing to suspend disbelief and say that sometime down the road we might have a solution for scalable global routing, but in what timeframe can we expect to see something like that deployed? 1yr? 5yrs? 10yrs? longer?
Scalable global routing in a flat addressing space certainly seems like a utopian scenario if it can be achieved. But, if the deployment timeframe is looking like mid/long term, then we still need some sort of replacement for site-locals in the near term - right?
Thanks - Fred [EMAIL PROTECTED]
Michael Thomas wrote:
[EMAIL PROTECTED] writes: > If you think the document has a scoping issue (no pun intended), > then let's discuss that with a measured tone.
Yes, I think it has scoping issues. A name change, for starters. It should first lay out requirements of network operators, etc in terms of what they need to accomplish not how they can accomplish it. Take as a very large for example, address stability. That's not the requirement, per se. What they want is for topology tweaking to not adversely affect running applications. However protocols such as TCP are incapable of sustaining sessions across address changes which is typically needed when you want to move topology around. That's the reason I say that "stability" is a solution, not a requirement. Keeping addresses the same is *a* way of keeping applications from breaking, but not the only one. Mobile IP obviously comes to mind, and there are other ways we could envision like Fred's attempt at operational renumbering.
Another example is your "well known prefix". I'd
think that the requirement is that certain
services and/or classes of devices need to be
isolated and/or invisible from the other parts of
the net. A well known prefix is a way to do that,
but it doesn't necessitate local scope and again
isn't the only way to wall stuff off.
I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. That's not what we need right now. We need something that tries to be unbiased about the ultimate compromises we're going to have to make by saying what we want (requirements), what the possible frameworks are for addressing the requirements, and most especially what their possible downsides are. We don't need boosterism which tries to paper over the warts; all possible solutions have problems, what we need is an honest evaluation so that we can decide which path is the least objectionable.
Mike
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
