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