Subject: [RADIR] Last Call on Section 3 of Problem statement

From: Thomas Narten <[email-masked]>
Date: Mon, 07 May 2007 14:24:09 -0400

I've revised the draft (making the editorial changes that Marla
flagged, and expanding the acknowledgment's section to list the
directorate) and I'm issuing a short Last Call on Section 3 (the main
text we've been discussing) that ends Tuesday during our RADIR call.

John, could you please have a look at the document and let us know if
you have any feedback? The rest of us have indicated that we're OK
with sending it on to Olaf and Russ for their review.

That said, I'd really like to have an explicit indication from you
that you've read the latest text and are comfortable with it. Or if
not, feedback on your concerns.

Thanks,
Thomas

Network Working Group                                          T. Narten
Internet-Draft                                               May 7, 2007
Intended status: Informational
Expires: November 8, 2007

                Routing and Addressing Problem Statement
               draft-narten-ram-problem-statement-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 8, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Narten                  Expires November 8, 2007                [Page 1]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

Abstract

   Problem statement for the route scaling problem.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terms and Definitions  . . . . . . . . . . . . . . . . . . . .  4
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Technical Challenge  . . . . . . . . . . . . . . . . . . .  5
     3.2.  Business Challenge . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Alignment of Incentives  . . . . . . . . . . . . . . . . .  6
   4.  Pressures To Deaggregate . . . . . . . . . . . . . . . . . . .  8
     4.1.  Traffic Engineering  . . . . . . . . . . . . . . . . . . .  8
     4.2.  Multihoming  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  End Site Renumbering . . . . . . . . . . . . . . . . . . .  8
     4.4.  Acquisitions and Mergers . . . . . . . . . . . . . . . . .  8
     4.5.  RIR IPv4 Policies favor Conservation over Aggregation  . .  8
   5.  Pressures on Routing Update Rate . . . . . . . . . . . . . . .  9
     5.1.  Interconnection Richness . . . . . . . . . . . . . . . . .  9
     5.2.  Multihoming  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Traffic Engineering  . . . . . . . . . . . . . . . . . . .  9
     5.4.  Questionable Operational Practices?  . . . . . . . . . . .  9
   6.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

Narten                  Expires November 8, 2007                [Page 2]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

1.  Introduction

   Prompted in part by the recent IAB workshop on Routing & Addressing
   [RAWS-REPORT], there has been a renewed focus on the problem of
   routing scalability within the Internet.  The issue itself is not
   new, with discussions dating back at least 10-15 years [GSE, ...].

   This document attempts to define the "problem", with the aim of
   describing the essential aspects so that the community has a way of
   evaluating whether proposed solutions actually address or impact the
   underlying problem or "pain points" in a significant manner.

Narten                  Expires November 8, 2007                [Page 3]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

2.  Terms and Definitions

   Default Free Zone (DFZ):  That part of the Internet where routers
      maintain full routing tables.  Many routers maintain only partial
      routes, having explicit routes for "local" destinations plus a
      "default" for everything else.  For such routers, building and
      maintaining routing tables is relatively simple because the amount
      of information learned and maintained can be small.  In contrast,
      routers in the DFZ maintain complete information about all
      reachable destinations, which number in the hundreds of the
      thousands of entries.

   Routing Information Base (RIB):  The data structures a router
      maintains that hold the information about destinations (i.e.,
      prefixes) and paths to those destinations.  The amount of state
      information maintained is dependent on a number of factors,
      including the number of individual prefixes, the number of BGP
      peers, the number of distinct paths, etc.  The RIB may also
      include information about unused ("backup") paths for a given
      prefix as well as the active path(s) used for forwarding.

   Forwarding Information Base (FIB):  The actual table used while
      making forwarding decisions for individual packets.  The FIB is a
      compact, optimized version of the RIB, containing only the
      information needed to actually forward individual packets, i.e.,
      mapping a packet's destination address to an outgoing interface
      and next-hop.  The FIB only stores information about paths
      actually used for forwarding; it typically does not store
      information about backup paths.

Narten                  Expires November 8, 2007                [Page 4]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

