Iljitsch van Beijnum wrote:
On 14 jun 2004, at 12:12, Joe Touch wrote:
a) are two IDs comparable within the same app over time? i.e., can an ID change? if so, can the old ID be used?
b) can two IDs on different apps on the same node be compared?
c) can two IDs on different nodes be compared?
During the meeting there was some talk about per-session identifiers. Wouldn't such identifiers be pretty much useless?
They're used in HIP, e.g.
What I want from an identifier is be able to set up sessions towwards it, the same way I can now with a FQDN or IP address. If this isn't possible, what use are these identifiers? In this situation an identifierless solution would be better. And if there are ephemeral values that are used internally somewhere, we should probably avoid calling them "identifiers".
The name of the endpoint (A) that you talk to isn't the same as the name used for forwarding (B), which may not be the same as any of the multiple endpoint addresses (C1...CN).
The one I'm referring to is B. A might be a DNS name or current 'well known' IP address used to bootstrap the communication.
In the good old days it would have been possible to presume that if two FQDN or IP address values are identical, they point to the same host.
A FQDN has always been mappable to multiple IP addresses. If two IP addresses are identical, it is still the case that they either point to the same host or something that emulates one host.
However, in these days of load balancers this is no longer true, although it's usually safe to make this assumption in applications because the different hosts would be providing the same service.
When load balancers break the 'same host or equivalent' they can 'break the Internet' (e.g., arbitrary protocols can break).
In the design team # 1 we had some discussions on the FQDN <-> ID <-> locator relationship and I think we agreed that the ID should be tied to a single host, even if the FQDN is shared between more than one host.
A must be tied to a single host or something that emulates such, for the reasons above.
Obviously it must be possible to change identifiers. This means it must be possible to have more than one at the same time or operators will revolt. Another reason to have more than one ID at one point in time is for privacy reasons, this would be similar to RFC 3041.
Changing A is like renumbering now; a slow, out-of-band operation that requires resynchronization (e.g., of the DNS). Changing B is more of an opportunity than a liability...
I think this is a very hard conversation to have in the abstract. I think it will be much easier to analyze these questions in terms of a specific proposal. So maybe we should note them as open, until our ongoing reduction of the solution set from many to few has been achieved.