-----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/