3.  Background

   Within the DFZ, both the size of the RIB/FIB and their update rate
   resulting from routing updates have historically increased at a
   greater than linear rate.  Specifically:

   o  The number of individual prefixes that are propagated into the DFZ
      is increasing at a super-linear rate.  The reasons behind this
      increase are varied and discussed below.  However, each individual
      prefix that appears in routing updates, requires state in the RIB
      (and possibly the FIB), and consumes processing resources when
      updates related to the prefix are received.

   o  The rate of routing updates is increasing, requiring routers to
      process updates at an increased rate or converge more slowly if
      they cannot.  The rate increase is driven by a number of factors
      (discussed below).

   This super linear growth presents a scalability challenge for current
   and/or future routers.  There are two aspects to the challenge.  The
   first one is purely technical: can we build routers (i.e., hardware &
   software) actually capable handling the load, both today and going
   forward?  The second challenge is one of economics: is the cost of
   developing, building and deploying such routers economically
   sustainable, given current and realistic business models that govern
   how ISPs operate as businesses?

3.1.  Technical Challenge

   The technical challenge of building routers relates to the resources
   needed to process a larger and increasingly dynamic amount of routing
   information.  More specifically, routers must maintain an increasing
   amount of associated state information in the RIB, they must be
   capable of populating a growing FIB, they must perform forwarding
   lookups at line rates (while accessing the FIB) and they must be able
   to initialize the RIB and FIB at boot time.  Moreover, this activity
   must take place within acceptable time frames (i.e., the overall
   system must converge and stabilize within an acceptable time period).
   Finally, the hardware needed to achieve this cannot have unreasonable
   power consumption or cooling demands.

3.2.  Business Challenge

   Even if it is technically possible to build routers capable of
   meeting the technical and operational requirements, it is also
   necessary that the overall cost to build, maintain and deploy such
   equipment meet reasonable business expectations.  ISPs, after all,
   are run as businesses.  As such, they must be able to plan, develop

Narten                  Expires November 8, 2007                [Page 5]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

   and construct viable business plans that provide an acceptable return
   on investment (i.e., one acceptable to investors).

   One aspect of planning concerns the assumptions made about the
   expected usable lifetime of purchased equipment.  Businesses
   typically expect that once deployed, equipment can remain in use for
   some projected amount of time (e.g., 3-5 years).  That is, in the
   absence of a need to upgrade in order to provide new services or
   functionality (e.g., increased traffic, additional customers, etc.),
   deployed equipment should remain usable.  An increase in the
   resources required to support larger or more dynamic routing tables,
   however, can undermine such assumptions, forcing upgrades earlier
   than had been planned or forecast.  This undermining of planning is
   particularly problematic when the increase in routing demand
   originates external to the ISP, and the ISP has no way to control or
   limit it (e.g., the increased demand comes from being part of the
   DFZ).

   From a business perspective, it is desirable to maintain or increase
   the useful lifespan of routing equipment, by improving the scaling
   properties of the routing and addressing system.

3.3.  Alignment of Incentives

   Today's growth pattern is influenced by the scaling properties of the
   current system.  If the system had better scaling properties, we
   would be able support and enable more widespread usage of certain
   applications such as multihoming and traffic engineering.  Currently
   the system does not allow everyone to multihome, as there are some
   barriers to multihoming due to operational practices that try to
   strike a balance between the amount of multihoming and preservation
   of routing slots.  It is desirable that the routing and addressing
   system exert the least possible back pressure on end user
   applications and deployment scenarios, to enable the broadest
   possible use of the Internet.

   One aspect of the current architecture is a misalignment of cost and
   benefit.  Injecting individual prefixes into the DFZ creates a small
   amount of "pain" for those routers that are part of the DFZ.  Each
   individual prefix has a small cost, but the aggregate sum of all
   prefixes is significant, and leads to the core problem at hand.
   Those that inject prefixes into the DFZ do not generally pay the cost
   associated with the individual prefix -- it is carried by the routers
   in the DFZ.  But the originator of the prefix receives the benefit.
   Hence, there is misalignment of incentives between those receiving
   the benefit and those bearing the cost of providing the benefit.
   Consequently, incentives are not aligned properly to produce a
   natural balance between the cost and benefit of maintaining routing

Narten                  Expires November 8, 2007                [Page 6]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

   tables.

Narten                  Expires November 8, 2007                [Page 7]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

