From mccreary at pch.net  Wed Aug  8 13:56:21 2001
From: mccreary at pch.net (mccreary at pch.net)
Date: Wed, 08 Aug 2001 07:56:21 -0600
Subject: possible charter 
In-Reply-To: Your message of "Tue, 24 Jul 2001 14:35:58 EDT."
             <Pine.SOL.4.33.0107241435240.19063-100000@stargate.gpcc.itd.umich.edu> 
Message-ID: <200108081356.f78DuLJ13257@xoanon.mcwest.org>

I have a couple additional references for the charter.  The first is Dave
Meyer's information page for the Route Views project at
http://www.antc.uoregon.edu/route-views/, and his archive of BGP table
snapshots at http://128.223.162.74/oix-route-views/.  The second is PCH's
routing table size graph at http://www.pch.net/routing/BGP_table_size.html,
and the MOAT and PCH data archives at http://moat.nlanr.net/AS and
http://www.pch.net/documents/data/routing-tables/route-views.oregon-ix.net/.
The MOAT data extends back to November of 1997, so it is a good source for
investigating longer-term trends.  The MOAT data is also mirrored on the PCH
web server at 
http://www.pch.net/documents/data/routing-tables/route-views.oregon-ix.net/moat/
--
Sean McCreary                                                 mccreary at pch.net


From ahuja at umich.edu  Wed Aug  8 15:56:41 2001
From: ahuja at umich.edu (abha ahuja)
Date: Wed, 8 Aug 2001 11:56:41 -0400 (EDT)
Subject: Revised Agenda 
Message-ID: <Pine.SOL.4.33.0108081151540.1639-100000@pacman.gpcc.itd.umich.edu>


Revised Agenda for tomorrow's meeting....


-Intro and Agenda Bashing (5 min)
-Analysis of RIPE RIS BGP Data - Cengiz Alaettinoglu (30 min)
-Measuring Routing Table Growth - Randy Bush (20 min)
-draft-berkowitz-tblgrow-00.txt (15 mins) - Howard C. Berkowitz
-NOPEER scope (15 min) - Geoff Huston
-Review of potential charter (15 min)


=abha ;)

++++++++++++++++++
abha ahuja
<ahuja at umich.edu>





From randy at research.att.com  Thu Aug  9 12:53:08 2001
From: randy at research.att.com (Randy Bush)
Date: Thu, 09 Aug 2001 13:53:08 +0100
Subject: foils and paper
Message-ID: <E15UpJE-000228-00@roam.psg.com>

the book  : http://www.research.att.com/~jrex/papers/filter.(pdf|ps)
the movie : http://psg.com/~randy/010809.ptomaine.pdf

randy


From cengiz at packetdesign.com  Thu Aug  9 15:48:50 2001
From: cengiz at packetdesign.com (Cengiz Alaettinoglu)
Date: 09 Aug 2001 08:48:50 -0700
Subject: more foils
In-Reply-To: <E15UpJE-000228-00@roam.psg.com>
References: <E15UpJE-000228-00@roam.psg.com>
Message-ID: <997372130.14608.46.camel@elf.packetdesign.com>

My slides will be available at
http://www.packetdesign.com/publications.html
probably sometime next week.

Cengiz

On 09 Aug 2001 13:53:08 +0100, Randy Bush wrote:
> the book  : http://www.research.att.com/~jrex/papers/filter.(pdf|ps)
> the movie : http://psg.com/~randy/010809.ptomaine.pdf
> 
> randy
> 




From gih at telstra.net  Sun Aug 12 01:48:31 2001
From: gih at telstra.net (Geoff Huston)
Date: Sun, 12 Aug 2001 11:48:31 +1000
Subject: NOPEER community proposal fromthe PTOMAINE BOF
In-Reply-To: <E15UpJE-000228-00@roam.psg.com>
Message-ID: <4.3.2.7.2.20010812114412.00b78630@localhost>

The presentation: www.telstra.net/gih/nopeer.pdf

The text: www.telstra.net/gih/nopeer.txt

The text has been submitted as draft-huston-nopeer-00.txt to the drafts 
editor as an interim step. I understand that the BOF hummed in accordance 
with the proposal that if PTOMAINE is chartered as a Working Group, then 
the WG would take on this document as a WG document.

