Subject: [RADIR] FWD: Impending publication: draft-iab-raws-report-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 03 Apr 2007 08:49:02 -0400

FYI, comment period is closing.

------- Forwarded Message

From: Leslie Daigle <[email-masked]>
To: IETF Announcement list <[email-masked]>
Cc: [email-masked]
Date: Wed, 07 Mar 2007 17:04:54 -0500
Subject: Impending publication: draft-iab-raws-report-01.txt 

The IAB is ready to ask the RFC-Editor to publish

        Report from the IAB Workshop on Routing and Addressing
                      draft-iab-raws-report-01.txt

as an Informational RFC.   This document is a report
from an invitational workshop convened by the IAB.
As such, it represents the opinions of the attendees
expressed at the time of the workshop.  

Please direct any comments to improve the clarity of
the report to the IAB ([email-masked]) by April 4, 2007.

The document can be found at

http://www.ietf.org/internet-drafts/draft-iab-raws-report-01.txt

 From the Abstract:

   This document reports the outcome of the Routing and Addressing
   Workshop which the Internet Architecture Board (IAB) held on October
   18-19, 2006 in Amsterdam, Netherlands.  The primary goal of the
   workshop was to develop a shared understanding of the problems that
   the large backbone operators are facing regarding the scalability of
   today's Internet routing system.  The key workshop findings include
   an analysis of the major factors that are driving routing table
   growth, constraints in router technology, and the limitations of
   today's Internet addressing architecture.  It is hoped that these
   findings will serve as input to the IETF community and help identify
   next steps towards effective solutions.

   Note that this document is a report on the proceedings of the
   workshop.  The views and positions documented in this report are
   those of the workshop participants and not the IAB.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

------- End of Forwarded Message

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 05 Apr 2007 11:04:54 -0400

FYI

From: Thomas Narten <[email-masked]>
To: Leslie Daigle <[email-masked]>
cc: [email-masked]
Date: Thu, 05 Apr 2007 11:04:21 -0400
Subject: Re: Impending publication: draft-iab-raws-report-01.txt 

2007-04-04: review of -01 (IAB wants to publish)

Overall: the report is good, easy to read and fairly balanced. Its
mostly ready to go.

Substantive:

I agree with comments made elsewhere (e.g., from Ross) that a stronger
disclaimer should be attached. It is fine to say "this is a snapshot
of what happened at the workshop". But then it is also appropriate to
point out that some of the positions taken continue to be discussed
and have not been broadly accepted as fact. Or something like that. I
worry about alarmist messages being taken out of context by folk that
don't konw what they are talking about...

The references need to be cleaned up (some specific statements are
made, with a reference, but the reference is too generic to see where
the specific statement comes from).

>    The ever
>    increasing user population, as well as multiple other factors
>    including multi-homing, traffic engineering, and policy routing, have
>    been driving the growth of Default Free Zone (DFZ) routing table size
>    at an alarming rate [DFZ].
   
>    [DFZ]      Huston, G., "Growth of the BGP Table - 1994 to Present",
>                http://bgp.potaroo.net, 2006.

need a better reference. This is just a home page and doesn't directly
support the sentence with the reference. And note that "alarming" is a
loaded term. Nowhere has "alarming" been defined or put into a broader
context. 

There are other places where assertions are made with a reference to
[DFZ]. These references need to be more specific.

>    The shape of the growth curve of the DFZ RIB has been the topic of
>    much research and discussion since the early days of the Internet
>    [DFZ].  There have been various hypotheses regarding the sources of
>    this growth.  The workshop identified the following factors as the
>    main driving forces behind the rapid growth of the DFZ RIB:

>    o  Suboptimal RIR address allocations, and

This points a negative finger at the RIRs that really isn't
helpful. The issue would seem to be that they "allow PI
assignments". Later, the document says the RIRs have no choice but do
do this. So calling the policy "suboptimal" is a poor choice of
words. Maybe it would be better to just say in the bullet something
like "PI assignments for end sites" (without saying this is good/bad),
as I think that is the issue being cited. (See the last paragraph of
Section 2.1.1.)