4.  Pressures To Deaggregate

   Note: the remainder of this document is in rough outline form and
   remains to be completed.  We decided to defer completing this section
   in order to focus on the problem statement in Section 3 first.

   There are a number of factors behind the increase in the quantity of
   prefixes appearing in the DFZ.  From a theoretical perspective, the
   number of prefixes in the DFZ can be minimized through aggressive
   aggregation [RFC4632].  In practice, strict adherence to the CIDR
   principles is difficult.

4.1.  Traffic Engineering

   Simply include Section 3.1.3 of RAWS Report?

4.2.  Multihoming

   Simply include Section 3.1.2 of RAWS Report?

4.3.  End Site Renumbering

   Pain of end site renumbering leads to demand for PI assignments, each
   of which translates into an additional prefix in the DFZ.

4.4.  Acquisitions and Mergers

4.5.  RIR IPv4 Policies favor Conservation over Aggregation

   Especially in IPv4, subsequent allocations not always from same block
   as previous allocation...

Narten                  Expires November 8, 2007                [Page 8]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

5.  Pressures on Routing Update Rate

5.1.  Interconnection Richness

5.2.  Multihoming

5.3.  Traffic Engineering

5.4.  Questionable Operational Practices?

Narten                  Expires November 8, 2007                [Page 9]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

6.  Problem Statement

   There is a need for an approach to routing and addressing that:

   1.  reduces the growth rate of the size of the DFZ routing load

   2.  allows any end site wishing to multihome to do so

   3.  Supports ISP and enterprise TE needs

   4.  Allows end sites to switch providers while minimizing
       configuration changes to internal end site devices.

   5.  Provides meaningful benefits to the parties who bear the costs of
       deploying and maintaining the technology.

Narten                  Expires November 8, 2007               [Page 10]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

7.  Security Considerations

   None.

Narten                  Expires November 8, 2007               [Page 11]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

8.  Acknowledgments

   The initial version of this document was produced by the Routing and
   Addressing Directorate (http://www.ietf.org/IESG/content/radir.html).
   The membership of the directorate at that time included Marla
   Azinger, Vince Fuller, Vijay Gill, Thomas Narten, Erik Nordmark,
   Jason Schiller, Peter Schoenmaker, and John Scudder.

Narten                  Expires November 8, 2007               [Page 12]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

9.  Informative References

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

Narten                  Expires November 8, 2007               [Page 13]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

Author's Address

   Thomas Narten (Editor)

Narten                  Expires November 8, 2007               [Page 14]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Narten                  Expires November 8, 2007               [Page 15]


_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 8 May 2007 16:20:17 +0300

Comments in line.

--John

> not, feedback on your concerns.
[snip]
>    resulting from routing updates have historically increased at a

"their update rate resulting from routing updates" has a bit of  
department of redundancy department feel to it.  Can't it just say  
"their update rate"?  Or am I missing some shade of meaning?

>       increase are varied and discussed below.  However, each  

s/However, each/Each/

>       prefix that appears in routing updates, requires state in the  

s/updates, requires/updates requires/

>       (and possibly the FIB), and consumes processing resources when

s/FIB), and/FIB) and/

Although style authorities do differ on the use of comma before "and."

>       they cannot.  The rate increase is driven by a number of factors

It occurs to me that the two things listed are unlike each other, in  
that DFZ growth is a more basic parameter than update rate.  Basically,

	update rate = f(DFZ size, mean prefix stability)

So the second bullet is partly dependent on the first.  There are a  
number of ways we could reflect this:

We could leave the text as it stands.

We could simply mention in the second bullet that it's a derived  
quantity, as in "Due in part to the growth of the DFZ, the rate of  
routing updates is increasing...".

We could allude to prefix stability directly.  I took a quick glance  
at Geoff's Prague slides and eyeballing the numbers off of his backup  
graphs (slides 16 and 22) leads me to believe that mean prefix  
instability is indeed increasing.  This is of course one person's  
quick glance at another person's snapshot from one vantage point in  
the network -- hardly an exhaustive study.  But anyway, if we want to  
refactor the text to directly mention route stability we could say  
something like this:

    o  The number of individual prefixes that are propagated into the  
DFZ
       is increasing at a super-linear rate.  The reasons behind this
       increase are varied and discussed below.

This increase has several consequences.  Each individual DFZ prefix  
appears in routing updates, requires state in the RIB (and possibly  
the FIB), and consumes processing resources when updates related to  
the prefix are received.

    o  There is some evidence that the stability of individual  
