home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1670.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  5.2 KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        D. Heagerty
  8. Request for Comments: 1670                                          CERN
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.                 Input to IPng Engineering Considerations
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the big-internet@munnari.oz.au mailing list.
  26.  
  27. Summary
  28.  
  29.    This white paper expresses some personal opinions on IPng engineering
  30.    considerations, based on experience with DECnet Phase V transition.
  31.    It suggests breaking down the IPng decisions and transition tasks
  32.    into smaller parts so they can be tackled early by the relevant
  33.    experts.
  34.  
  35. Timescales
  36.  
  37.    In order to allow key decisions to be taken early, I would like to
  38.    see IPng decisions and timescales broken down into into smaller
  39.    parts, for example:
  40.  
  41.     - address structure and allocation mechanism
  42.     - name service changes
  43.     - host software and programming interface changes
  44.     - routing protocol changes
  45.  
  46.    Although interrelated, not all details need to be defined by the same
  47.    date. Identify which decisions will be hard to change and which can
  48.    be allowed to evolve. All changes should be worked on in parallel,
  49.    but the above list indicates a feeling for urgency of a decision.
  50.    Our experience has been that administrative changes (as may be
  51.    required for addressing changes) need the greatest elapse time for
  52.    implementation, whereas routing protocol changes need the least.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Heagerty                                                        [Page 1]
  59.  
  60. RFC 1670        Input to IPng Engineering Considerations     August 1994
  61.  
  62.  
  63.    I would like to see an early decision on address structure and enough
  64.    information for service managers to start planning their transition.
  65.    Some hosts will never be upgraded and will need to be phased out or
  66.    configured with reduced connectivity. A lead time of 10 years (or
  67.    more) will help to take good long term technical decisions and ease
  68.    financial and organisational constraints.
  69.  
  70. Transition and deployment
  71.  
  72.    Transition requires intimate knowledge of the environment (financial,
  73.    political as well as technical). The task needs to be broken down so
  74.    that service managers close to their clients can take decisions and
  75.    make them happen.
  76.  
  77.    Let the service managers adapt the solutions for their environment by
  78.    providing them with a transition toolbox and scenarios of their uses
  79.    based on real examples. Clearly state the merits and limitations of
  80.    different transition strategies.
  81.  
  82.    Provide for transition autonomy. Let systems and sites transition at
  83.    different times, as convenient for them.
  84.  
  85.    Identify what software needs to be changed and keep an up-to-date
  86.    list.
  87.  
  88.    Identify what is essential to have in place so that service managers
  89.    can transition at their own pace.
  90.  
  91.    Allow for a feedback loop to improve software based on experience.
  92.  
  93. Configuration, Administration, Operation
  94.  
  95.    We run IP on a wide range of equipment and operating systems.  We
  96.    need an easy way to (re-)configure all our IP capable systems.  The
  97.    systems need to be sent their IP parameters (e.g., their address,
  98.    address of their default router, address of their local name servers)
  99.    and we need to obtain data from the system (e.g., contact information
  100.    for owner, location and name of system). We also need an easy way to
  101.    update DNS.
  102.  
  103.    In our environment systems are regularly moved between buildings and
  104.    we therefore find the tight coupling of IP address to physical subnet
  105.    over restrictive. Automatic configuration could help overcome this.
  106.  
  107.    We would like to efficiently load balance users of various IP based
  108.    services (e.g., telnet, ftp, locally written applications) across a
  109.    number of systems.
  110.  
  111.  
  112.  
  113.  
  114. Heagerty                                                        [Page 2]
  115.  
  116. RFC 1670        Input to IPng Engineering Considerations     August 1994
  117.  
  118.  
  119.    The ability to break down addresses and routing into several levels
  120.    of hierarchy is important to allow the delegation of network
  121.    management into subdomains. As the network grows so does the desire
  122.    to increase the number of levels of hierarchy.
  123.  
  124. Disclaimer and acknowledgments
  125.  
  126.    This is a personal view and does not necessarily represent that of my
  127.    employer. I have benefited from many transition discussions with my
  128.    colleagues at CERN, other High Energy Physics DECnet managers and
  129.    Digital Equipment Corporation engineers.
  130.  
  131. Security Considerations
  132.  
  133.    Security issues are not discussed in this memo.
  134.  
  135. Author's Address
  136.  
  137.    Denise Heagerty
  138.    Communications Systems Group
  139.    Computing and Networks Division
  140.    CERN
  141.    European Laboratory for Particle Physics
  142.    1211 Geneva 23, Switzerland
  143.  
  144.    Phone:  +41 22 767-4975
  145.    Fax:    +41 22 767-7155
  146.    EMail: denise@dxcoms.cern.ch
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Heagerty                                                        [Page 3]
  171.  
  172.