Browse Prior Art Database

Input to IPng Engineering Considerations (RFC1670)

IP.com Disclosure Number: IPCOM000002507D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 3 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Heagerty: AUTHOR

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 big-internet@munnari.oz.au mailing list.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 60% of the total text.

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 big-internet@munnari.oz.au 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.

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