prefixes in
       the DFZ is decreasing.

The update rate is proportional to both route stability and DFZ  
size.  The consequence of the above is that the rate of routing  
updates is increasing, requiring routers to process updates at an  
increased rate or converge more slowly if they cannot.

>    forward?

The answer to this question is "yes".  I would suggest removing the  
rhetorical question.

>    The second challenge is one of economics: is the cost of

Do we really want the IETF to try to answer this rhetorical question?

>    limit it (e.g., the increased demand comes from being part of the

The above is kind of a can of worms.  For example, if we think (as  
some of us do) that we can continue to build routers with cost and  
depreciation which are constant relative to past generations of  
routers and growth trends, is that good enough and we can all move on  
to some other pretext for Fine Lunches And Dinners?

Or is the subtext here "we want the real cost of routers to go  
down"?  Or something else?  (What?)  (Personally, I want the real  
cost of everything in my life to go down, but there are frequently  
tradeoffs where pushing down the cost of one thing makes the cost of  
something else go up.)

Given that the business question does seem to be the (or at least an)  
elephant in the corner, simply removing the text doesn't seem like a  
good idea at all.  However, bringing it up begs questions such as the  
above.  Who is going to answer them?  The IETF?  Really, I think that  

>    properties of the routing and addressing system.

Is about as much as the IETF can say about business issues without  
straying completely into terra incognita.

If we are going to leave the longer form in, I think we need to  
acknowledge that many factors go into determining the price, volume,  
and power consumption of a router.  They include the specific thing  
listed ("larger or more dynamic routing tables") but also other  
factors such as packet forwarding rate and feature set to name just a  
couple of the most obvious.  In fact, the size of the routing table  
is not the most important of these factors.  Simply put, if we were  
to wave a magic wand and somehow fix the DFZ growth rate, it might  
not do a whole lot to change the business problems being complained  
of.  We ought not imply that it surely would.

>    possible use of the Internet.

I have no particular problem with the sentiments expressed above -- I  
think multihoming and TE are great, should be supported, etc.  But  
the closer focus on these two specific applications doesn't quite  
capture the point I was trying (not very well) to express with the  
earlier version.  That point was that part of the measure of a good  
internet architecture is that it doesn't only enable current practice  
to continue, but also potentially enables uses we haven't even  
thought of yet.  Noel Chiappa makes this point from time to time, and  
I agree with it.  Vince also brought it up at our f2f meeting in  
Prague, in the guise of "we should focus on carrots as well as sticks".

One problem, though, is that "please give me an architecture which is  
infinitely flexible for the future" isn't terribly actionable.  Which  
may be why the previous text I wrote was so squishy.

Anyone think we should try to capture the broader point, or should we  
abandon it as too touchy-feely?

Since I have nothing better to propose at this point, the quoted text  
is o.k. with me absent any other ideas.

> Internet-Draft  Routing and Addressing Problem Statement        May  
[snip]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 08 May 2007 11:04:20 -0400

Thanks for the comments John.

My take.

> "their update rate"?  Or am I missing some shade of meaning?

Agree this needs fixing. Marla suggested some wording too, but it
didn't feel right either. What you quoted above was my most recent
attempt. Anyway, how about:

    Within the DFZ, both the size of the RIB/FIB and the overall
    update rate have historically increased at a greater than linear
    rate. Specifically:

And I agree with your later point that the distinction of "overall
update rate" vs. "mean update per prefix" is important to capture
correctly. But perhaps the above is OK for the opening sentence of
this section.

> s/However, each/Each/

OK.

> s/updates, requires/updates requires/

Done.

> Although style authorities do differ on the use of comma before
  "and."

