Eliot Lear wrote: > Hello, > > I've read over this draft, and I find it very confusing. The > title of > the draft is "Limited Range Addressing Requirements". > However, as one > goes through the document, there is both justification and > requirements. > What time is spent on the justification for "limited range" > addressing > is using IPv4 and NOT IPv6 logic.
There are some historic 'lessons learned' included here, but the real issue is meeting the expectations of the network managers who are currently using IPv4 logic. That is not to say we don't want them to change, but we can't assume they will even be willing to consider something that has a radically different architecture. > In part I presume this is due to > somebody's notion of IPv6 registry policies. I'm not sure. But here > are a few "for instances": > > > There is a strong requirement for an easy-to-get, stable, private > > address space for use within a limited range. Reasons include: > > > o avoid costs associated with running a registration infrastructure > > I've done this job for a very large company, as have many of you. I > presume what you are talking about above is the management of network > allocations. That doesn't stop whether or not one uses > site-locals XXX > errr.. limited range addressing. It does get easier with > IPv6 given the > fixed amount of space hosts have. The vast majority of time is spent > allocating and reallocating that which has already been > assigned by the > upstream authority. Only rarely is there any interaction > needed with an > upstream for additional allocations. It is a low frequency operation > not to be optimized for. You appear to assume that it is possible or desirable to expose the internal use of previous allocations, to show that some derivative of the HD ratio has been met to justify more space. It also appears you are looking at this from the perspective of managing allocations internal to the local network. The requirement was targeting the cost of maintaining an external central registry, and specifically at the cost aversion of small organizations, not large ones. > > > o avoid exposing internal network plans to competitors > > This is a procedural artifact of IPv4 that I have to believe can be > gotten around. In fact it probably could have been gotten > around with > IPv4 using existing auditing business relationships. > > Before I go through the remainder of the document on this list (and I > believe I have substantial disagreement) I'd request the > authors update > the Terminology section to include at least the following definitions: > > 1. "limited range" -- in particular, what is the semantic difference > between these and SLs? >From a routing perspective, nothing. SL meets the requirements for many network managers (it just doesn't meet the puritanical expectations of the IETF elite). From the identifier perspective, these are unambiguous. > 2. Redo "range" as its current definition doesn't help me > much. Send text. > 3. "validity" or "valid" 4. "filter" or "filtering" > Maybe I missed it, but it is not clear what you are looking for here. Other than to argue that the requirements of some network managers don't meet your goals for how they should run their networks, there doesn't seem to be any suggested fix for the document. We will be happy to change the document, but arguing someone else's requirement is not valid is not helpful. Tony > Thanks, > > Eliot > > > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