And it seems like a significant oversight to not mention end site
renumbering difficulties as a factor here. The (same) last paragraph
seems to blur the multihoming issue with the desire to have  PI space
to avoid renumbering.

>    The first one is a general concern with IPv6 deployment.  In the
>    absence of a scalable routing strategy, IPv6 has the potential to
>    exacerbate today's problems simply by virtue of its much larger
>    address space.  The only routing paradigm available today for IPv6 is
>    a combination of CIDR [RFC4632] and provider independent (PI) address
>    allocation strategies [PIPA] (and possibly SHIM6 [SHIM6] when that
>    technology is developed and deployed).  Thus the opportunity exists
>    to create a "swamp" (unaggregatable address space) that can be many
>    orders of magnitude larger than what we faced with IPv4.  Although
>    this is not independent of the concerns raised in both Section 2.1
>    and Section 2.2, the advent of IPv6 and its larger address space have
>    the potential to make these problems much worse if a solution isn't
>    found.

One gripe I have generally, is a tendancy to blame IPv6 for making the
problem worse. Lots of people do it, and the above repeats it (though
less strongly that is often the case). Actually, it is continued
growth that is the issue. IPv6 allows continued growth, but it is the
underlying growth that is the problem. Stated another way, I could say
"IPv4 doesn't have a scaling problem because we'll run out of
addresses before we reach route scaling limitations". But most people
wouldn't view that is helpful. Should IPv6 be blamed for allowing
continued growth? Read the first couple of sentences above.  Is the
implication/conclusion that we should not deploy IPv6? And is
introduction of IPv6 _in the short term_ the problem? Or is it the
overall _long term_ growth trend that is the issue?

Indeed, section 7.1 has a more balanced statement on this topic.

>    today [CIDRRPT], and is projected to increase to 370,000 or more
>    within 5 years.  Some workshop participants projected that the DFZ

Reference to said projection?

>    example, a BGP router may observe up to 400,000 BGP updates on a
>    single day [BGP2005].  Such UPDATE churn problems are not limited to

400K/day = 277 updates/minute. Is that a large number? Hard for me to
say. It would be better to have more compelling data about updates
that show this is a  real problem. My point is that the statement,
devoid of context, has no meaning.

>    prefixes).  In this section, we discuss in more detail why this
>    alarming trend is accelerating.

There is that "alarming" term again. Please provide more detail about
what "alarming" means, or use different words. (Indeed, search for
"alarm" in the text and think whether the use of the term is
appropriate.)

>    geographical locations.  The first approach does not scale; the
>    second approach represents a fundamental change to the Internet
>    routing system and its economic model, and imposes undue constraints
>    on ISPs.  These proposals were found to be incomplete, as they

The word "undue" above is interesting, as that is a value
judgement. Who says that changing the current business model places
undue constraints on ISPs? I'm sure the ISPs say that...

Perhaps reword to say it would change fundamental existing business
models and assumptions which can't easily be changed, or some such...

>    to applications.  However, there are often cases where a more
>    specific route (a longer prefix) has failed, yet the destination can
>    still be reached through an aggregated route (a shorter prefix).  In
>    these cases, the long convergence delay does impact application
>    performance.

This seems to contradict an earlier assertion in Section 3.1.2:

>    primary ISP.  A problem with multihoming arises when a customer's PA
>    IP prefixes are advertised by AS(es) other than their 'primary'
>    ISP's.  Because of the longest-matching prefix forwarding rule, in
>    this case the customer's traffic will be directed through the non-
>    primary AS(es).  In response, the primary ISP is forced to de-
>    aggregate the customer's prefix in order to keep the customer's
>    traffic flowing through it instead of the non-primary AS(es).

You can't argue it both ways... Which is it?

>    that we seem running out of time.  As explained in Section 4, the
>    current RIB growth trend is leading towards cost increases at a rate
>    greater than the nominal depreciation cycle.

