home *** CD-ROM | disk | FTP | other *** search
-
- 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
-