Subject: [RADIR] Routing & Addresssing problem statement

From: Thomas Narten <[email-masked]>
Date: Wed, 23 May 2007 15:51:38 -0400

INT/RTG/OPS ADs, RRG Chairs:

The Routing & Addressing Directorate has produced a first-cut at a
problem statement. At this point, the statement has been reviewed by
the directorate and by Russ Housley and Olaf Kolkman. We are now ready
to expand the circle of reviewers and seek your input/feedback. Our
current plan is to get feedback from you, revise the statement as
appropriate and then send it out for wider review on the RAM list.  We
hope to be able to do that by Wednesday, May 30, so that the IAB can
also review the statement at its retreat next week. Hence, it would be
helpful if you could review and respond quickly.

Our goal with section 3 is to clearly define the problem in general
terms, in order to frame the discussion. It is that section in
particular we request review of.

Sections 4 and 5 are expected to address the specific pressures on the
general problem as defined in section 3.  Sections 4 and 5 are an
attempt to catalog the specific pressures on deaggregation and
routing churn respectively.  At the moment, sections 4 & 5 are just
placeholders, and we hope to fill those in over the next week based on
information documented in the RAWs report.  As the document's audience
expands, it is our hopes that sections 4 and 5 will be added to,
clarified, and finally word smithed into a more flushed out and
polished inventory of specific pressures.

Document appended below.

For RADIR,
Thomas

Network Working Group                                          T. Narten
Internet-Draft                                              May 15, 2007
Intended status: Informational
Expires: November 16, 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 16, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Narten                  Expires November 16, 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 . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Alignment of Incentives  . . . . . . . . . . . . . . . . .  6
     3.4.  Table Growth Targets . . . . . . . . . . . . . . . . . . .  7
   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
     5.5.  RIR IPv6 Policy is Not Balanced  . . . . . . . . . . . . .  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 16, 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 16, 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.

   Trafic Engineering (TE):  In this document, "traffic engineering"
      refers to the current practice of inbound, inter-AS traffic
      engineering.  This is accomplished by placing more specific routes
      in the routing table and/ or increasing the frequency of routing
      updates in order to control inbound traffic at the boundary of an
      Autonomous system (AS).

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

3.  Background

   Within the DFZ, both the size of the RIB and 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, further study is needed to determine whether the mean
      per-prefix update rate is increasing as well [need reference].

   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.

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

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
   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).  Upgrading equipment
   earlier than planned is more easily justified (as an unplanned
   expense) when a new business opportunity is enabled as a result of an
   upgrade.  For example, an upgrade might be justified by an ability to
   support increased traffic or an increase in the number of customer
   connections, etc., where the upgrade can translate into increased
   revenue.  In contrast, it is more difficult to justify unplanned
   upgrades in the absence of corresponding customer benefit (and
   revenue) to cover the upgrade cost.  It is generally desired that
   deployed equipment remain usable over its planned lifetime.  An
   increase in the resources required to support larger or more dynamic
   routing tables is viewed as a sort of "unfunded mandate", in that
   customers do not expect to have to pay more just to continue
   retaining the same level of service as before, i.e., having all
   destinations be reachable as was the case in the past.  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

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

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

3.4.  Table Growth Targets

   A precise target for the rate of table size or routing update
   increase that should reasonably be supported going forward is
   difficult to state in quantitative terms.  One target might simply be
   to keep the growth at a stable, but manageable growth rate so that
   the increased router functionality can roughly be covered by
   improvements in technology (e.g., increased processor speeds,
   reductions in component costs, etc.).

   However, it is highly desirable to significantly bring down (or even
   reverse) the growth rate in order to meet user expectations for
   specific services.  As discussed below, there are numerous pressures
   to deaggregate routes.  These pressures come from users seeking
   specific, tangible service improvements that provide "business-
   critical" value.  Today, some of those services simply cannot be
   supported to the degree that future demand can be reasonably be
   expected because of the negative implications on DFZ table growth.
   Hence, valuable services are available to some, but not all potential
   customers.  As the need for such services becomes increasingly
   important, it will be difficult to deny such services to large
   numbers of users, especially when some "lucky" sites are able to use
   the service and others are not.

Narten                  Expires November 16, 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 16, 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?

5.5.  RIR IPv6 Policy is Not Balanced