Actually, in this case having the comma is incorrect, because the
second clause does not have its own subject. (Isn't grammer fun!)

> 	update rate = f(DFZ size, mean prefix stability)

Agreed.

> refactor the text to directly mention route stability we could say  

I'd like to be even more explicit than the wording you suggest. How
about:

3.  Background

   Within the DFZ, both the size of the RIB/FIB and the overall update
   rate have historically increased at a greater than linear rate.
   Specifically:

   o  The number of individual prefixes that are propagated into the DFZ
      is increasing at a super-linear rate.  The reasons behind this
      increase are varied and discussed below.  Because each individual
      prefix requires resources to process, any increase in the number
      of prefixes requires a corresponding increase in resources.  Each
      individual prefix that appears in routing updates requires state
      in the RIB (and possibly the FIB) and consumes processing
      resources when updates related to the prefix are received.

   o  The overall rate of routing updates is increasing, requiring
      routers to process updates at an increased rate or converge more
      slowly if they cannot.  The rate increase is driven by a number of
      factors (discussed below).  It should be noted that the overall
      routing update rate is dependent on two factors: the number of
      individual prefixes and the mean per-prefix update rate.  While it
      is clear that the overall number of prefixes is increasing super-
      linearly, there is also some evidence that the mean per-prefix
      update rate is increasing as well [need reference].

> The answer to this question is "yes".  I would suggest removing the  

I don't think it is rhetorical. I sense honest disagreement on this
point. And I don't think one can argue with certainity that the answer
is yes without  making assumptions about future growth -- and there is
quite a bit of potential uncertainty here. (e.g., if PI assignments  become
the norm on a large scale, what happens then?)

> Do we really want the IETF to try to answer this rhetorical

Not necessarily answer, but make clear that this is an issue.

My understanding is the that IETF cannot discuss pricing and business
models (or develop technology that enforces particular business
models), etc. There are anti-trust issues. But that doesn't mean we
are completely oblivious to economics.

When we make engineering tradeoffs, economics (indirectly) are really
part of the factors. Is a solution "too complex"? Is that an
engineering argument or is there an economic factor to that too?  Can
the complexity be managed?  What is the operational cost? etc.

> to some other pretext for Fine Lunches And Dinners?

I think this is a valid point. It gets back to the question of whether
there is a "problem" that need fixing or an "opportunity" to provide
new services (which presumably requires a bigger fix). Personally, I
think both are true, and it's actually hard to separate the two in
practice.

Fundamentally, there are many pressures increasing the number of
prefixes in the DFZ.  Can we keep cost and depreciation of routers
constant as pressure on the DFZ increases? How much do we have to push
back on DFZ growth to maintain this? Will we be able to in practice?
(e.g., consider the RIRs and how they were forced to adopte PI for
IPv6).

> straying completely into terra incognita.

Which is presumably why we have the current text. :-)

> of.  We ought not imply that it surely would.

This is a key point. I suspect many will argue that the issue of
router cost/depreciation is not dominated by the route scale problem
alone.

But what I am also hearing from ISPs is that the cost is an issue and
they don't want it dismissed. At least, there seems to be strong
support for that view from others on the directorate.

> may be why the previous text I wrote was so squishy.

Right. I would like to stick with things that are actionable, to the
degree we can. And I'm very wary of getting sucked into a generic call
to "improve the architecture" for "uses yet unimagined". I've seen
that too often be a recipe for IETF WGs to go off in the weeds because
there is no consensus on what problem is being adddressed, and hence,
whether a proposed solution actually solves a problem of interest, or
whether one solution is "better" than another at solving the nebulous
problem...

> is o.k. with me absent any other ideas.

I'm open to suggestions here, but I think we are at a "send text"
stage now.

Thanks again for the comments!

Thomas

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 8 May 2007 18:28:39 +0300

> support for that view from others on the directorate.

As to the particular paragraph (double) quoted above, I wasn't saying  
that cost isn't an issue, nor suggesting that it be dismissed.  I'm  
saying that

	cost = f(DFZ size, packet rate, features, many more things)

But the text as it stands could leave the casual reader to conclude that

	cost = f(DFZ size)

That would be quite wrong.

I can think of a couple of possible fixes, and perhaps both should be  
employed.  One is to explicitly raise the caveat I have above.  The  
other is to change the language slightly -- I think it's easy to  
agree that it would be desirable for a proposed Internet architecture  
to preclude or put off obsolescence *due to DFZ size*.  What is wrong  
is to imply that this would eliminate all sources of obsolescence.

I think people who are focused on Internet architecture issues tend  
to avoid this point because novel Internet architectures appear to  
only be able to affect the DFZ term in the equation.  That's OK and  
worth pursuing, but shouldn't blind us to the other terms -- or lead  
us to oversell an Internet architecture based "solution".

I would send text but must run now.

--John