Re: [RADIR] proposed changes to Section 3

[Erik Nordmark <[e-mail]>]

Thomas Narten wrote:
> Going back through Section 3, here is what I'd propose we do:
> 
> Better define "superlinear". I.e., to make clear we don't know exactly
> what the curve is, but that it appears to be
> quardratic/polynomial/something. The fact that it is not linear is
> problematic because historically, technology is able to keep up with
> linear growth. Some definitions:

I think we need to do something with the "superlinear" text. I don't 
have a strong opinion on how to rewrite it.


> Tony has won me over and I think we need to collapse the two
> points. We can make pigs fly. The issue is at what cost. It is the
> cost fact that is the issue. Or, the cost factor will be looming large
> if we are really bumping into technical challenges.

Does that mean we should drop the 3.1 and 3.2 section headings? Or 
rename them?

>> 3.1.  Technical Aspects
>>
>>    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., paths for
>>    individual destinations must converge and stabilize within an
>>    acceptable time period).  Finally, the hardware needed to achieve
>>    this cannot have unreasonable power consumption or cooling
>>    demands.
> 
> Reword slightly to just list what routers have to do (technically) and
> how bigger tables/faster updates increases the challenge.

OK

After this I think we can say something a lot simpler than what is in 
the current section 3.2.

How about these two paragraphs (the terms and style probably needs to be 
made more similar to the rest of the document):

In general the Internet would benefit from the cost of the (routing) 
infrastructure not growing too rapidly as the Internet grows, since a 
lower infrastructure cost makes it possible to provide Internet service 
at a lower cost to a larger number of users. However, as the Internet 
scales up an ISP might have to handle more users/customers, higher 
bandwidth, different services (e.g., VPNs adding more internal routes 
for the ISP), which will invariably require more capable infrastructure. 
But in that case the ISP would normally find additional revenue 
associated with scaling up, thus cost recovery is feasible. Hence 
limiting the cost of self-induced scaling is a nice-to-have and not a 
requirement.

What is problematic is when the infrastructure cost for an ISP grows 
(rapidly) for reasons unrelated to the growth of the ISP. If an ISP that 
does not add new customers, upgrade the bandwidth for their customers, 
or provide new services need to frequently replace their infrastructure, 
then they are no natural cost recovery mechanisms. This is in essence 
what is happening with the scaling of the global routing table. An ISP 
that is part of the DFZ needs to upgrade their routers to handle a 
larger number of BGP routes and more frequent routing updates just to 
stand still with their current customers and services.


The above can then be followed by section 3.3 and 3.4.

    Erik

_______________________________________________
RADIR mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/radir