CURRENT_MEETING_REPORT_ Reported by Brian Carpenter/CERN and Tim Dixon/RARE with additional text from Phill Gross/ANS Minutes of the IPng Decision Process BOF (IPDECIDE) Summary and Results The IPng Decision Process BOF was intended to help re-focus attention on the very important topic of making a decision between the candidates for IPng. The BOF focused on the issues of who should take the lead in making the recommendation to the community and what criteria should be used to reach the recommendation. The discussion ranged widely, but some key points emerged: o Vendors and operators look to the IETF to reach a clear decision. o It would be bad to offer the market an ambiguous decision. o The market will resist any IPng that does not just look like a new release of IP. Co-existence, and ease and cost of transition, should be key decision criteria. o It is unclear how to prove that any proposal truly scales to a billion nodes. o Timescales for IPv4 address depletion and for IPng deployment are not well understood. o The IESG needs to figure out how to pursue the decision process and avoid wasted effort on competing proposals. Making a reasonable well-founded decision earlier was preferred over taking longer to decide and allowing major deployment of competing proposals. In the end, the BOF led very productively to a follow-up discussion in the Thursday afternoon open plenary. During the open plenary, a proposal that the IESG should take the lead responsibility for recommending an IPng choice to the IETF community met with strong consensus. This proposal included a series of steps that the IESG should take, with strong community involvment, toward a recommendation. We now give a more detailed review of the BOF discussion, in the interest of recording the wide range of opinions expressed. 1 Meeting Goals The purpose of the BOF was to focus on the decision process for IPng rather than on technical criteria, the proposals themselves, or on the working group process. Attendance About 200 people attended, plus about 100 MBONE auditors. Members of the audience represented the IETF's typical wide community of service providers, equipment vendors and engineers. The Need for a Decision The view was frequently expressed that a decision was needed. Vendors and operators looked to the IETF to reach a clear decision. The IPng issue had been widely publicized for some time and the expectation clearly was that it was the responsibility of the IETF to decide. Operators simply reacted to the demands of their customers: the IETF must set the technical standards. The IETF was doing a disservice to the community by appearing to be indecisive. The alternative of ``letting the market decide'' (whatever that may mean) was criticised on several grounds: o There are infrastructural issues, like DNS, which go hand-in-hand with the choice of a protocol and which cannot reasonably be expected to deal with 4 protocols. o There are already enough other choices (both proprietary and otherwise) in the marketplace. o The decision was too complicated for a rational market-led solution. The fact that the Internet is doubling in size about every 11 months means that the cost of transition to IPng (in terms of equipment and manpower) is also increasing. The longer it takes to reach a decision, the more costly the process of transition and the more difficult it is to undertake. There were some minority views expressed, including: o The decision will inevitably be controlled by the pricing policy of vendors. 2 o Router vendors are already supporting multiple network-layer protocols; in principle it would not be significantly more difficult to support several IPng solutions at the same time. Should there be a decision to recommend one proposal, or simply to eliminate some of the candidates? Concern was expressed about the feasibility of conducting reasonably-sized trials of more than one selected protocol and of the confusing signals this would send the market: IETF decisions now have an enormous potential economic impact on suppliers of equipment and services. It was also likely that uncertainty would lead to customers holding back on their purchases of networking equipment until the situation was clearer. A straw poll showed a clear majority view that there should be a decision for one solution. The Time Scale for a Decision The best guesstimates for the remaining lifetime of the IPv4 address space put the figure at around five to seven years, assuming CIDR is widely deployed. A margin of potential error in these figures is to be expected---one suggestion was that they could be out by a factor of four in either direction. However, the address space is only five doublings away from exhaustion. It was strongly recommended that more work be done on investigating the feasible remaining lifetime of IPv4. It is also difficult to estimate the time taken to implement, test and then deploy any chosen solution: it was not clear who was best placed to do this. The ordering of the decisions might also have a different priority for customers and vendors than for the IETF. For example, it might be necessary to have a decision about DNS changes early in order to deploy the infrastructure necessary to support IPng in advance of the availability of the IPng protocol itself. The IETF work was not proceeding in this order. The Evaluation Process Concern was expressed that the evaluation criteria which had so far been discussed were too general to support a defensible choice on the grounds of technical adequacy. The criteria had emerged in parallel with the protocol designs, and had so far not gelled enough to eliminate any candidate. There were also potential legal difficulties if the IETF appeared to be eliminating proposals on arbitrary grounds. It was stated frequently and forcibly that the transition costs should be a significant factor in the selection criteria. Concerns were expressed by several service providers that the developers had little 3 appreciation of the real-world networking complexities that transition would force people to cope with. If the cost of transition outweighed the pain of other solutions (application gateways or address translators) customers would not deploy IPng. It was suggested a couple of times that the working groups should be invited to evaluate each others' proposals in order to investigate their weaknesses, or that the proposals should be vetted by disinterested parties. It was suggested that the proposals were too similar for any reasonable choice to be made on the grounds of technical strength. However there was no consensus on these points. Although one of the goals of IPng had been to use the inevitable transition required by address exhaustion and routing problems to incorporate new features, there were a number of concerns about bundling too much additional complexity into an already difficult problem. It wasn't even clear that the technology yet existed to handle some of the new features that had been touted for IPng. IPng should appear simply like a new release of IPv4; although this would not necessarily bring new features, people would still transition through enlightened self-interest---to avoid disconnection from the global Internet in the future. There was no consensus about how to resolve this dilemma, since both smooth transition and multimedia support are musts. Various parties were identified as needing to assist in the evaluation process: o Operators, who need to understand deployment costs and scenarios. o Vendors, who understand the implementation consequences. The Decision Process There is an IETF process for making a decision on protocol standards: working groups can be given deadlines to submit papers to the IESG which then decides which to progress as standards. It was suggested that this process has only broken down in that the deadlines had not been applied. Other suggestions included: o Urging coalitions between the different working groups. o Forming an ``IPng'' working group either to make recommendations or to draw together the different proposals. o Asking the IESG or even the IAB to drive the decision process. On the basis of a straw poll, there was strong consensus that the decision should be made on technical grounds alone (subject to 4 reasonable costs of implementation, deployment and transition). It was repeatedly stated that an obvious requirement was that the proposed solution should work. There were at least two components to this: interoperability and scaling. This would be difficult to establish without large-scale piloting. There was no consensus on who might reasonably be expected to participate in such an exercise. The following day, at the Thursday open plenary session, a proposal that the IESG should take the responsibility of recommending an IPng choice to the IETF met with strong consensus. This proposal included a series of steps that the IESG should take to develop a progressive decision with community involvement. Attendees George Abe abe@infonet.com Chris Adie C.J.Adie@edinburgh.ac.uk Nick Alfano alfano@mpr.ca James Allard jallard@microsoft.com Bernt Allonen bal@tip.net Harald Alvestrand Harald.Alvestrand@uninett.no Frederik Andersen fha@dde.dk Per Andersson pa@cdg.chalmers.se Toshiya Asaba asaba@iij.ad.jp Josee Auber Josee_Auber@hpgnd.grenoble.hp.com Anders Baardsgaad anders@cc.uit.no Dennis Baker dbaker@wellfleet.com Jim Barnes barnes@xylogics.com Tony Bates tony@ripe.net Nutan Behki Nutan_Behki@qmail.newbridge.com Axel Belinfante Axel.Belinfante@cs.utwente.nl Vincent Berkhout berkhout@cs.utwente.nl Per Bilse bilse@ic.dk Jim Binkley jrb@ibeam.intel.com Robert Blokzijl K13@nikhef.nl Rebecca Bostwick bostwick@es.net Jim Bound bound@zk3.dec.com Robert Braden braden@isi.edu Stefan Braun smb@cs.tu-berlin.de Thomas Brisco brisco@pilot.njin.net Ronald Broersma ron@nosc.mil J. Nevil Brownlee nevil@ccu1.aukuni.ac.nz Steve Buchko stevebu@newbridge.com Ross Callon rcallon@wellfleet.com Peter Cameron cameron@xylint.co.uk C. Allan Cargille allan.cargille@cs.wisc.edu Brian Carpenter brian@dxcern.cern.ch Vinton Cerf vcerf@cnri.reston.va.us George Chang gkc@ctt.bellcore.com A. Lyman Chapin lyman@bbn.com Chris Chiotasso chris@andr.ub.com 5 Henry Clark henryc@oar.net Richard Colella colella@nist.gov David Conrad davidc@iij.ad.jp Al Costanzo al@akc.com Stephen Crocker crocker@tis.com Dave Cullerot cullerot@ctron.com Geert Jan de Groot geertj@ica.philips.nl Stephen Deering deering@parc.xerox.com Steve DeJarnett steve@ibmpa.awdpa.ibm.com Kurt Dobbins dobbins@ctron.com Jeffrey Dunn dunn@neptune.nrl.navy.mil Francis Dupont francis.dupont@inria.fr Toerless Eckert Toerless.Eckert@informatik.uni-erlangen.de Kjeld Borch Egevang kbe@craycom.dk Ed Ellesson ellesson@vnet.ibm.com Robert Enger enger@reston.ans.net Hans Eriksson hans@sics.se Deborah Estrin estrin@usc.edu Dino Farinacci dino@cisco.com Stefan Fassbender stf@easi.net Eric Fleischman ericf@act.boeing.com Peter Ford peter@goshawk.lanl.gov Osten Franberg euaokf@eua.ericsson.se Paul Francis Francis@thumper.bellcore.com Dan Frommer dan@jeremy.enet.dec.com Shoji Fukutomi fuku@furukawa.co.jp Vince Fuller vaf@stanford.edu Peter Furniss p.furniss@ulcc.ac.uk Eugene Geer ewg@cc.bellcore.com Robert Gilligan Bob.Gilligan@Eng.Sun.Com Joseph Godsil jgodsil@ncsa.uiuc.edu Tim Goodwin tim@pipex.net Ramesh Govindan rxg@thumper.bellcore.com Marcel Graf graf%dhdibm1.bitnet@vm.gmd.de Terry Gray gray@cac.washington.edu Ron Greve rgreve@cs.utwente.nl Phillip Gross pgross@ans.net Chris Gunner gunner@dsmail.lkg.dec.com Joel Halpern jmh@network.com Susan Hares skh@merit.edu Denise Heagerty denise@dxcoms.cern.ch Marco Hernandez marco@mh-slip.cren.edu Robert Hinden hinden@eng.sun.com Frank Hoffmann hoffmann@dhdibm1.bitnet John Hopkins J_Hopkins@icrf.icnet.uk Marc Horowitz marc@mit.edu Chris Howard chris_howard@inmarsat.org Christian Huitema Christian.Huitema@sophia.inria.fr Erik Huizer Erik.Huizer@SURFnet.nl Geoff Huston g.huston@aarnet.edu.au Phil Irey pirey@relay.nswc.navy.mil Ole Jacobsen ole@interop.com David Jacobson dnjake@vnet.ibm.com Ronald Jacoby rj@sgi.com 6 Ola Johansson ojn@tip.net David Johnson dbj@cs.cmu.edu Laurent Joncheray lpj@merit.edu Philip Jones p.jones@jnt.ac.uk Cyndi Jung cmj@3com.com Thomas Kaeppner kaeppner%heidelbg.vnet@ibmpa.ibm.com Tomaz Kalin kalin@rare.nl Scott Kaplan scott@wco.ftp.com Anders Karlsson sak@cdg.chalmers.se Daniel Karrenberg daniel@ripe.net Frank Kastenholz kasten@ftp.com Peter Kaufmann kaufmann@dfn.dbp.de Sean Kennedy liam@nic.near.net Stephen Kent kent@bbn.com Zbigniew Kielczewski zbig@eicon.qc.ca John Klensin Klensin@infoods.unu.edu Mark Knopper mak@merit.edu Peter Koch pk@techfak.uni-bielefeld.de Rajeev Kochhar rajeev_kochhar@3com.com Ton Koelman koelman@stc.nato.int Mark Kosters markk@internic.net Glenn Kowack Glenn@eu.net John Krawczyk jkrawczy@wellfleet.com Arnold Krechel krechel@gmd.de John Larson jlarson@parc.xerox.com Eliot Lear lear@sgi.com Jose Legatheaux Martins jalm@fct.unl.pt Tony Li tli@cisco.com Susan Lin suelin@vnet.ibm.com John Lindsay lindsay@kingston.ac.uk Robin Littlefield robin@wellfleet.com Anne Lord anne@ripe.net Peter Lothberg roll@stupi.se Paul Lustgarten Paul.Lustgarten@att.com Paolo Malara malara@crs4.it Allison Mankin mankin@cmf.nrl.navy.mil Bill Manning bmanning@rice.edu David Marlow dmarlow@relay.nswc.navy.mil Cynthia Martin martin@spica.disa.mil Ignacio Martinez martinez@rediris.es Jun Matsukata jm@eng.isas.ac.jp Keith McCloghrie kzm@hls.com Peter Merdian merdian@rus.uni-stuttgart.de Greg Minshall minshall@wc.novell.com Keith Mitchell keith@pipex.net Pushpendra Mohta pushp@cerf.net Keith Moore moore@cs.utk.edu Kees Neggers neggers@surfnet.nl Peder Chr. Noergaard pcn@tbit.dk Erik Nordmark nordmark@eng.sun.com David O'Leary doleary@cisco.com Masataka Ohta mohta@cc.titech.ac.jp Jorg Ott jo@cs.tu-berlin.de Christian Panigl christian.panigl@cc.univie.ac.at 7 Andrew Partan asp@uunet.uu.net Michael Patton map@bbn.com Geir Pedersen Geir.Pedersen@usit.uio.no Charles Perkins perk@watson.ibm.com Drew Perkins ddp@fore.com David Piscitello dave@mail.bellcore.com Mel Pleasant pleasant@hardees.rutgers.edu Willi Porten porten@gmd.de Mark Prior mrp@itd.adelaide.edu.au Juergen Rauschenbach jrau@dfn.de Alex Reijnierse a.a.reijnierse@research.ptt.nl Victor Reijs reijs@surfnet.nl Robert Reschly reschly@brl.mil Georg Richter richter@uni-muenster.de Dan Romascanu dan@lannet.com Luc Rooijakkers lwj@cs.kun.nl Marjo Rottschaefer Hal Sandick sandick@vnet.ibm.com Miguel Sanz miguel.sanz@rediris.es Jon Saperia saperia@tay.dec.com Eve Schooler schooler@isi.edu John Scudder jgs@merit.edu Tim Seaver tas@concert.net Kitty Shih kmshih@novell.com William Simpson Bill.Simpson@um.cc.umich.edu W. David Sincoskie sincos@thumper.bellcore.com Simon Spero simon_spero@unc.edu Vladimir Sukonnik sukonnik@process.com Fumio Teraoka tera@csl.sony.co.jp Marten Terpstra marten@ripe.net Kamlesh Tewani ktt@arch2.att.com Richard Thomas rjthomas@bnr.ca Susan Thomson set@bellcore.com Martin Toet toet@cs.utwente.nl Antoine Trannoy trannoy@crs4.it Robert Ullmann ariel@world.std.com Willem van der Scheun scheun@sara.nl Guido van Rossum guido@cwi.nl Werner Vogels werner@inesc.pt Ruediger Volk rv@informatik.uni-dortmund.de Steven Waldbusser waldbusser@andrew.cmu.edu Sandro Wallach sandro@elf.com Abel Weinrib abel@bellcore.com Douglas Williams dougw@ralvmg.vnet.ibm.com Kirk Williams kirk@sbctri.sbc.com Steven Willis steve@wellfleet.com Sam Wilson sam.wilson@ed.ac.uk Wilfried Woeber Wilfried.Woeber@CC.UniVie.ac.at Jessica Yu jyy@merit.edu Paul Zawada Zawada@ncsa.uiuc.edu 8