Narten                  Expires November 16, 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 16, 2007              [Page 10]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

7.  Security Considerations

   None.

Narten                  Expires November 16, 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 16, 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 16, 2007              [Page 13]

Internet-Draft  Routing and Addressing Problem Statement        May 2007

Author's Address

   Thomas Narten (Editor)

Narten                  Expires November 16, 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 16, 2007              [Page 15]

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

---

From: Ross Callon <[email-masked]>
Date: Wed, 23 May 2007 21:17:33 -0400

This looks good to me (at least up to the end of section 3, I
didn't look as hard at sections 4 and beyond since they are
mostly not there).

One minor nit comment I have relates to the paragraph
right before section 3.4. A sentence in the middle of this
paragraph reads:

     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.

Well, actually the routers that are injecting the excessive prefixes into
the DFZ are quite likely themselves also in the DFZ. However, the ISP
doing this generally doesn't pay any cost since the extra prefix(es)
that they are advertising generally represent networks that they can
reach directly (most likely their customers), and thus they would have
had to carry the prefix(es) anyway in their network. I think that this is
quite a minor point, and the best that I was able to come up with was:

     A service provider that injects unnecessary prefixes into the DFZ
     does not generally pay the cost associated with injecting the
     extra prefixes, since such "extra" prefixes are generally addresses
     reachable via that service provider, to which it would need to
     maintain routes in any case. However, the cost is born by other
     routers in the DFZ on an Internet-wide (ie, worldwide) basis.

Thanks, Ross

---

From: Thomas Narten <[email-masked]>
Date: Thu, 24 May 2007 14:48:22 -0400

Hi Ross.

Thanks for the feedback.

> the DFZ are quite likely themselves also in the DFZ.

I think the point we want to make here is that the originator of the
prefix, i.e., the point where the prefix is generated, is exporting
some of the cost that by exporting the route into the DFZ. I agree it
will also bear the cost itself, but that is a given and not
significant.

> However, the ISP doing this generally doesn't pay any cost since the
> extra prefix(es) that they are advertising generally represent
> networks that they can reach directly (most likely their customers),
> and thus they would have had to carry the prefix(es) anyway in their
> network. I think that this is quite a minor point, and the best that
> I was able to come up with was:

>      A service provider that injects unnecessary prefixes into the
       DFZ

I have difficulty with "unnecessary" here. They are necessary to the
originator presumably. And "necessary" prefixes also are a burden.
       
>      routers in the DFZ on an Internet-wide (ie, worldwide) basis.

How about:

     Those that originate prefixes and inject them into the DFZ do not
     generally pay the full cost associated with the individual prefix
     -- the full cost is borne by all the routers in the DFZ.

Is that better?

Thomas

---

From: Tony Li <[email-masked]>
Date: Fri, 25 May 2007 16:04:38 -0700

Hi Thomas,

Great start, thank you.  I've got a number of comments, both  
substantive and editorial.  As others have done I'm only reviewing  
through section 3.

>    how ISPs operate as businesses?

This probably also should somehow capture that the growth rate is  
unconstrained, either architecturally or through regulatory dictum.   
Thus, the challenge is not only to cope with current growth rates,  
but to also cope with whatever arbitrary growth rate is presented in  
the future.  In the past, certain social pressures have helped to  
constrain the growth, but these pressures are no longer reliable in  
the face of increased competition.  The existence of traffic  
engineering more-specifics is evidence that those prior constraints  
no longer apply.

Yes, you touch on this in section 3.4, but it deserves significantly  
more attention.

>    properties of the routing and addressing system.

This will immediately be met with responses about how the IETF is not  
responsible for the business practices of ISPs.  Rightly so.

I think we also need to point out that the cost of the running the  
routing subsystem is dictated by the routing architecture of the  
Internet, which is under the I*.  Further, costs are part of each and  
every engineering decision, and that controlling the costs of running  
the routing subsystem (through architectural decisions) is part of  
our fundamental charter.  Thus, while the IETF is not concerned with  
business models or the profitability of the ISP community, for the  
IETF to continue with an architectural model with unbounded cost  
requirements represents an undue risk.

 >   natural balance between the cost and benefit of maintaining routing

