Ofer Inbar wrote:
> For what it's worth, I've been watching this discussion for a
> while, not as a proponent of any particular side, and I
> completely agree with Keith on this point. I've seen Tony
> Hain repeatedly make the assertion that this discussion is
> about the fact that not all addresses can be reached from
> everywhere, or that we don't have a "flat routing space", or
> any number of related restatements... but I have seen nothing
> other than Tony's assertions that would make me think this
> dicussion is about any of those things. It puzzles me that
> he keeps repeating them.
>
> Tony, *why* do you think this discussion is about reachability?
Below
>
> Everyone else: Do any of you believe that's what this is about, aside
> from Tony's assertions and peoples responses to those assertions?
>
> From what I have seen, those who think "local scope" is
> harmful, are concerned about the ambuity of addresses, as
> Keith says here again. They are NOT concerned about the fact
> that a given address may not be reachable from some places,
> or may be reachable via different routes from different
> places. Or, rather, whether they're concerned about that or
> not, it has nothing to do with their objections to locally
> scoped addresses. All of their objections to locally scoped
> addresses seem to be about the fact that the addresses are
> ambiguous, not unique. They have no objections to globally
> unique addresses that remain "local" as far as routing and
> reachability.
We have several proposals for removing the ambiguity in the current SL,
so while we may not agree on a specific one, we have examples of
technically how to do that. Therefore the effort to eliminate SL can't
be about ambiguity, because we could simply fix that component of the
current SL with little effort.
The reason I say this is about reachability is that even with unique
addresses, applications will fail when they choose to pass 'an opaque
identifier' around, while they simultaneously assume that the content is
a valid topology locator at the receiver. The arguments claim the need
for opaqueness as an application simplifier on one hand, at the same
they insist that the topology match their perspective of a flat routing
space. The real network is not a single flat routing space.
Given a list of addresses for a target, how would an application pick
one that is assured to work at the receiver? Answer: it can't without
knowing the topology. The only way to keep the app from knowing
topology, and make the app work in the presence of a list is to pass the
label that was used to get the initial list, so the receiver can get its
own that is topologically appropriate. This has nothing at all to do
with ambiguity in the allocations, and everything to do with the fact
that topology locators have different utility in different parts of the
network. For example:
---- A ----
| I
| n
| t
I e ---- C
2 r
| n
| e
| t
---- B ----
There are no ambiguous addresses here, just a list of potential topology
locators. If B wants to tell C to connect to A, it either has to pass a
label that C can use to figure it out, or know enough about the topology
to know which locator C needs. This simple example of why routing is not
globally flat is why I have been saying that an assumption by
applications that they can simply pick any member of the list and the
result will be useful at C is invalid.
Replace I2 in the above diagram with one of the globally unique versions
of SL, and the issues are exactly the same. If B hands C the
non-Internet address of A, there will be no valid route in the public
net.
Replace I2 with the current version of SL, and the only difference is
that C might be in a site which uses the same subnet prefix in its local
use, so the bits will head toward a router inside the C site rather than
being dropped in the public net (people that pay by volume on the ISP
link actually consider this a feature). If the A & C sites chose to
manually allocate IIDs 1, 2, 3 ... there is a possibility that the
address handed by B would point to a different host in the C site. If
either site chose to use just about any other scheme for generating
IIDs, the likelihood of any given IID pattern being at the other site,
let alone having the same subnet prefix, is so close to 0 it is not
worth discussing. Note, this is not an argument for keeping the
ambiguity of the current SL.
Ambiguity is not the cause of the problem here, it is just the red
herring used to bolster support for shooting the SL messenger. The
fundamental problem is that processes exist that refuse to acknowledge
the network is not a single flat routing space. They do this by passing
around topology information with the explicit assumption that the
'opaque contents' will be a valid topology locator at the receiver.
Until we deal with this, there will continue to be lengthy discussions
about removing limited scope addresses from the architecture. Since
scoping through limiting routing information is an operations issue,
removing them will not happen.
We can choose to set aside a prefix to easily identify the limited scope
addresses or not. If we don't we will have exactly the I2 case above and
no way for sorting the list of possibilitie. If we put them all in a
well-known prefix, the public net can use that in the bogon filter, and
any app that chooses to look might decide one or the other type is most
likely to work for its purposes.
Tony