thanks,

   Geoff





From ahuja at umich.edu  Mon Aug 13 18:13:16 2001
From: ahuja at umich.edu (abha ahuja)
Date: Mon, 13 Aug 2001 14:13:16 -0400 (EDT)
Subject: Latest Version 
Message-ID: <Pine.SOL.4.33.0108131410220.13124-100000@frogger.gpcc.itd.umich.edu>


Here is the most recent version of the charter.  This is what we'll be
sending to the IESG for WG approval unless someone has any major
objections...

-abha ;)

===========================================================================

Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine)

Chair(s):
Abha Ahuja <ahuja at wibh.net>

Operations Area Director(s):

Randy Bush <randy at psg.com>
Bert Wijnen <bwijnen at lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy at psg.com>

Mailing Lists:

General Discussion: ptomaine at shrubbery.net
To Subscribe: majordomo at shrubbery.net
In Body: subscribe ptomaine
Archive: http://www.shrubbery.net/ptomaine


DESCRIPTION:

Routing table growth has been an issue of much concern.  Many have talked
about temporary methods to alleviate the drain on Internet resources.  In the
vein of these discussions, we started to consider aggregation and filtering
techniques to reduce the amount of routing information carried by routers with
global knowledge.

The purpose of the Prefix Taxonomy Ongoing Measurement & Inter Network
Experiment WG is to consider and measure the problem of routing table
growth and possible interim methods for reducing the impact of routing
table resource consumption within a network and the global Internet.  The
first step of the WG is to define the impacts on routing resource
consumption and to identify the problems facing routing scalability.

We believe the next step is to develop suggestions for filtering and
aggregating prefixes to reduce an individual networks routing table size
and route processing load and possible knobs with the least loss of
reachability if such methods are determined to be feasible in addressing
the problem.  This work may possibly define a framework for larger efforts
to address the problems facing interdomain routing scalability.

GOALS:

1) To provide a clear definition of the problems facing Internet
   Routing Scaling today.  This includes routing table size and route
   processing load.
2) To provide a taxonomy to describe prefix information for peer review.
3) To collate measurements of routing table scaling data and publish a
   reference list.
4) To discuss and document methods of filtering/aggregating prefix
   information and to discuss and document what support from protocols or
   vendor knobs that might be helpful in doing this.  In addition, to
   suggest policy guidelines to RIRs, LIRs and/or ISPs for
   allocations,etc. that may be useful.
5) To determine the long and short term effects of filtering/aggregating
   prefixes to reduce router resource consumption.
6) To develop methods of controlling policy information propagation in
   order to limit the need for propagation of prefix sub-aggregates.

MILESTONES:

Nov 01 - Submit Taxonomy Draft
Dec 01 - Submit Problem Statement Draft
Jan 02 - Submit References Draft
Feb 02 - Submit Policy Propagation Draft

Some Relevant References:

http://www.antc.uoregon.edu/route-views/
http://www.pch.net/routing/BGP_table_size.html
http://moat.nlanr.net/AS
http://www.pch.net/documents/data/routing-tables/route-views.oregon-ix.net/
http://www.employees.org/~tbates/cidr-report.html
http://www.telstra.net/ops/bgp/index.html
http://www.apnic.net/stats/bgp
http://www.merit.edu/ipma



From jnc at ginger.lcs.mit.edu  Mon Aug 13 18:33:42 2001
From: jnc at ginger.lcs.mit.edu (J. Noel Chiappa)
Date: Mon, 13 Aug 2001 14:33:42 -0400
Subject: Latest Version
Message-ID: <200108131833.OAA15321@ginger.lcs.mit.edu>

    > From: abha ahuja <ahuja at umich.edu>

    > Here is the most recent version of the charter.

    > to consider and measure the problem of routing table growth and 
    > possible interim methods for reducing the impact of routing table
    > resource consumption ... The first step of the WG is to define the
    > impacts on routing resource consumption

In the long run, the problem with large tables is not resource consumption so
much as increased stabilization time (with respect to any particular
destination, of course - the table as a whole is changing all the time in a
network this big).

