Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 13 Aug 2003, Alan E. Beard wrote:
> per Pekka's request below. I'll review the other documents queued for last
> call within a few days.

Thanks.

> On Wed, 13 Aug 2003, Pekka Savola wrote:
> 
> > Hello all,
> >
> > Thanks to those who have sent feedback (both on and off-list).
> >
> > However, a couple of people reading through them is not enough.
> >
> > PLEASE review the documents ASAP and provide feedback.  We NEED stronger
> > support and acknowledgement from the WG that these have actually been
> > read!
> >
> 
> The comments below pertain to section 1.1 of  -ipv4survey-intro-01.
> Further comments on this document, mostly concerning section 4, will
> follow.
> 
> Most of the comments are changes in text for enhanced readability and for
> clarification of ambiguous terms.  Changes which do not effect substantial
> modification in the meaning of the original (as interpreted by this
> reader) are interpolated into the body of the text, with original wording
> shown in brackets immediately following the replacement text.
> 
> In a few cases suggesting for alternative wording are given which may
> alter the substantive meaning of the original: these changes are given in
> brackets immediately following the paragraph in which the original text
> appears, along with some explanation of the reasoning which prompted the
> suggested changes.
> 
> I will be interested to learn the reactions of the WG participants to the
> changes suggested below.  Comments are welcome; also flames, within
> reason. ;-)
> 
> Herewith the suggestions:
> 
> 
> 
> 1.1 Short Historical Perspective
> 
> There are many challenges that face the Internet Engineering community.
> The foremost of these challenges has been the scaling issue: how to grow a
> network that was envisioned to handle thousands of hosts to one that will
> handle tens of millions of networks with billions of hosts.  Over the
> years this scaling problem has been overcome with changes to the network
> layer and to routing protocols.  (Although largely ignored in the changes
> to network layer and routing protocols, the tremendous advances in
> computational hardware during the past two decades have been of
> significant benefit in managment of scaling problems encountered thus
> far.)
> 
> [Alternative text for sentence 2 of the paragraph above:
> 
> Over the years this scaling issue has been managed, with varying degrees
> of success, by changes made to the network layer and to routing protocols.
> 
> Reasoning: In light of our current discussions, it seems to me that the
> scaling issue (in actuality, a group of entangled issues) is still with
> us; we have so far avoided the worst of the postulated adverse effects by
> changes to routing protocols, network layer conventions, operational
> techniques described in later paragraphs of the extant draft.  Given the
> nature and extent of current activities which purport to address "the
> scaling issue", I don't think we have "overcome" the problem; it seems to
> me that scaling issues will be a fact of life in the IP world for the
> foreseeable future, although we now have a limited set of tools and
> techniques for dealing with some of the more pernicious effects, and it is
> within our capability to develop more such tools.]

Agreed.
 
> The first "modern" transition to the network layer occurred in during the
> early 1980's from the Network Control Protocol (NCP) to IPv4.  This
> culminated in the famous "flag day" of January 1, 1983.  IP Version 4
> originally specified an 8 bit network and 24 bit host addresses, as
> documented in RFC 760.  A year later IPv4 was updated in RFC 791 to
> include the famous A, B, C, D, & E class system.
> 
> [note: much of the above paragraph has been re-written, but, I think,
> without any substantive change in meaning. AEB]

Agreed.
 
> Networks were growing in such a way that it was clear that a convention
> for [original text: ...a need for...] breaking networks into smaller
> pieces was needed.  In October of 1984 RFC 917 was published formalizing
> the practice of subnetting.
> 
> By the late 1980's it was clear that the current exterior routing protocol
> used by the Internet (EGP) was insufficiently robust to [original: was not
> sufficient to] scale with the growth of the Internet.  The first version
> of BGP was documented in 1989 in RFC 1105.
> 
> Yet another scaling issue, exhaustion of the Class B address space, became
> apparent in the early 1990s. [original text: The next scaling issues to
> became apparent in the early 1990's was the exhaustion of the Class B
> address space.] The growth and commercialization of the Internet
> stimulated organizations to request IP [original text: ...Internet had
> organizations requesting IP...] addresses in alarming numbers. By May
> [original text: In May...] of 1992 over 45% of the Class B space was
> allocated.  In early 1993 RFC 1466 was published directing assignment of
> blocks of Class Cs to be given out in lieu of Class B allocations.
> [original text: ...Class C's be given out instead of Class B's.] This
> solved the problem of address space exhaustion but had significant impact
> of the routing infrastructure.

Agreed.
 
> [In the last sentence above, perhaps the word "solved" might be replaced
> by any of these words or phrases: "palliated" or "temporarily
> circumvented" or "alleviated" or "delayed the most pernicious effects of".
> The problem of exhaustion of IPv4 address space is still with us, and is
> likely to be extant until a substantial proportion of existing IPv4
> networks migrate to IPv6 and surrender their v4 allocations. This appears
> as a suggestion because the wording change also effects a significant
> alteration in the meaning of the original text: this extends well beyond
> a mere clarification.]

I think "temporarily circumvented" would be both simple enough and to the 
point.
 
> The number of entries in the "core" routing tables began to grow
> exponentially as a result of RFC 1466.  This led to the implementation
> of BGP4 and CIDR prefix addressing.  This may have solved the problem
> for the present but there are still potential scaling issues.
> 
> [Again, regarding the last sentence above, perhaps a more accurate reading
> of the current state of the technology would substitute for the word
> "solved" any of the following: "alleviated" or "circumvented".  This
> appears as a suggestion because the wording change also effects a
> significant change in meaning.]

Agree.  Solved is fine here, but a stronger wording is also fine, and 
perhaps better, e.g. alleviated.  It's clear that there is a scaling issue 
here.
 
> Growth in the population of Internet hosts since the mid-1980s would
> have long overwhelmed the IPv4 address space if industry had not supplied
> a solution in the form of Network Address Translators (NATs).[original
> text: Current Internet growth would have long overwhelmed the current
> address space if industry didn't supply a solution in Network Address
> Translators (NATs).] To do this the Internet has sacrificed the underlying
> "End-to-End" principle.

Ok.
 
> [Regarding the first sentence in the paragraph immediately above: some of
> the IPv6 WG members consider NAT not a solution at all; rather, they
> proclaim NAT an unmitigatedly BAD THING (emphasis in the original) and,
> even in the most generous and flattering of all possible interpretations,
> not better than a crude kludge. Perhaps the word "solution" might be
> replaced with "circumvention" for a reading more consistent with the
> common wisdom concerning NAT.  Additionally, should we make some mention
> of PNN address spaces (RFC 1918), without which NAT would probably not
> have become as widely implemented as it is today?  Based on what we see
> in enterprise implementations, either NAT or PNN alone would probably
> have been insufficient to relieve, even temporarily, the demand for v4
> address space arising from the rapid growth of IP host counts in business
> and academic environments.]

I agree that mentioning private address space in conjunction with NAT 
would seem like the right thing to do.  "Solve" might not be optimal here 
either, but either way is fine with me.
 
> In the early 1990's the IETF was aware of these potential problems and
> began a long design process to create a successor to IPv4 that would
> address these issues.  The outcome of that process was IPv6.
> 
> The purpose of this document is not to discuss the merits or problems of
> IPv6.  That is a debate that is still ongoing and will eventually be
> decided on how well the IETF defines transition mechanisms and how
> industry accepts the solution.  The question is not "should," but
> "when."

Ok.
 
> ************
> 
> Now, what think ye all?

Very good suggestions, thanks :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings