Lixia Zhang wrote: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.
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...
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.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.
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?
Do tell. Normal TCP will not do this.
Unfortunately, that breaks the transport connection.
depends.
there exist multiple implementations today that do not break transport connections when host change IP addresses.
Sorry, we already broke that. When DNS is down, the net is down. ;-)
Relevance? I have yet to see one proposal make this mistake.
Do not depend on DNS to get packet delivered.
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.
But we still want to be able to send IP packets even when DNS is done.
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
rrg at irtf.org
http://www.irtf.org/mailman/listinfo/rrg
SCALABLE INTERNET
dykim, 09.11.18
A. Fundamentals:
o Skeletons:
o ID is global, Locator is local(private) to AS.
o Keep use of DNS, with some extension.
o TCP works on ID, IP on Loctor, Gateways(BGP) on AS #.
o Gateways advertises only AS #s, not network prefixes.
o Corollaries:
o Number space of AS is limited to 2^^16(64K) in one tier.
o AS tier recurs hierarchically, downward and upwards(or inwards and outwards). In each tier, the maximum number of ASs is limited to 2^^16.
o AS(cloud) can float within and across tiers. AS(ISP) can change is neighbor relation anytime in the course of its existence within and across the tier architecture.
o Implementation choices:
o Take IPv6 and IPv6 addresses as IDs. That is, IP addresses in the current Internet infrastructure is to be used as IDs, not anymore as locators.
o DNS is extended to serve not only name-to-address(ID) mapping but also ID-to-AS mapping.
B. Scenario of outgoing communication example:
1. DNS returns the remote (glabal) ID as well as the AS number it belongs to.
2. TCP establishes connections by use of ID.
3. TCP requests, to IP, transmission of segments with the AS number, as a parameter, of the domain where the destination peer belongs.
4a. If the target AS is local domain, IP uses a local locator to deliver the packet.
4b. If the target AS is foreign, IP uses a local locator to deliver the packet to the egress gateway(BGP) router.
5. Local gateway relays the packet to one of the next hop gateways that advertised the target AS #.
C. Scenario of incoming communication example:
(Your homework.)
D. Consequences.
o Gateway routing table doesn't explode, never exceeds 64K(2^^16).
o AS tier can recurs, theoretically, indefinitely. The whole Internet can scale to infinity.
o NAT is a norm, not an evil.
o The current IP address management infrastructure won't be abandoned. They operate exactly the same way as it does. Only that the number is now used as IDs, not for locators.
o The current DNS infrastructure is maintained, only with a bit of extension. It now has to keep database of (domain name, ID, AS number) tuples.
o Minimal disturbance to the current Internet infrastructure, with a path out for sustainable scalability.
Your comments are solicited.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.