|
|
От: |
netch80
|
http://netch80.dreamwidth.org/ |
| Дата: | 12.11.24 09:37 | ||
| Оценка: | 4 (2) | ||
Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements
To: SIPP Mailing list <sipp@sunroof2.eng.sun.com>,
big-Internet@munnari.oz.au
Date: Thu, 7 Jul 1994 15:35:29 -0500 (EST)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
Cc: mankin@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu,
"Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
Message-Id: <9407072035.aa15952@sundance.itd.nrl.navy.mil>
> Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF:
Hi from SIPP, IETF, and BIG-INTERNET.
> At this time it would appear to us that there is considerable consensus
> that a fixed length, topologically structured, hierarchical
Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
of fixed length addresses before. My biggest beef with variable length
addresses is the issue of maintaining additional state or taking additional
time to parse an address whose length I don't know at the start. Granted,
flow ID's and optimizing for certain common ("fast path") cases may help
this, but flow ID's still require tables with flow ID's for keys, and
today's common case may be tomorrow's exception. Authentication and
encryption also present problems similar to flow ID's with key lookup. I
don't want to rewrite my (statically configured) OS kernel in 4 years when
today's common cases no longer exist. (Although, admittedly, current trends
in OS research may render this argument obsolete.)
Parsing addresses is a problem all along the path (both network hops, and
within each system) an IPng datagram takes. Both routers and end-systems
have to parse addresses, at least to the point of finding a fast path. Our
implementation experience has shown us that variable length addresses adds a
whole new layer of complexity to things such as:
* Routing lookups
* User interface issues
* Storage requirements
* Address parsing (for lookups, incoming packets, etc.)
Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
of fixed length addresses before. My biggest beef with variable length
addresses is the issue of maintaining additional state or taking additional
time to parse an address whose length I don't know at the start. Granted,
flow ID's and optimizing for certain common ("fast path") cases may help
this, but flow ID's still require tables with flow ID's for keys, and
today's common case may be tomorrow's exception. Authentication and
encryption also present problems similar to flow ID's with key lookup. I
don't want to rewrite my (statically configured) OS kernel in 4 years when
today's common cases no longer exist. (Although, admittedly, current trends
in OS research may render this argument obsolete.)
Parsing addresses is a problem all along the path (both network hops, and
within each system) an IPng datagram takes. Both routers and end-systems
have to parse addresses, at least to the point of finding a fast path. Our
implementation experience has shown us that variable length addresses adds a
whole new layer of complexity to things such as:
* Routing lookups
* User interface issues
* Storage requirements
* Address parsing (for lookups, incoming packets, etc.)
Since it is still fixed length it has none of the nightmares of
variable-length addresses.
> longer than 16 byte fixed length address now.
I would like to see why we NEED any address space above 16-bytes. Does
anyone have any solid arguments as to why 16 bytes is not enough? I've seen
ones for 8, but not 16.
Also, let's consider alignment issues if picking a size above 16 bytes. 20
blows 8-byte alignment, 24 does not. (But of course, if 128-bit machines
happen, 24-byte addresses will be annoying on 128-bit machines.)
But hey, at least it's fixed length.
> only 16 byte length addresses now but ability
> to lengthen the address later.
This will add confusion to implementations, and smacks of variable-length.
Experience with OSI implementations shows that many do not handle NSAP's
greater than 20 bytes.
Absolutely not a good idea.
> At this point the consensus among the IPng directorate
> and on several of the mailing lists seems fairly clear
> (a 16 byte length address is good for those things).
Yes, but IMHO, no MORE than 16 bytes.
> This is a good time to bring forward your remaining views
> about the requirements for address length for IPng.
My position can be best summarized as:
The SMALLEST possible fixed-length address. And that length
better have a good justification for why it cannot be smaller.
--
Dan McDonald | Mail: {danmcd,mcdonald}@itd.nrl.navy.mil --------------+
Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html |
Naval Research Lab | Phone: (202) 404-7122 #include <disclaimer.h> |
Washington, DC | "Rise from the ashes, A blaze of everyday glory" — Rush +
To: sipp@sunroff.eng.sun.com, ipng@cmf.nrl.navy.mil,
big-internet@munnari.oz.au
Cc: deering@parc.xerox.com
Subject: SIPP-16 draft
Date: Mon, 18 Jul 1994 01:13:15 PDT
X-Orig-Sender: Steve Deering <deering@parc.xerox.com>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <94Jul18.011317pdt.12171@skylark.parc.xerox.com>
I have submitted a new version of the SIPP spec, with 16-byte addresses,
as an Internet Draft. If you want to grab a copy before it shows up in
the official directories, you can get it from:
ftp://parcftp.xerox.com/pub/sipp/draft-ietf-sipp-spec-01.txt
Besides the change of address size, a number of other changes were made,
arising from the implementors' meeting in Seattle and subsequent events.
Be sure to read through Appendix B to find out everything that changed
since the last draft.
Steve