Actually, section 4 didn't do this, IMO. There is little talk about
depreciation cycle in concrete terms, and what the normal refresh
cycle is or should be. This is presumably a difficult thing to talk
about, as it's a business issues. But it goes to the heart of how
"big" the problem is in reality.

Indeed, going back to Section 4:

> 4.5.  Summary
> 
>    Given the uncontrolled nature of it's growth rate, there is some
>    concern about the long term prospects for the health and cost of the
>    routing subsystem of the Internet.  The ongoing growth will force
>    periodic technology refresh.  However, the growth rate can possibly
>    exceed the rate that can be supported at constant cost based on the
>    development costs seen in the router industry.  Since high end
>    routing is based on low volume technology, the cost advantages that
>    the bulk of the broader computing industry sees based on Moore's law
>    are not directly inherited.  This leads to a sustainable growth rate
>    of 1.3x/2yrs for the forwarding table and 1.2x/2yrs for the routing
>    table.  Given that the current baseline growth is at 1.3x/2yrs with
>    bursts that even exceed Moore's law, the trend is for the costs of
>    technology refresh to continue to grow, indefinitely, even in
>    constant dollars.

Maybe this is just not my area, but I have not been convinced by the
above. There is detail/rigor missing in this section. Where has it
been shown, for instance, that the "baseline growth is at 1.3x/2yrs"?

>    system and hardware upgrade cycles.  Many attendees expressed a
>    desire that the scaling properties of the system can allow the
>    hardware to keep up with the Internet growth at a rate that is
>    comparable to the current costs, for example allowing one to keep a
>    5-year hardware depreciation cycle, as opposed to a situation where
>    scaling leads to accelerated cost increases.

Here is more on depreciation, and the first time I see a specific
target/number (e.g., 5 years). Yet, the assumptions being made here
are key to point of how "urgent" the problem really is.

Nits:

>    aggregation leads to routing scalability problem because, absent some

tense of "problem" not right.

>    Presentations made at the workshop showed that the DFZ RIB has been
>    growing at greater than linear rates for several years [DFZ].  While

need a more specific reference.

> 2.2.  Problem #2: The Overloading of IP Address Semantics

Given the heading, I expected to see a "Problem #1: " heading earlier,
but didn't. Nor is their a "problem #3:", etc.

>    [BGP2005]  Huston, G., "2005 -- A BGP Year in Review",
>                http://potaroo.net/presentations/index.html, 2005.
> 
>

URL doesn't work. And more generally, there are a lot of URLs in the
citation. How stable will these be going forward? Will they still work
in 2 years?

>    entries to 175,000 entries [BGP2005]; this number has reached 200,000
>    today [CIDRRPT], and is projected to increase to 370,000 or more

s/today/in December, 2006/

>    o  Finally, TE is sometimes deployed to enforce certain forms of
>       policy (e.g., Canadian government traffic is not permitted to
>       transit through the United States).

s/is not/might not be/

>    [Editor's note: The information in this section is gathered from
>    presentations given at the workshop.  The presentation slides can be
>    retrieved from the pointer provided in Appendix D.  It is worth
>    noting that this information has generated quite a bit of discussion
>    since the workshop, and as such requires further community input.]

make caveat even stronger?

>    [Editor's note: The exact implementation of a high-performance
>    router's RIB and FIB memories is the subject of much debate.]

and add: today's designs may not consider alternate designs that are
possible.

>    In routers, DRAM is used for storing the RIB and, in lower end
>    routers, is also used for storing the FIB.  Historically, DRAM
>    capacity grows at about 4x every 3.3 years.  This translates to 2.4x
> 

Reference?

>    The increasing deployment of VPN/VRF is considered another major

term VRF is not defined.

>    definedEin the contextEof the Internet routing system; the definition

extra characters?

>    enterprises to penetrate deeply into variously parts of the

s/variously/various/

>    While IGPs are designed to and do converge more quickly that BGP

s/that/than/