home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
93jul
/
ipdecide-minutes-93jul.txt
< prev
next >
Wrap
Text File
|
1993-09-21
|
18KB
|
472 lines
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