Internet DRAFT - draft-heagerty-input

draft-heagerty-input




Network Working Group                                        D. Heagerty
Internet draft                                                      CERN
                                                           21 March 1994


                Input to IPng Engineering Considerations
                   <draft-heagerty-ipng-input-00.txt>

Status of this Memo

   This document was submitted to the IETF IPng area in response to RFC
   1550  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the big-internet@munnari.oz.au mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

Summary

   This white paper expresses some personal opinions on IPng engineering
   considerations, based on experience with DECnet Phase V transition.
   It suggests breaking down the IPng decisions and transition tasks
   into smaller parts so they can be tackled early by the relevant
   experts.

Timescales

   In order to allow key decisions to be taken early, I would like to
   see IPng decisions and timescales broken down into into smaller
   parts, for example:

    - address structure and allocation mechanism
    - name service changes



Heagerty                                                        [Page 1]

RFC draft       Input to IPng Engineering Considerations   21 March 1994


    - host software and programming interface changes
    - routing protocol changes

   Although interrelated, not all details need to be defined by the same
   date. Identify which decisions will be hard to change and which can
   be allowed to evolve. All changes should be worked on in parallel,
   but the above list indicates a feeling for urgency of a decision.
   Our experience has been that administrative changes (as may be
   required for addressing changes) need the greatest elapse time for
   implementation, whereas routing protocol changes need the least.

   I would like to see an early decision on address structure and enough
   information for service managers to start planning their transition.
   Some hosts will never be upgraded and will need to be phased out or
   configured with reduced connectivity. A lead time of 10 years (or
   more) will help to take good long term technical decisions and ease
   financial and organisational constraints.

Transition and deployment

   Transition requires intimate knowledge of the environment (financial,
   political as well as technical). The task needs to be broken down so
   that service managers close to their clients can take decisions and
   make them happen.

   Let the service managers adapt the solutions for their environment by
   providing them with a transition toolbox and scenarios of their uses
   based on real examples. Clearly state the merits and limitations of
   different transition strategies.

   Provide for transition autonomy. Let systems and sites transition at
   different times, as convenient for them.

   Identify what software needs to be changed and keep an up-to-date
   list.

   Identify what is essential to have in place so that service managers
   can transition at their own pace.

   Allow for a feedback loop to improve software based on experience.

Configuration, Administration, Operation

   We run IP on a wide range of equipment and operating systems.  We
   need an easy way to (re-)configure all our IP capable systems.  The
   systems need to be sent their IP parameters (e.g. their address,
   address of their default router, address of their local name servers)
   and we need to obtain data from the system (e.g. contact information



Heagerty                                                        [Page 2]

RFC draft       Input to IPng Engineering Considerations   21 March 1994


   for owner, location and name of system). We also need an easy way to
   update DNS.

   In our environment systems are regularly moved between buildings and
   we therefore find the tight coupling of IP address to physical subnet
   over restrictive. Automatic configuration could help overcome this.

   We would like to efficiently load balance users of various IP based
   services (e.g. telnet, ftp, locally written applications) across a
   number of systems.

   The ability to break down addresses and routing into several levels
   of hierarchy is important to allow the delegation of network
   management into subdomains. As the network grows so does the desire
   to increase the number of levels of hierarchy.

Disclaimer and acknowledgments.

   This is a personal view and does not necessarily represent that of my
   employer. I have benefited from many transition discussions with my
   colleagues at CERN, other High Energy Physics DECnet managers and
   Digital Equipment Corporation engineers.

Author's Address

   Denise Heagerty
   Communications Systems Group           Phone:  +41 22 767-4975
   Computing and Networks Division        Fax:    +41 22 767-7155
   CERN                                   E-mail: denise@dxcoms.cern.ch
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland




















Heagerty                                                        [Page 3]