Subject: [RADIR] another cut on problem

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Apr 2007 11:52:51 -0400

Here is my attempt at another version. Still not sure if I've got this
right, or if it is even going in the right direction...

Reminder: call at 3PM EDT today. I assume the following bridge still
works:

USA toll free: 866-692-3158
USA tool:      203-692-3158
Sweden toll free: 0200-884-628
Sweden toll:      46-8-566-19-394
Pass: 6633307

I may be a few minutes late to the call, but will definitely
join. Please start without me if I'm late.

Current text:

>  This super linear growth presents a scalability challenge for current
>  and/or future routers with regard to the resources needed to process
>  a larger and increasingly dynamic amount of routing information, to
>  store an increasing amount of associated state information in the
>  RIB, to populate a growing FIB, to perform forwarding lookups at line
>  rate in the FIB, and to initialize the RIB and FIB at boot time.
>
>  Regardless of whether it is possible to scale routing hardware to
>  keep pace with these factors while keeping other aspects such as
>  power consumption, volume and cost within acceptable bounds, if
>  growth continues it is clear that for any given piece of routing
>  equipment, its scaling limits will eventually be exceeded (although
>  one must acknowledge that other limits exist with respect to factors
>  unrelated to the growth of the routing system, such as packet rate,
>  one such could be the limiting factor).  It is desirable to maintain
>  or increase the useful lifespan of routing equipment, by improving
>  the scaling properties of the routing and addressing system.
>
>  Furthermore, the growth pattern observed is influenced by the scaling
>  properties of the current system.  If the system had better scaling
>  properties, it is possible that certain applications which are
>  currently untenable, for example ubiquitous multihoming, might become
>  widespread.  It is desirable that the routing and addressing system
>  exert the least possible backpressure on end user applications and
>  deployment scenarios, to enable the broadest possible use of the
>  Internet.

Possible alaternative:

   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?
   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?

   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 stablize
   within an acceptable time period). Finally, the hardware needed to
   achieve this cannot have unreasonable power consumption or cooling
   demands.

   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
   and construct viable business plans that provide an acceptable
   return on investment (i.e., one acceptable to investors).

   One aspect of planning concerns assumptions about the expected
   useable 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 pressure comes from maintaining
   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. [xxx: I'd
   like to strengthen this point somehow..]

   Alignment of Incentives
   
   Today's growth pattern is influenced by the scaling properties of
   the current system.  If the system had better scaling properties,
   it is possible that certain applications which are currently
   untenable, for example ubiquitous multihoming, might become
   widespread.  It is desirable that the routing and addressing system
   exert the least possible backpressure 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 "pain" for those routers that are part of the
   DFZ. Each individual prefix has 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 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 misaligned to allow normal
   market pressures to produce a reasonable balance between the
   benefit and costs of maintaining routing tables.

Thomas

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Apr 2007 10:47:57 -0700

>    return on investment (i.e., one acceptable to investors).

I personally don't have any issues with explicitly talking about 
business issues, but I don't know if others in the IETF will have a 
knee-jerk reaction to this.

I think we could capture a big part of the essence by instead talking 
about the need to plan and how the DFZ growth and update rate caused by 
everybody else makes it hard to plan.
I don't know if that will be sufficiently strong though.

   Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Apr 2007 13:56:32 -0400

> knee-jerk reaction to this.

IN any case, probably needs a paragraph explaining how the IETF
doesn't talk about business issues (and why), but explain also why
this is a bit of an elephant in the room situation and thus needs to
be understood.

> I think we could capture a big part of the essence by instead
> talking about the need to plan and how the DFZ growth and update
> rate caused by everybody else makes it hard to plan.  I don't know
> if that will be sufficiently strong though.

Right. I keep thinking though that if there is really an elephant in
the room, we should just be up front about it.

And why do people need to plan? Because this is about $$ and you have
to have a viable business plan...

There are also plenty of people around that don't understand even
really basic stuff about the economic/business issues of how the
internet is actually put together and operates, even at the 20k foot
level...

Thomas