Network Working Group                                        D. Heagerty
Request for Comments: 1670                                          CERN
Category: Informational                                      August 1994


               Input to IPng Engineering Considerations

Status of this Memo

  This memo provides information for the Internet community.  This memo
  does not specify an Internet standard of any kind.  Distribution of
  this memo is unlimited.

Abstract

  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 [email protected] mailing list.

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
   - 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.





Heagerty                                                        [Page 1]

RFC 1670        Input to IPng Engineering Considerations     August 1994


  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
  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.




Heagerty                                                        [Page 2]

RFC 1670        Input to IPng Engineering Considerations     August 1994


  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.

Security Considerations

  Security issues are not discussed in this memo.

Author's Address

  Denise Heagerty
  Communications Systems Group
  Computing and Networks Division
  CERN
  European Laboratory for Particle Physics
  1211 Geneva 23, Switzerland

  Phone:  +41 22 767-4975
  Fax:    +41 22 767-7155
  EMail: [email protected]























Heagerty                                                        [Page 3]

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.