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 >
Text File  |  1993-09-21  |  18KB  |  472 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Brian Carpenter/CERN and Tim Dixon/RARE with additional text
  6. from Phill Gross/ANS
  7.  
  8. Minutes of the IPng Decision Process BOF (IPDECIDE)
  9.  
  10.  
  11.  
  12. Summary and Results
  13.  
  14.  
  15. The IPng Decision Process BOF was intended to help re-focus attention on
  16. the very important topic of making a decision between the candidates for
  17. IPng.  The BOF focused on the issues of who should take the lead in
  18. making the recommendation to the community and what criteria should be
  19. used to reach the recommendation.  The discussion ranged widely, but
  20. some key points emerged:
  21.  
  22.  
  23.    o Vendors and operators look to the IETF to reach a clear decision.
  24.  
  25.    o It would be bad to offer the market an ambiguous decision.
  26.  
  27.    o The market will resist any IPng that does not just look like a new
  28.      release of IP. Co-existence, and ease and cost of transition,
  29.      should be key decision criteria.
  30.  
  31.    o It is unclear how to prove that any proposal truly scales to a
  32.      billion nodes.
  33.  
  34.    o Timescales for IPv4 address depletion and for IPng deployment are
  35.      not well understood.
  36.  
  37.    o The IESG needs to figure out how to pursue the decision process and
  38.      avoid wasted effort on competing proposals.  Making a reasonable
  39.      well-founded decision earlier was preferred over taking longer to
  40.      decide and allowing major deployment of competing proposals.
  41.  
  42.  
  43. In the end, the BOF led very productively to a follow-up discussion in
  44. the Thursday afternoon open plenary.  During the open plenary, a
  45. proposal that the IESG should take the lead responsibility for
  46. recommending an IPng choice to the IETF community met with strong
  47. consensus.  This proposal included a series of steps that the IESG
  48. should take, with strong community involvment, toward a recommendation.
  49.  
  50. We now give a more detailed review of the BOF discussion, in the
  51. interest of recording the wide range of opinions expressed.
  52.  
  53.                                    1
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Meeting Goals
  60.  
  61. The purpose of the BOF was to focus on the decision process for IPng
  62. rather than on technical criteria, the proposals themselves, or on the
  63. working group process.
  64.  
  65.  
  66. Attendance
  67.  
  68. About 200 people attended, plus about 100 MBONE auditors.  Members of
  69. the audience represented the IETF's typical wide community of service
  70. providers, equipment vendors and engineers.
  71.  
  72.  
  73. The Need for a Decision
  74.  
  75. The view was frequently expressed that a decision was needed.  Vendors
  76. and operators looked to the IETF to reach a clear decision.  The IPng
  77. issue had been widely publicized for some time and the expectation
  78. clearly was that it was the responsibility of the IETF to decide.
  79. Operators simply reacted to the demands of their customers:  the IETF
  80. must set the technical standards.  The IETF was doing a disservice to
  81. the community by appearing to be indecisive.
  82.  
  83. The alternative of ``letting the market decide'' (whatever that may
  84. mean) was criticised on several grounds:
  85.  
  86.  
  87.    o There are infrastructural issues, like DNS, which go hand-in-hand
  88.      with the choice of a protocol and which cannot reasonably be
  89.      expected to deal with 4 protocols.
  90.  
  91.    o There are already enough other choices (both proprietary and
  92.      otherwise) in the marketplace.
  93.  
  94.    o The decision was too complicated for a rational market-led
  95.      solution.
  96.  
  97.  
  98. The fact that the Internet is doubling in size about every 11 months
  99. means that the cost of transition to IPng (in terms of equipment and
  100. manpower) is also increasing.  The longer it takes to reach a decision,
  101. the more costly the process of transition and the more difficult it is
  102. to undertake.
  103.  
  104. There were some minority views expressed, including:
  105.  
  106.  
  107.    o The decision will inevitably be controlled by the pricing policy of
  108.      vendors.
  109.  
  110.  
  111.                                    2
  112.  
  113.  
  114.  
  115.  
  116.  
  117.    o Router vendors are already supporting multiple network-layer
  118.      protocols; in principle it would not be significantly more
  119.      difficult to support several IPng solutions at the same time.
  120.  
  121.  
  122. Should there be a decision to recommend one proposal, or simply to
  123. eliminate some of the candidates?  Concern was expressed about the
  124. feasibility of conducting reasonably-sized trials of more than one
  125. selected protocol and of the confusing signals this would send the
  126. market:  IETF decisions now have an enormous potential economic impact
  127. on suppliers of equipment and services.  It was also likely that
  128. uncertainty would lead to customers holding back on their purchases of
  129. networking equipment until the situation was clearer.
  130.  
  131. A straw poll showed a clear majority view that there should be a
  132. decision for one solution.
  133.  
  134.  
  135. The Time Scale for a Decision
  136.  
  137. The best guesstimates for the remaining lifetime of the IPv4 address
  138. space put the figure at around five to seven years, assuming CIDR is
  139. widely deployed.  A margin of potential error in these figures is to be
  140. expected---one suggestion was that they could be out by a factor of four
  141. in either direction.  However, the address space is only five doublings
  142. away from exhaustion.
  143.  
  144. It was strongly recommended that more work be done on investigating the
  145. feasible remaining lifetime of IPv4.
  146.  
  147. It is also difficult to estimate the time taken to implement, test and
  148. then deploy any chosen solution:  it was not clear who was best placed
  149. to do this.  The ordering of the decisions might also have a different
  150. priority for customers and vendors than for the IETF. For example, it
  151. might be necessary to have a decision about DNS changes early in order
  152. to deploy the infrastructure necessary to support IPng in advance of the
  153. availability of the IPng protocol itself.  The IETF work was not
  154. proceeding in this order.
  155.  
  156.  
  157. The Evaluation Process
  158.  
  159. Concern was expressed that the evaluation criteria which had so far been
  160. discussed were too general to support a defensible choice on the grounds
  161. of technical adequacy.  The criteria had emerged in parallel with the
  162. protocol designs, and had so far not gelled enough to eliminate any
  163. candidate.  There were also potential legal difficulties if the IETF
  164. appeared to be eliminating proposals on arbitrary grounds.
  165.  
  166. It was stated frequently and forcibly that the transition costs should
  167. be a significant factor in the selection criteria.  Concerns were
  168. expressed by several service providers that the developers had little
  169.  
  170.                                    3
  171.  
  172.  
  173.  
  174.  
  175.  
  176. appreciation of the real-world networking complexities that transition
  177. would force people to cope with.  If the cost of transition outweighed
  178. the pain of other solutions (application gateways or address
  179. translators) customers would not deploy IPng.
  180.  
  181. It was suggested a couple of times that the working groups should be
  182. invited to evaluate each others' proposals in order to investigate their
  183. weaknesses, or that the proposals should be vetted by disinterested
  184. parties.  It was suggested that the proposals were too similar for any
  185. reasonable choice to be made on the grounds of technical strength.
  186. However there was no consensus on these points.
  187.  
  188. Although one of the goals of IPng had been to use the inevitable
  189. transition required by address exhaustion and routing problems to
  190. incorporate new features, there were a number of concerns about bundling
  191. too much additional complexity into an already difficult problem.  It
  192. wasn't even clear that the technology yet existed to handle some of the
  193. new features that had been touted for IPng.  IPng should appear simply
  194. like a new release of IPv4; although this would not necessarily bring
  195. new features, people would still transition through enlightened
  196. self-interest---to avoid disconnection from the global Internet in the
  197. future.  There was no consensus about how to resolve this dilemma, since
  198. both smooth transition and multimedia support are musts.
  199.  
  200. Various parties were identified as needing to assist in the evaluation
  201. process:
  202.  
  203.  
  204.    o Operators, who need to understand deployment costs and scenarios.
  205.    o Vendors, who understand the implementation consequences.
  206.  
  207.  
  208.  
  209. The Decision Process
  210.  
  211. There is an IETF process for making a decision on protocol standards:
  212. working groups can be given deadlines to submit papers to the IESG which
  213. then decides which to progress as standards.  It was suggested that this
  214. process has only broken down in that the deadlines had not been applied.
  215.  
  216. Other suggestions included:
  217.  
  218.  
  219.    o Urging coalitions between the different working groups.
  220.  
  221.    o Forming an ``IPng'' working group either to make recommendations or
  222.      to draw together the different proposals.
  223.  
  224.    o Asking the IESG or even the IAB to drive the decision process.
  225.  
  226.  
  227. On the basis of a straw poll, there was strong consensus that the
  228. decision should be made on technical grounds alone (subject to
  229.  
  230.                                    4
  231.  
  232.  
  233.  
  234.  
  235.  
  236. reasonable costs of implementation, deployment and transition).
  237.  
  238. It was repeatedly stated that an obvious requirement was that the
  239. proposed solution should work.  There were at least two components to
  240. this:  interoperability and scaling.  This would be difficult to
  241. establish without large-scale piloting.  There was no consensus on who
  242. might reasonably be expected to participate in such an exercise.
  243.  
  244. The following day, at the Thursday open plenary session, a proposal that
  245. the IESG should take the responsibility of recommending an IPng choice
  246. to the IETF met with strong consensus.  This proposal included a series
  247. of steps that the IESG should take to develop a progressive decision
  248. with community involvement.
  249.  
  250.  
  251. Attendees
  252.  
  253. George Abe               abe@infonet.com
  254. Chris Adie               C.J.Adie@edinburgh.ac.uk
  255. Nick Alfano              alfano@mpr.ca
  256. James Allard             jallard@microsoft.com
  257. Bernt Allonen            bal@tip.net
  258. Harald Alvestrand        Harald.Alvestrand@uninett.no
  259. Frederik Andersen        fha@dde.dk
  260. Per Andersson            pa@cdg.chalmers.se
  261. Toshiya Asaba            asaba@iij.ad.jp
  262. Josee Auber              Josee_Auber@hpgnd.grenoble.hp.com
  263. Anders Baardsgaad        anders@cc.uit.no
  264. Dennis Baker             dbaker@wellfleet.com
  265. Jim Barnes               barnes@xylogics.com
  266. Tony Bates               tony@ripe.net
  267. Nutan Behki              Nutan_Behki@qmail.newbridge.com
  268. Axel Belinfante          Axel.Belinfante@cs.utwente.nl
  269. Vincent Berkhout         berkhout@cs.utwente.nl
  270. Per Bilse                bilse@ic.dk
  271. Jim Binkley              jrb@ibeam.intel.com
  272. Robert Blokzijl          K13@nikhef.nl
  273. Rebecca Bostwick         bostwick@es.net
  274. Jim Bound                bound@zk3.dec.com
  275. Robert Braden            braden@isi.edu
  276. Stefan Braun             smb@cs.tu-berlin.de
  277. Thomas Brisco            brisco@pilot.njin.net
  278. Ronald Broersma          ron@nosc.mil
  279. J. Nevil Brownlee        nevil@ccu1.aukuni.ac.nz
  280. Steve Buchko             stevebu@newbridge.com
  281. Ross Callon              rcallon@wellfleet.com
  282. Peter Cameron            cameron@xylint.co.uk
  283. C. Allan Cargille        allan.cargille@cs.wisc.edu
  284. Brian Carpenter          brian@dxcern.cern.ch
  285. Vinton Cerf              vcerf@cnri.reston.va.us
  286. George Chang             gkc@ctt.bellcore.com
  287. A. Lyman Chapin          lyman@bbn.com
  288. Chris Chiotasso          chris@andr.ub.com
  289.  
  290.                                    5
  291.  
  292.  
  293.  
  294.  
  295.  
  296. Henry Clark              henryc@oar.net
  297. Richard Colella          colella@nist.gov
  298. David Conrad             davidc@iij.ad.jp
  299. Al Costanzo              al@akc.com
  300. Stephen Crocker          crocker@tis.com
  301. Dave Cullerot            cullerot@ctron.com
  302. Geert Jan de Groot       geertj@ica.philips.nl
  303. Stephen Deering          deering@parc.xerox.com
  304. Steve DeJarnett          steve@ibmpa.awdpa.ibm.com
  305. Kurt Dobbins             dobbins@ctron.com
  306. Jeffrey Dunn             dunn@neptune.nrl.navy.mil
  307. Francis Dupont           francis.dupont@inria.fr
  308. Toerless Eckert          Toerless.Eckert@informatik.uni-erlangen.de
  309. Kjeld Borch Egevang      kbe@craycom.dk
  310. Ed Ellesson              ellesson@vnet.ibm.com
  311. Robert Enger             enger@reston.ans.net
  312. Hans Eriksson            hans@sics.se
  313. Deborah Estrin           estrin@usc.edu
  314. Dino Farinacci           dino@cisco.com
  315. Stefan Fassbender        stf@easi.net
  316. Eric Fleischman          ericf@act.boeing.com
  317. Peter Ford               peter@goshawk.lanl.gov
  318. Osten Franberg           euaokf@eua.ericsson.se
  319. Paul Francis             Francis@thumper.bellcore.com
  320. Dan Frommer              dan@jeremy.enet.dec.com
  321. Shoji Fukutomi           fuku@furukawa.co.jp
  322. Vince Fuller             vaf@stanford.edu
  323. Peter Furniss            p.furniss@ulcc.ac.uk
  324. Eugene Geer              ewg@cc.bellcore.com
  325. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  326. Joseph Godsil            jgodsil@ncsa.uiuc.edu
  327. Tim Goodwin              tim@pipex.net
  328. Ramesh Govindan          rxg@thumper.bellcore.com
  329. Marcel Graf              graf%dhdibm1.bitnet@vm.gmd.de
  330. Terry Gray               gray@cac.washington.edu
  331. Ron Greve                rgreve@cs.utwente.nl
  332. Phillip Gross            pgross@ans.net
  333. Chris Gunner             gunner@dsmail.lkg.dec.com
  334. Joel Halpern             jmh@network.com
  335. Susan Hares              skh@merit.edu
  336. Denise Heagerty          denise@dxcoms.cern.ch
  337. Marco Hernandez          marco@mh-slip.cren.edu
  338. Robert Hinden            hinden@eng.sun.com
  339. Frank Hoffmann           hoffmann@dhdibm1.bitnet
  340. John Hopkins             J_Hopkins@icrf.icnet.uk
  341. Marc Horowitz            marc@mit.edu
  342. Chris Howard             chris_howard@inmarsat.org
  343. Christian Huitema        Christian.Huitema@sophia.inria.fr
  344. Erik Huizer              Erik.Huizer@SURFnet.nl
  345. Geoff Huston             g.huston@aarnet.edu.au
  346. Phil Irey                pirey@relay.nswc.navy.mil
  347. Ole Jacobsen             ole@interop.com
  348. David Jacobson           dnjake@vnet.ibm.com
  349. Ronald Jacoby            rj@sgi.com
  350.  
  351.                                    6
  352.  
  353.  
  354.  
  355.  
  356.  
  357. Ola Johansson            ojn@tip.net
  358. David Johnson            dbj@cs.cmu.edu
  359. Laurent Joncheray        lpj@merit.edu
  360. Philip Jones             p.jones@jnt.ac.uk
  361. Cyndi Jung               cmj@3com.com
  362. Thomas Kaeppner          kaeppner%heidelbg.vnet@ibmpa.ibm.com
  363. Tomaz Kalin              kalin@rare.nl
  364. Scott Kaplan             scott@wco.ftp.com
  365. Anders Karlsson          sak@cdg.chalmers.se
  366. Daniel Karrenberg        daniel@ripe.net
  367. Frank Kastenholz         kasten@ftp.com
  368. Peter Kaufmann           kaufmann@dfn.dbp.de
  369. Sean Kennedy             liam@nic.near.net
  370. Stephen Kent             kent@bbn.com
  371. Zbigniew Kielczewski     zbig@eicon.qc.ca
  372. John Klensin             Klensin@infoods.unu.edu
  373. Mark Knopper             mak@merit.edu
  374. Peter Koch               pk@techfak.uni-bielefeld.de
  375. Rajeev Kochhar           rajeev_kochhar@3com.com
  376. Ton Koelman              koelman@stc.nato.int
  377. Mark Kosters             markk@internic.net
  378. Glenn Kowack             Glenn@eu.net
  379. John Krawczyk            jkrawczy@wellfleet.com
  380. Arnold Krechel           krechel@gmd.de
  381. John Larson              jlarson@parc.xerox.com
  382. Eliot Lear               lear@sgi.com
  383. Jose Legatheaux Martins  jalm@fct.unl.pt
  384. Tony Li                  tli@cisco.com
  385. Susan Lin                suelin@vnet.ibm.com
  386. John Lindsay             lindsay@kingston.ac.uk
  387. Robin Littlefield        robin@wellfleet.com
  388. Anne Lord                anne@ripe.net
  389. Peter Lothberg           roll@stupi.se
  390. Paul Lustgarten          Paul.Lustgarten@att.com
  391. Paolo Malara             malara@crs4.it
  392. Allison Mankin           mankin@cmf.nrl.navy.mil
  393. Bill Manning             bmanning@rice.edu
  394. David Marlow             dmarlow@relay.nswc.navy.mil
  395. Cynthia Martin           martin@spica.disa.mil
  396. Ignacio Martinez         martinez@rediris.es
  397. Jun Matsukata            jm@eng.isas.ac.jp
  398. Keith McCloghrie         kzm@hls.com
  399. Peter Merdian            merdian@rus.uni-stuttgart.de
  400. Greg Minshall            minshall@wc.novell.com
  401. Keith Mitchell           keith@pipex.net
  402. Pushpendra Mohta         pushp@cerf.net
  403. Keith Moore              moore@cs.utk.edu
  404. Kees Neggers             neggers@surfnet.nl
  405. Peder Chr.  Noergaard    pcn@tbit.dk
  406. Erik Nordmark            nordmark@eng.sun.com
  407. David O'Leary            doleary@cisco.com
  408. Masataka Ohta            mohta@cc.titech.ac.jp
  409. Jorg Ott                 jo@cs.tu-berlin.de
  410. Christian Panigl         christian.panigl@cc.univie.ac.at
  411.  
  412.                                    7
  413.  
  414.  
  415.  
  416.  
  417.  
  418. Andrew Partan            asp@uunet.uu.net
  419. Michael Patton           map@bbn.com
  420. Geir Pedersen            Geir.Pedersen@usit.uio.no
  421. Charles Perkins          perk@watson.ibm.com
  422. Drew Perkins             ddp@fore.com
  423. David Piscitello         dave@mail.bellcore.com
  424. Mel Pleasant             pleasant@hardees.rutgers.edu
  425. Willi Porten             porten@gmd.de
  426. Mark Prior               mrp@itd.adelaide.edu.au
  427. Juergen Rauschenbach     jrau@dfn.de
  428. Alex Reijnierse          a.a.reijnierse@research.ptt.nl
  429. Victor Reijs             reijs@surfnet.nl
  430. Robert Reschly           reschly@brl.mil
  431. Georg Richter            richter@uni-muenster.de
  432. Dan Romascanu            dan@lannet.com
  433. Luc Rooijakkers          lwj@cs.kun.nl
  434. Marjo Rottschaefer
  435. Hal Sandick              sandick@vnet.ibm.com
  436. Miguel Sanz              miguel.sanz@rediris.es
  437. Jon Saperia              saperia@tay.dec.com
  438. Eve Schooler             schooler@isi.edu
  439. John Scudder             jgs@merit.edu
  440. Tim Seaver               tas@concert.net
  441. Kitty Shih               kmshih@novell.com
  442. William Simpson          Bill.Simpson@um.cc.umich.edu
  443. W. David Sincoskie       sincos@thumper.bellcore.com
  444. Simon Spero              simon_spero@unc.edu
  445. Vladimir Sukonnik        sukonnik@process.com
  446. Fumio Teraoka            tera@csl.sony.co.jp
  447. Marten Terpstra          marten@ripe.net
  448. Kamlesh Tewani           ktt@arch2.att.com
  449. Richard Thomas           rjthomas@bnr.ca
  450. Susan Thomson            set@bellcore.com
  451. Martin Toet              toet@cs.utwente.nl
  452. Antoine Trannoy          trannoy@crs4.it
  453. Robert Ullmann           ariel@world.std.com
  454. Willem van der Scheun    scheun@sara.nl
  455. Guido van Rossum         guido@cwi.nl
  456. Werner Vogels            werner@inesc.pt
  457. Ruediger Volk            rv@informatik.uni-dortmund.de
  458. Steven Waldbusser        waldbusser@andrew.cmu.edu
  459. Sandro Wallach           sandro@elf.com
  460. Abel Weinrib             abel@bellcore.com
  461. Douglas Williams         dougw@ralvmg.vnet.ibm.com
  462. Kirk Williams            kirk@sbctri.sbc.com
  463. Steven Willis            steve@wellfleet.com
  464. Sam Wilson               sam.wilson@ed.ac.uk
  465. Wilfried Woeber          Wilfried.Woeber@CC.UniVie.ac.at
  466. Jessica Yu               jyy@merit.edu
  467. Paul Zawada              Zawada@ncsa.uiuc.edu
  468.  
  469.  
  470.  
  471.                                    8
  472.