Input to IPng Engineering Considerations (RFC1670)
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
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.
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 firstname.lastname@example.org mailing list.
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.
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 soft...