I think a lot of my message may have confused you, because I was using the
term "name" as a generic term, in the sense of 'something used to name a
particular thing', with no particular syntax or properties.
So, 'addressesa', 'locators', 'identifiers' - they are all 'names', in the
sense I was using the term 'name'. So perhaps you could re-read my message:
http://www.ietf.org/mail-archive/web/rrg/current/msg05312.html
with that in mind, and perhaps it will make a bit more sense this time... :-)
Yes, and as we discussed earlier, everyone seems to agree that 'separation of
location and identity' is a _necessary_ part of 'solving the inter-domain
routing problem' (whatever that is :-).
> ...
> one approach seemingly getting wider support is to take separation of
> ID(host) and Locator(for routing) as the basis.
> In the endeavor, this RRG might possibly come up with a again differentExcept that LISP is an attempt to 'do' that part of the problem, in a way
> picture than what HIT and LISP drew.
that is practical, realistic, and feasible - i.e. actually likely to be
deployed and used in a widespread way. As we have discovered over the last
couple of decades, it's easy to dream up a new design - what's hard is to
come up with a design that the world actually takes up and uses.
I happen to think that the path of which LISP is a first step is the best
path, but because it does separate location and identity is only a part of
the reason I like it. To me, there are other, more important reasons I like
this path - the layer of xTRs which will hopefully grow up gives us a nice
boundary inside of which we can make changes which are not necessarily
visible to legacy hosts and site routers (e.g. deploy a new locator
namespace, deploy a new routing architecture, etc).
But I think it's a bit premature to try and design all that new stuff - and
in any case, there's no manpower for it. What I am trying to do with LISP is
make sure that it has useful 'hooks' in it to make deployment of future
pieces easier (e.g. the RLOC resolution protool can produce answers which are
in a format other than 'IPv4' or 'IPv6').
Like I said, the chief difficulty with any new architecture we come up with
is not designing the architecture - any competent architect can do that.
Coming up with a way to deploy it is the real challenge.
SCALABLE INTERNET
dykim, 09.11
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 IPv4 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 Locators are local (private) IP addresses.
o DNS is extended to serve not only name-to-address(ID) mapping but also ID-to-AS mapping.
o Mapping between AS and (local) Locator, forward as well as reverse, is done by a server(LocS) within the AS where the affected hosts or gateways belong.
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 foreign, IP uses a locator to deliver the packet to the egress gateway(BGP) router.
4b. If the target AS is local, IP uses a locator(private IP address) to deliver the packet. The target can be a local host or the ingress router into a local internal AS belonging to one lower(deeper) tier.
5. Local gateway relays the packet to one of the next hop gateways that advertised the target AS #.
C. Scenario of incoming communication example:
1. If the AS of the incoming packet is a foreign one for which the receiving AS has contracted for transit, the packet is redirected to a relevant outgoing gateway.
2. If the AS of the incoming packet is indeed local, the ingress gateway delivers the packet to the target implied by the ID imbedded in the packet. The resultant target can be a local host or an ingress router into a local internal AS beloning to one lower(deeper) tie.
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.Attachment:
scalable internet.pdf
Description: Adobe PDF document
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.