Subject: RE: [RADIR] problem statement (first cut)

From: "Azinger, Marla" <[email-masked]>
Date: Thu, 19 Apr 2007 13:10:29 -0400

>>I'm not saying that that makes the problem irrelevant, but it mean
it's more complicated to argue how big a problem is. E.g., do _all_
ISPs agree with this, or does the degree of pain vary among ISPs?<<

It's a problem.  I dont agree with debating how large of an issue it is and thus how worthy of us spending time on a solution.  It has become both a technical and business model related need.  I dont see anyone standing up and saying "no you cant create that new gadget because it uses up ip addresses".  And we shouldnt say such things.  Nor should we say "no you cant do TE with IPv6 because it uses up RIB".  I dont see any point on spending time doing a numbers poll to find out exactly how many entities use TE.  Its mute.  The need is there.

People/Company's need to do TE.  We need to figure out how to best support this requirement/use of technology.   

Cheers!
Marla

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, April 19, 2007 7:29 AM
To: Jason Schiller
Cc: [email-masked]
Subject: Re: [RADIR] problem statement (first cut) 

> The first is that the scalibility challange does not solely result from
> the DFZ.  Local information for a large ISP is also a significant
> contributer compounding the scalibility challenge.  Not sue where that
> text should be worked in.

I understand that. At the same time, it's clear that the DFZ is really
critical, because that can make/break the Internet as we know it. Lead
to Balkanization, etc.

For internal routes, one can argue that the extent of this problem is
at least partly a result of internal ISP decisions that have been
made, as opposed to global ones being forced from the outside. That
changes the nature of the debate as to how problematic this is.

I'm not saying that that makes the problem irrelevant, but it mean
it's more complicated to argue how big a problem is. E.g., do _all_
ISPs agree with this, or does the degree of pain vary among ISPs?

> The second is business driver of ROI with regard to depreciation models,
> and a possible compression of the upgrade cycle leading to at the worst,
> rolling upgrades...

yes. we need to describe this in terms that don't get us into the
cursed "business model" discussion that the IETF has to stay out of,
but I think we need to address it more concretely than we have so far.
Perhaps we can talk about it more generically in terms of common
business practices. 

> How about:

>    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.  This
>    will reduce the pressure to compress upgrade cycles allowing 
>    continued support of the currently utilized depreciation models
>    and return on investment scheduals.

This is all very abstract, and many people just won't understand the
degree to which this is really a problem. I suspect.

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

Thomas

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

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