Hi Bill, Here are some thoughts on your second draft:
http://bill.herrin.us/network/rrgarchitectures.html I haven't completely followed the recent discussions, and I am not trying to check your description against every proposal. My aim is mainly to comment on how well it covers Ivip and to some extent APT. The "Strategy A" section matches Ivip pretty well. The "attaches a second Remote LOC address" is neat, since it covers both encapsulation and "Forwarding": ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ as well as translation (Six/One Router). I think there need to be some options here: 1 - Encapsulation. LISP, APT, TRRP and the original Ivip. 2 - Translation. Six/One Router. 3 - Forwarding with the RLOC address, or part of it, in the existing header, as noted above. This requires upgrades to most - essentially all - DFZ routers, and probably to many or most internal routers of ISPs. There are currently two approaches: 3a: (EAF 30 bits in IPv4) Sufficient bits to uniquely identify the ETR. 3b: (PLF 19 or 20 bits in IPv6) Sufficient bits to identify the ISP, or one of multiple address ranges in the one ISP. This may be sufficient if there is a single ETR for that range. Otherwise, when the packet arrives at that ISP another lookup will be required with some other arrangement to get the packet to the correct ETR within this address block. Question A1 concerns how ISPs organise their RLOC space. None of the existing options directly describes Ivip. A1a and A1b doesn't fit, because with Ivip, ISPs can and probably will have many separate RLOC addresses (addresses on which an ETR could exist). A1c doesn't quite fit either, since ISPs will probably have more than one block of space they use for RLOCs. Maybe: A1d. Each core ISP has one or a small number of BGP-advertised prefixes which are suitable for use as RLOCs. The ETRs at these RLOC spaces may be physically within the ISP's network, and/or physically within end-user networks, but they are always accessible via one of the ISP's one or a few BGP prefixes. A2 concerns mapping. A2a is full push - LISP-NERD. A2b is probably closest to Ivip and APT. However the central or distributed registry pushes all changes in near real time to the full database query servers - QSDs -(Ivip) or Default Mappers (APT). A full database ITR is really just a caching ITR integrated with, or very close to, a QSD. In Ivip, most ITRs are caching ITRs, and they request from a nearby QSD (perhaps via intermediate caching Query Servers) whatever mapping they need. The QSDs remember the requests, and the caching time of the responses they give. If the QSD gets a changed mapping from the central / distributed registry, it pushes it to the ITR or caching query server which requested it. I think APT has similar arrangements. So it "hybrid push-pull". Ivip has a fast version of this and APT a slow version. In both cases, there is a full push of the entire mapping database to all full database query servers, which are physically close to the ITRs, but changes are only pushed in real-time from the full database query servers to the ITRs based on recent requests according to cache times. A2c is full pull - LISP-APT or TRRP. Perhaps there could be this addition to cover Ivip and APT: A2d. GUIDs dynamically mapped to each RLOC are pushed towards a central or distributed registry as they change. The registry pushes all incremental changes in near-real time to all full database query servers in ISP and/or end-user networks. The encoders (ITRs) request mapping from these local query servers. The response has a caching time and the local query server will push any changed mapping to an encoder if it receives such a change for mapping which matches a recent query which is still within its caching time. There may be one or more full database query servers in each ISP and there may be one or more layers of caching query servers between these and the encoders. Regarding how the system copes with RLOC addresses becoming unreachable, neither A3a or A3b really describe Ivip. A3a involves the ITRs determining reachability. A3b doesn't specify how the mapping is changed, and involves the concept of preferences between multiple RLOC addresses for any EID address. Ivip's mapping does not involve preferences or ITRs detecting reachability or making any other decisions. For Ivip, perhaps you could add something like: A3c. End-user networks are responsible for controlling the mapping of their EID address space. Each EID prefix - in the case of Ivip, not necessarily a prefix, since it can be one or more contiguous IPv4 addresses or IPv6 /64s - is mapped to a single RLOC address. For reasons such as a link failure, to implement inbound Traffic Engineering, or to implement address portability when moving to another ISP, the end-user network causes the mapping to change to the new RLOC address, and this is conveyed to all full database query servers in near real time. These push the changes to any encoders (ITRs) which may need them, based on previous queries and the caching times of the responses. The Ivip system - the ITRs etc. - are not involved in making any mapping decisions. The mapping has no preferences. It is up to the end-user to control their mapping for whatever purposes they desire - and there is a small fee per change. So the economics of mapping changes pays for most of the global fast push system and ensures that the costs and usage are matched. This largely avoids BGP's tragedy of the commons problem, which is at the heart of the routing scaling problem. In question A4, A4d is a good description of Ivip with encapsulation and the tricks the ITR needs to do to solve PMTUD problems: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ There seem to be no PMTUD problems with the Forwarding approaches mentioned above. I think compatibility is more than coping with PMTUD problems. I think there is also the crucial question of how the system handles packets sent by non-upgraded networks and/or hosts. Without this, the system only provides very limited benefits when few people have adopted it - so it would never become widely enough adopted to solve the routing scaling problem. Ivip's "Open ITRs in the DFZ" (OITRDs) and LISP's "Proxy Tunnel Routers) (PTRs) do much the same thing (although I think the PTR description is much less informative about how address space will be managed than with Ivip's description). So I think there needs to be a new section on this. For Ivip's OITRDs, and I guess LISP PTRs: Packets sent to EID addresses by hosts in non-upgraded networks are forwarded by those networks' routers to the DFZ. There, OITRDs/PTRs advertise prefixes which encompass large blocks of RLOC space, typically encompassing the RLOC addresses used by many end-user networks. Those OITRDs/PTRs encapsulate (or in the case of Ivip with Forwarding, convert the packet to the new format with with the RLOC address inside the existing header) the packet so it is forwarded by the DFZ routers and any internal routers to the correct ETR. Strategy B seems to cover SHIM6, ILNP and perhaps others. I believe this is 100% impractical, since it only provides benefits to adopters in proportion to how many other networks adopt it. Also, it involves host stack and probably application changes, if sessions are to survive multihoming transitions. Please see my previous message: http://www.irtf.org/pipermail/rrg/2008-November/000169.html for why I believe these approaches are of theoretical interest only. This includes some "clean slate" approach where the introduction date is so far away that people think we can ignore the difficulties of changing everyone to the new system. Whenever it happens, it is still going to be impossible. I think Strategy C is completely impractical. It involves a complete change to the routing and addressing structure which would be difficult or impossible to introduce, even if everyone agreed it was a good thing. Then there are various problems with it, not least that geography is not necessarily the most important determinant of how the Internet's routing system can be broken into local zones, for the purpose of enabling routers to work with only a local view of the Net. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
