Date: Mon, 13 Aug 2001 12:20:53 +0200 (CEST)
From: Erik Nordmark <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| But your constraint seem to imply that the ID(link2) would now need to
| change from 2 to be the same as the ID for some other interface in that link.
No, that's reading more into what I said than I intended.
The important part, from my perspective, was ...
avoid the problem where "1" means one place in one context
and somewhere totally different in another.
The rest of it was just one possibility, allowing all of interfaces, links
and sites, to be numbered with small integers starting from 1. (That is,
avoid numbers that have bits set up in the high bits, which Jinmei's
B and C seemed to be requiring).
How the numbering is done is pretty much irrelevant to me, provided that
we don't have identifier ambiguity, and ideally, without using identifiers
with magic in the upper bits. For all I care, you can number the interfaces
1, 2, 3, ... N, then the links N+1, N+2, ... M, then the sites M+1, ... P,
then if a new interface or link (or site) appears, call it P+1. It doesn't
matter that the numbers for any one type aren't contiguous.
If an implementation wanted, it could even number its interfaces 1 4 7 10 ...
its links 2 5 8 11 ..., and its sites 3 6 9 12 ... (also no requirement for
all numbers to actually be in use).
The 'Instead "2" in link context would mean a particular link, in site
context it would mean a collection of links, but the link "2" would
certainly be one of them' comment was just meant as one possible way that
small numbers could be assigned in a way that wouldn't be too horrible
(at least the identifier would always mean one general direction).
You might remember that it was also a question - whether that's something
that scheme A would allow (not having followed this debate, I had no idea
whether it was assumed for A that the id's would be 1 2 3 for interfaces,
1 2 3 for links, and 1 2 3 for sites... - that's how it was represented
in the example, and that I don't much like at all).
Certainly I wouldn't want applications to have to go polling (or handling
events) to discover that the id's have all changed because of some interface
reconfiguration - the IDs should certainly be stable from one boot to
another (or at least reasonably stable, if an interface is removed, then
replaced, I don't care if it has the same ID it used to have or not).
I'm not sure how applications should handle the case where an interface
moves from one link to another, or a link moves from one site to another
(which would be done by administrator configuration or some automated
equivalent thereof I assume). For more applications it probably doesn't
matter, for the others (eg: I want to (many times over an interval) send
to all interfaces in site X) some kind of polling or event mechanism
will probably be needed.
| I guess one could handle this type of reconfiguration by
| - never reusing the IDs at any scope for new stuff, and
| - somehow keeping the historic bindings around.
The latter isn't needed, assuming the current bindings are kept around.
But yes, never re-using an ID is one fairly easy way to handle things,
and one which is likely to be safe.
Maybe what I'd like to say would be that no identifier should be used for
any interface, link, or site, that is also used for another of those,
unless the smaller of those (as defined, ie: interface < link < site)
is a subset of the bigger (as configured). No requirement that there
ever be any duplication, just a restriction on when duplicate ids in
different scopes are permitted.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
