Lixia Zhang wrote:
Well, what we already know is that we want our routing tokens to be
changeable. We need hierarchy in the address space to provide
scalability. We have seen that we need to form that hierarchy on the
topology,
the above seems a general statement that everyone would agree.
the real question is: are we talking about a single address hierarchy
that everyone's routing table would conform to, or somewhat different
hierarchies as viewed from different ASes...
First, 'address' is a horribly overloaded term that we should simply
excise from our discussions. We cannot have a semantically useful
conversation if we cannot have common, precise terminology.
I'm going to interpret your 'address' in the above to be purely a
routing token (a.k.a., a locator). Yes, I think we agree that we need
multiple namespaces, with at least one locator and one identifier namespace.
You _could_ have more, but it would seem to fly in the face of Occam's
razor. That said, it's not an unthinkable architecture.
So when a host changes its
position in the topology, the routing token needs to change.
I could not decipher the last sentence: when a host changes its
attachment point, its IP address changes -- do you mean routing token =
IP address?
Again, you're falling trap to the vague meaning of 'address'. Yes, when
a host changes its point of attachment, its locator needs to change.
Unfortunately, that breaks the transport connection.
depends.
there exist multiple implementations today that do not break transport
connections when host change IP addresses.
Do tell. Normal TCP will not do this.
Relevance? I have yet to see one proposal make this mistake.
Do not depend on DNS to get packet delivered.
Sorry, we already broke that. When DNS is down, the net is down. ;-)
But we still want to be able to send IP packets even when DNS is done.
Well, assuming that the end user already has the necessary bits, I have
yet to see any proposal that will not deliver the packets, even if DNS
is down. Did I miss something? With ILNP, it will revert to legacy
IPv6 semantics, which seems perfectly acceptable.
Note that all proposals are going to have issues when their mapping
system is down. Again, the real point of the original point is to avoid
the circular dependency, where you can't ever get the system up.
Again, I haven't seen anyone fall into that trap. And it applies to the
mapping system, not just DNS.
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