Bandwidth is already not a problem, and CPU power and memory is getting
cheaper all the time, which might lead some people "out there" to think that
we can grow our way out of the problem with faster/bigger hardware. "Time" is
not traditionally thought of as a resource... :-)


    > 4) To discuss and document methods of filtering/aggregating prefix
    > information and to discuss and document what support from protocols or
    > vendor knobs that might be helpful in doing this. 
    > In addition, to suggest policy guidelines to RIRs, LIRs and/or ISPs for
    > allocations, etc. that may be useful.

I would have said "allocations and aggregations", since it's the latter that
is the only solution.

(And it might be worth discussing that, and getting general agreement to that
point, and making a point of stating that better aggregation is the *only*
technique known for making routing scale.)

	Noel


From randy at psg.com  Mon Aug 13 18:36:06 2001
From: randy at psg.com (Randy Bush)
Date: Mon, 13 Aug 2001 11:36:06 -0700
Subject: Latest Version
References: <200108131833.OAA15321@ginger.lcs.mit.edu>
Message-ID: <E15WMZK-000B81-00@rip.psg.com>

> making a point of stating that better aggregation is the *only* technique
> known for making routing scale.

and do you see any path(s) for doing this in the *current* routing system,
which is the range of the ptomaine effort?

randy


From ahuja at umich.edu  Mon Aug 13 18:36:29 2001
From: ahuja at umich.edu (abha ahuja)
Date: Mon, 13 Aug 2001 14:36:29 -0400 (EDT)
Subject: Latest Version
In-Reply-To: <200108131833.OAA15321@ginger.lcs.mit.edu>
Message-ID: <Pine.SOL.4.33.0108131434340.13124-100000@frogger.gpcc.itd.umich.edu>


Hi Noel!

>     > to consider and measure the problem of routing table growth and
>     > possible interim methods for reducing the impact of routing table
>     > resource consumption ... The first step of the WG is to define the
>     > impacts on routing resource consumption
>
> In the long run, the problem with large tables is not resource consumption so
> much as increased stabilization time (with respect to any particular
> destination, of course - the table as a whole is changing all the time in a
> network this big).

Totally agree!  Unfortunately, there seems to be a lot of misconception
about what the problem really is, thus the first goal of this WG is to
define it for all to see....

Filtering/better aggregation has the benefit that it reduces the scope of
"detailed" info propagation to help improve the stabilization time of the
system as a whole.

> Bandwidth is already not a problem, and CPU power and memory is getting
> cheaper all the time, which might lead some people "out there" to think that
> we can grow our way out of the problem with faster/bigger hardware. "Time" is
> not traditionally thought of as a resource... :-)

:)

>
>     > 4) To discuss and document methods of filtering/aggregating prefix
>     > information and to discuss and document what support from protocols or
>     > vendor knobs that might be helpful in doing this.
>     > In addition, to suggest policy guidelines to RIRs, LIRs and/or ISPs for
>     > allocations, etc. that may be useful.
>
> I would have said "allocations and aggregations", since it's the latter that
> is the only solution.

Will fix.

> (And it might be worth discussing that, and getting general agreement to that
> point, and making a point of stating that better aggregation is the *only*
> technique known for making routing scale.)

*grin*

Thanks, Noel!

-abha ;)




From Eduard.Metz at kpnqwest.com  Wed Aug 15 12:43:13 2001
From: Eduard.Metz at kpnqwest.com (Metz, Eduard)
Date: Wed, 15 Aug 2001 14:43:13 +0200
Subject: Latest Version 
Message-ID: <1E810ACBCC29D51185DF00508B66CCEE04B6DC@ntexghfd02>


I agree that the handling the "size" of things in terms of resources and
convergence etc is becoming (or is) more and more a problem. Since size is a
problem, reducing size could be a solution, or at least reduce the problem
as such. Currently, the description seems very focussed on this. I wonder
whether there should not be more room left open for different solutions,
that e.g. handle "size" differently, or converge in another way, etc.
Reducing size is a solution, but probably not the only one. Also given that
routing tables keep growing, we may end up at the same or bigger size anyway
... (even when reducing them now). 