I can only speculate how long it will be before some ISP sees this as  
an opportunity to inflict operational pain on its competitors and  
actively starts advertising prefixes without any technical benefit,  
solely for the sake of increasing the cost structures in the  
competitor's networks.  In this way,the current routing architecture  
creates an economic battlefield that heavily favors resource-rich  
incumbents.  Don't we also have the obligation to create a level  
playing field between ISPs?

>    new, with discussions dating back at least 10-15 years [GSE, ...].

Please include a reference to ROAD.  There isn't a single document  
that I know of that does it justice, but http://rms46.vlsm.org/ 
1/42.html is a good start.

>       reachable destinations, which number in the hundreds of the

How about:  ... which currently number ...

>       compact, optimized version of the RIB, containing only the

Perhaps 'subset'?  Something more to imply that a great deal of  
information in the RIB is not replicated in the FIB, not just backup  
paths...

>       information about backup paths.

Do we want to say something about FIB vs. RIB cost structures?  If  
only due to replication in distributed switching architectures, I  
think that it's safe to say that FIB memory is more precious than RIB  
memory.

>    power consumption or cooling demands.

I have a concern here about the presentation.  I understand the  
difficulty of giving a thoughtful, even presentation of a complex  
situation, but the current partitioning leads the reader to an  
improper conclusion far too quickly.  In fact, we all happily  
stipulate that adequate routers can (and will) be built.

Thus, the separation of two challenges here is something of a red- 
herring.  There is only one challenge: it combines both technical and  
economic aspects, to be sure, but the dominant one is the economic  
issue.  It is so dominant in fact, that the technical issues are  
largely irrelevant.  Cost is everything, and everything else is a  
distraction.

Regards,
Tony

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 28 May 2007 22:34:54 -0700

> helpful if you could review and respond quickly.

Hi Thomas, sorry for running late with comments here.

> particular we request review of.

For section 3, I do not have more to add on top of others comments.

> polished inventory of specific pressures.

I just have a general clarification question regarding the scope of  
the "problem" that this "problem statement" aims to describe:

   is the problem = routing scalability, or
   problem = major issues associated with routing and addressing
             that exist today?

