
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just as an FYI, I think this is something Ops folks should be
very interested in, and even actively participating in the
discussion(s).

- - ferg

[snip]

To: IETF Announcement list <ietf-announce@ietf.org>
From: Leslie Daigle <leslie@thinkingcat.com>
Date: Wed, 20 Dec 2006 20:58:05 -0500
Cc: iab@ietf.org, iesg@ietf.org, ram@iab.org


The recent IAB workshop (see draft-iab-raws-report-00) established that a
significant fraction of the Internet operations community and
their equipment vendors believe that we face a scaling problem for
routing in the core of the Internet, on a worrying timescale.
They further believe that timely action is needed.

Enough evidence was available to the workshop to convince the IAB
and IESG members present that the problem is real, even if the timescale
and details are debatable, and that the solution will lie in certain
specific areas mentioned below. It is also evident that the Internet
community has everything to gain if efforts in the IETF and IRTF are
closely coordinated with those in the operations and vendor communities,
and much to lose otherwise.  While these problems are pressing, we
believe there is time for a coordinated approach.

Therefore, the IAB & IESG have worked together to identify key paths for
progress in discussing and resolving this problem, and have agreed
to establish an advisory group for coordinating information flow and
awareness of activities (more on this group, below).

We note that although this topic is of primary concern to backbone
network operators and their equipment makers, many other parts of the
community have an interest. These include other ISPs, enterprise network
operators, mobile operators, server and host software makers, and
standards development organizations other than the IETF.


KEY PATHS FOR PROGRESS

Regarding possible solutions, the current understanding of the cause
of the scaling problem is that it is driven not by growth of the
size of the Internet as such, but by growth in the demand for routing
of individual address prefixes that cannot be aggregated into coarser
routes. This implies that the solution will lie in the direction of
separating the usage of address prefixes to identify sites from their
usage for wide-area routing. There is a variety of ways that such
a separation could be achieved.

Following various discussions at IETF67, we set out below the main
lines of action that we propose, followed by a suggested arrangement to
drive these actions forward in parallel.

(1) Complete the problem statement, addressing the issues
raised in the IAB workshop and others as applicable.

(2) Determine applicable objective metrics and identify applicable
trend analyses for them.

(3) Document the underlying causes of perceived scaling problems.

(4) Review proposed solution directions in terms of
expected impact in addressing scaling issues as well as
architectural soundness.

(5) Encourage and nurture short term solution proposals, prototypes
and appropriate standards activity.

(6) Encourage and nurture relevant research activities directed towards
long term solutions.



INTEGRATION WITH EXISTING IETF FUNCTIONS

The IAB and IESG intend to take their full part in these actions,
but specifically as part of a broad community effort. The IAB would
expect to focus on actions to promote (1), (2), (3) and (4), and
expects the IRTF to work with other research entities on (6). The IAB
in particular publishes informational documents, convenes workshops, and
supports IRTF work as necessary and possible. The IESG will play its
normal role in chartering BoFs and WGs and reviewing WG and individual
submission (IETF stream) documents as appropriate and in particular for
(5).

To be as inclusive as possible, while sustaining the effort over a
number of years, the IAB and IESG propose a tiered approach to
project coordination:

(A) We assume that detailed work will be carried out by ad hoc
or chartered teams, and there is no grand plan for structuring
these teams. As always in the development of the Internet,
we expect analysis and solutions to come from the community
at large.

(B) IAB workshops, BOFs, IETF WGs and IRTF RGs can be organized
in the normal way, as issues and proposals arise in the
community.

(C) General discussion is already proceeding on the ram@iab.org list.
More specialized lists can be created as needed.


COORDINATION

The IETF and IAB Chairs will appoint a Directorate, including
roughly ten people with different experience and expertise,
to stay abreast of activities, provide coordinated updates,
as well as input to the IESG and IAB about progress against
the noted actions above.

We use the name "Directorate" simply because it is a recognized
term in the IETF; we expect it to focus on communication and
coordination. It will not be charged with picking solutions or
choosing a technical direction. That will be a community decision.
This Directorate is expected to have a lifetime of about 5 years
(with an annual review of membership).

The Directorate will be organized and reviewed periodically
to ensure it is running smoothly and reporting on overall progress.

Specific objectives of the Directorate will be:

(i) On a continuing basis, survey existing efforts on the lines of
action listed above, and facilitate discussion of effectiveness and
timeliness of proposals and problem statements, etc.

(ii) Report to the IAB, IESG and the community regularly (at
least once per IETF meeting) about those efforts, and highlight
specific gaps or concerns about progress.

(iii) Provide feedback to IESG, IAB and IRSG on any relevant
proposed activities in the area (e.g., WG or RG charters,
BOF or workshop proposals, etc).

The Directorate will be charged with encouraging
appropriate communication with all the identified constituencies. 



Leslie & Brian, 
for the IAB & IESG.

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram

[snip]

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.5.2 (Build 4075)

wj8DBQFFifY9q1pz9mNUZTMRAgAsAJ46FAuVI04u261DetElSc88I9raEACgpFgi
ZM4zPZBtHCsVNBT21fDY2fA=
=TdlZ
-----END PGP SIGNATURE-----


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/