cheers,
	Eduard

ps.1 How does this group relate to the "future domain routing" initiative on
the routing-research list (if at all)?
ps.2 Minor comment: First section, "Internet resources" should probably be
something like "router resources".



> 
> DESCRIPTION:
> 
> Routing table growth has been an issue of much concern.  Many 
> have talked
> about temporary methods to alleviate the drain on Internet 
> resources.  In the
> vein of these discussions, we started to consider aggregation 
> and filtering
> techniques to reduce the amount of routing information 
> carried by routers with
> global knowledge.
> 
> The purpose of the Prefix Taxonomy Ongoing Measurement & Inter Network
> Experiment WG is to consider and measure the problem of routing table
> growth and possible interim methods for reducing the impact of routing
> table resource consumption within a network and the global 
> Internet.  The
> first step of the WG is to define the impacts on routing resource
> consumption and to identify the problems facing routing scalability.
> 
> We believe the next step is to develop suggestions for filtering and
> aggregating prefixes to reduce an individual networks routing 
> table size
> and route processing load and possible knobs with the least loss of
> reachability if such methods are determined to be feasible in 
> addressing
> the problem.  This work may possibly define a framework for 
> larger efforts
> to address the problems facing interdomain routing scalability.
> 
> GOALS:
> 
> 1) To provide a clear definition of the problems facing Internet
>    Routing Scaling today.  This includes routing table size and route
>    processing load.
> 2) To provide a taxonomy to describe prefix information for 
> peer review.
> 3) To collate measurements of routing table scaling data and publish a
>    reference list.
> 4) To discuss and document methods of filtering/aggregating prefix
>    information and to discuss and document what support from 
> protocols or
>    vendor knobs that might be helpful in doing this.  In addition, to
>    suggest policy guidelines to RIRs, LIRs and/or ISPs for
>    allocations,etc. that may be useful.
> 5) To determine the long and short term effects of 
> filtering/aggregating
>    prefixes to reduce router resource consumption.
> 6) To develop methods of controlling policy information propagation in
>    order to limit the need for propagation of prefix sub-aggregates.
> 
> MILESTONES:
> 
> Nov 01 - Submit Taxonomy Draft
> Dec 01 - Submit Problem Statement Draft
> Jan 02 - Submit References Draft
> Feb 02 - Submit Policy Propagation Draft
> 
> Some Relevant References:
> 
> http://www.antc.uoregon.edu/route-views/
> http://www.pch.net/routing/BGP_table_size.html
> http://moat.nlanr.net/AS
> http://www.pch.net/documents/data/routing-tables/route-views.o
regon-ix.net/
http://www.employees.org/~tbates/cidr-report.html
http://www.telstra.net/ops/bgp/index.html
http://www.apnic.net/stats/bgp
http://www.merit.edu/ipma


From gan at hammar.net  Fri Aug 17 18:16:23 2001
From: gan at hammar.net (Megan Hammar)
Date: Fri, 17 Aug 2001 14:16:23 -0400
Subject: Latest Version
In-Reply-To: <1E810ACBCC29D51185DF00508B66CCEE04B6DC@ntexghfd02>; from Eduard.Metz@kpnqwest.com on Wed, Aug 15, 2001 at 02:43:13PM +0200
References: <1E810ACBCC29D51185DF00508B66CCEE04B6DC@ntexghfd02>
Message-ID: <20010817141623.B15198@hammar.net>

> 
> I agree that the handling the "size" of things in terms of resources and
> convergence etc is becoming (or is) more and more a problem. Since size is a
> problem, reducing size could be a solution, or at least reduce the problem
> as such. Currently, the description seems very focussed on this. I wonder
> whether there should not be more room left open for different solutions,
> that e.g. handle "size" differently, or converge in another way, etc.
> Reducing size is a solution, but probably not the only one. Also given that
> routing tables keep growing, we may end up at the same or bigger size anyway
> ... (even when reducing them now). 
> cheers,
> 	Eduard

yes but the other options are more long term solutions which is not really the focus of ptomaine 
as I understand it.  The idea is to get us as far as we can on what we have until the something better
other groups are working on can be implemented...ie up to 5 years.

-Megan