(I may be the only one who's not clear here:)
The reason I ask: in the RAWS report,

    9.  Workshop Recommendations

    The workshop attendees would like to make the following
    recommendations:
    ......
    Second, because the participants of this workshop consisted of  
mostly
    large service providers and major router vendors, the workshop
    participants recommend that IAB/IESG organize additional  
workshops or
    use other venues of communication to reach out to other stakeholders
    such as content providers, retail providers, and enterprise
    operators, both to communicate to them the outcome of this workshop,
    and to solicit the routing/addressing problems they are facing  
today,
    and their requirements on the solution development.

I (maybe wrongly?) made a mental relation between the above workshop  
recommendation and this problem statement RADIR is working on...

Lixia

---

From: Thomas Narten <[email-masked]>
Date: Wed, 30 May 2007 10:10:57 -0400

Hi Tony.

Thanks much for the coments. Some specifics below.

> engineering more-specifics is evidence that those prior constraints  

We agree that this point is worth making more explicit.

How about we add the following text to the current paragraph:

   Finally, the scalability challenge is aggravated by the lack any
   limiting architectural upper-bound on the growth rate and a
   weakening of traditional social constraints on the growth rate that
   have helped restrain growth so far. Going forward, there is
   considerable uncertainty whether future growth rates will continue
   to be sufficiently constrained so that the routing load can be
   handled by routers available at that time.

> responsible for the business practices of ISPs.  Rightly so.

How about if I add the following paragraph to the above:

   While the IETF does not (and cannot) concern itself with business
   models or the profitability of the ISP community, the cost of
   running the routing subsystem as a whole is directly influenced by
   the routing architecture of the Internet, which clearly is the
   IETF's business.  Further, because cost implications are part of
   each and every engineering decision, controlling or limiting the
   overall cost of running the routing subsystem (through
   architectural decisions) is part of the IETF's fundamental charter.
   Consequently, having the IETF continue with an architectural model
   that places unbounded cost requirements on critical infrastructure
   represents an undue risk to the future of the Internet as a whole.

> playing field between ISPs?

Question. Is this a comment or are you suggesting a specific text
change? We don't necessarily disagree with this comment, but were
unsure of what to do with it.

> Editorial:

accepted.

> think that it's safe to say that FIB memory is more precious than RIB  

How about adding:

    The FIB is typically constructed from specialized hardware
    components, which have different (and higher) cost properties than
    the hardware typically used to maintain the FIB.

> largely irrelevant.  Cost is everything, and everything else is a  

I'm not sure I agree with this. I have difficulty saying there are not
technical issues, and it's all about economics. I don't think you can
ever split things up that cleanly.

But in any case, we were not sure what to do with this comment. It
possibly suggests a more fundamental restructuring of the
document. Can you expand a bit, especially in terms of what text
might be changed?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 30 May 2007 10:20:47 -0400

Hi Lixia.

>    problem = major issues associated with routing and addressing

Not sure I immediately see the difference here. I think it's both. But
fundamentally, I think that the second point manifests itself back
into "routing scalability", in terms of having a working routing
system in the DFZ.

We ended up agreeing that was the core problem, with many other
"problems" (like lack of good multihoming and a desire to avoid
renumbering) as being subproblems that manifest themselves back (in
terms of "pain") in the main problem.

>     and their requirements on the solution development.

We plan on soliciting input from the broader community, but are
hoping/expecting much of the feedback to map into "pressures to
deaggregate" and the like. If we get significantly different views on
the "problem", we will of course reevaluate.

As one example, some seem to think that it is a problem that mobility
solutions aren't "cleaner" and, e.g., don't use a ID/LOC split so that
multihoming/mobility leverage the same archtecture. But we've taken
the position that current mobility does not impact the routing system
at all, and is thus a non-problem. We have a general fear that if the
problem becomes too broad (e.g., "fix everything we don't like about
the current system"), it will be much more difficult to come up with a
solution that really impacts the pain point, namely the route
situation in the DFZ.

Thomas

---

From: Tony Li <[email-masked]>
Date: Wed, 30 May 2007 15:08:28 -0700

Thomas,

Thank you for your proposed changes.

>    Finally, the scalability challenge is aggravated by the lack any
                                                                         
                                        ^
                                                                         
                                        of

>    represents an undue risk to the future of the Internet as a whole.

Beautiful.

> unsure of what to do with it.

Given your change above, I don't think any further changes are  
necessary.

>     the hardware typically used to maintain the FIB.
                                                                         
                ^^^
                                                                         
                RIB

> document. Can you expand a bit, especially in terms of what text

I agree that you can't split it up cleanly into technical and  
economic challenges.  In fact, that's the point that I'm trying to  
make.  The current presentation appears to make the technical  
challenge the dominant issue, when in fact, it is the almost wholly  
trivial aspect of the entire situation.  The result is that the  
reader is going to treat the technical challenge as a trivial straw- 
man and discount it and possibly the rest of the document.  At the  
very least, could you move it after the economic discussion?

Thanks much,
Tony

---

From: Ross Callon <[email-masked]>
Date: Thu, 31 May 2007 23:02:40 -0400

I understand that section 6 has not been written out in detail,
and is likely to be updated / changed in the process of fully
fleshing it out. However, I do have some general concerns
about what is currently there, or perhaps more with what is
not there yet (ie, perhaps what is there is not complete).

Three issues with point 1:

One is that if we limit the size of the DFZ routing load by
exploding the size of a different routing table (perhaps by
putting very large tables on the edge), then this does not
necessarily help.

Another issue with point 1 is that I don't see us have having,
or even discussing, any method that actually puts a limit on
the overall routing table size, or that prevents an ISP from
advertising a very large number of prefixes. I suppose that if
this got too egregious, then perhaps other core ISPs would
get together and agree to dump the excessive routes (which
would mostly likely cause lots of excitement). This of course
relates to the point that Tony made:

>the future...

Even if we have a way to map all addresses to fully topological
addresses at the edge, we don't currently have any way to enforce
the implication that only topologically assigned and aggregatable
**and aggregated** addresses are actually advertised.

Also, I am not sure whether we want to "reduce the growth rate of
the DFZ routing load", or if we want to "ensure that the growth rate
of <some routing load, including DFZ> stays within technically and
economically manageable bounds".

Finally, I don't think that we are currently certain that it is
*possible* to do all that is in section 6, without causing other
unfortunate problems. I suppose that the "without causing other
unfortunate problems" and "only do it if it is actually possible"
might be implicit, but I am wondering if we want to at least say
something about this.

Thanks, Ross