Hi Bill, Regarding my comments on your second draft:
http://bill.herrin.us/network/rrgarchitectures.html you wrote: >> 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 > > For the moment I'm arguing that these are compatibility differences in > A4. Functionally (architecturally) adding an RLOC is adding an RLOC > whether its filling in a field in the packet, adding a label to the > front of the packet, encapsulating the packet into another which > contains the RLOC or temporarily and symmetrically swapping out part > of the address. OK. >> A1c doesn't quite fit either, since ISPs will probably have more than >> one block of space they use for RLOCs. Maybe: > > Is there an important architectural distinction between one > disaggregatable block and many blocks? If not, my inclination is to > leave this alone and say that IVIP "approximately" fits A1c. Maybe > I'll weaken the language a bit and say it "has an aggregated set of > RLOCs" instead of "has one aggregated set of RLOCs." Yes, I think it is best to describe it in a way which indicates one or a low number of blocks, rather than exactly one. >> 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. [...] > > My inclination is that if it's a full push to any of the map servers > then its a full push system. After all, leaf nodes in the existing BGP > system can discard distant routes in favor of a default saving quite a > bit of space in the router as things are now. Yet we still reasonably > consider BGP to be a full push system. > > I'm open to arguments why that viewpoint is wrong. I have described APT and Ivip as "hybrid push-pull" systems, and I think this is an important distinction from the "full push" of LISP-NERD. Here is my understanding of the 3 options so far: A2a. GUIDs statically mapped to each RLOC are periodically pushed towards a central or distributed registry. The full list is periodically downloaded to the encoders which add RLOCs to the packets. I think this matches only LISP-NERD. Although the ITRs requests the download of mapping data, it is still a "full push" system, since the mapping distribution system ensures that the full database is sent to every ITR. A2b. 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 encoders which add RLOCs to the packets. I think this doesn't match any of the proposals so far. A2c. GUIDs dynamically mapped to each RLOC are pushed towards a central or distributed registry as they change. Encoders request and briefly cache individual mappings from the registry as needed. I think this matches LISP-ALT and TRRP. Six-One Router has no specific mapping distribution system yet. I think APT and Ivip have an architecturally similar arrangement and that it would be good to add something like the A2d paragraph I suggested. The last paragraph could be chopped. >> 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. > > The minimum preference you can give an RLOC is "remove". ;) > > I'll change A3b to "destination host or set of hosts" to reflect > single-eid maps, prefix-based maps and arbitrary ranges of eids as > IVIP uses. OK, but A3b still doesn't describe Ivip at all. A3a and A3b both refer to changes to how the ITR chooses which RLOC to apply according to reachability failures which have in fact been detected by some means. Both involve an EID having multiple RLOCs and each RLOC having a particular preference. Ivip doesn't have multiple RLOCs - it only has one - so there are no preferences. A3a refers to the ITR detecting a reachability problem between itself and the ETR, and then deciding that this this high preference RLOC address appears to be useless at present, that it will instead use whichever other RLOC has the next highest preference. A3b seems to be a description of how an ETR tells the ITR that it can't reach some or all of the end-user network, so that the ITR should do as described above. However, I think that the current description is confusing, since: cause a dynamic change to the address-RLOC map, depreferencing the affected RLOC. is too terse. I think it needs to be clear that the ETR is not altering the mapping, but is sending a message back to the ITR that this ETR's RLOC should no longer be chosen - allowing the ITR to hopefully choose another one from the two or more RLOCs which are typically specified in the mapping. Below is an attempt at rewriting it. Part of the trouble, I think, is that in your attempt to be terse you haven't got a term for the ETR. The terms "ITR" and "ETR" are fine for LISP, APT (if the Default Mapper is counted as a type of ITR), Ivip and TRRP. Six-One Router calls them both "Translation Routers" I think. Does "tunnel" imply encapsulation? If so, then Ivip's forwarding approaches are not really tunnels. Still, I will use "ITR" and "ETR" because it is compatible with the other schemes and nutty to invent a new name for no really good purpose. Maybe if Christian Vogt could rename his routers "Ingress Translation Routers" and "Egress Translation Routers" we could all use the same acronyms! Here is an attempt at rewriting A3b. I need to use "ETR". A3b. Link failures which prevent parts of the RLOC's network from reaching a destination host it serves are detected by the ETR, which sends a message to the one or more encoders (ITRs) which are sending it packets, to cause those encoders to dynamically change how they choose which RLOC to use for this EID. The mapping information has a list of RLOCs with preferences, and the encoder would typically choose the next highest preference RLOC instead. I think something like my suggested A3c is required to describe Ivip, which operates on very different principles to the other schemes in terms of how failures are detected, and how the ITR behaviour is changed. Here is is again: 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. > > Then in IVIP the preference ranking for an ETR is "yes" or "not present." I think it is confusing to try to shoehorn Ivip into a set of descriptions which are suitable for the other schemes, which involve preferences. Ivip has no preferences because it specifies only a single RLOC for each EID. >> 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. > > "Come to think of it, you can't get there from here." - from "Which > way to Millinocket" > > I don't know how to intelligently address the deployment issue from > anarchitectural standpoint rather than a specific design standpoint. > It may not fit as an architectural issue beyond noting that any > non-optional changes to the architecture present a deployment problem. > I'm open to suggestions. I do not regard OITRDs or PTRs as merely a question of "deployment". That would be true only if we assume that the "deployment" phase is a transitory one which will come to an end when every last end-user network gets Religion and deploys ITRs in its own network. I see OITRDs and PTRs as a lasting part of the system - a vital part of the architecture - since I think it is unrealistic to assume all end-user networks will ever install ITRs. A4 at present covers PMTUD questions and whether there is to be a fundamentally new protocol or not. A4e also seems to describe Six-One Router's approach, which only works for IPv6. So perhaps the A4 material needs to be split into multiple questions: Is there a new protocol to replace IPv4 or IPv6? Is there a modified form of IPv4 or IPv6? How to deal with PMTUD problems, which result from encapsulation by a device other than the sending host. How to ensure adoptors of the new kind of address space have all their incoming packets handled fully for multihoming, TE and portability, despite them being sent from non-upgraded networks. For the last question, I think that Ivip's OITRDs and LISP's PTRs do much the same thing. Here is a description: APT, as currently defined, can advertise prefixes into BGP to achieve much the same result, but due to the current (and likely to remain) /24 administrative limit on IPv4 BGP propagation of routes, it can only work if the EID prefix is /24 or shorter. This is assuming there are multiple APT islands. If APT is changed so all ISPs link, via tunnels rather than direct router-to-router links, to share mapping data and so make a single global APT island, then APT perform the same task as OITRDs and PTRs, with some or all border routers of participating ISPs acting as OITRDs and tunneling packets directly to the ETRs, including across the DFZ - irrespective of the size of the EID prefix. Your TRRP approach: http://bill.herrin.us/network/trrp-implementation.html seems to be a Heath Robinson affair with 8 Carrots and 6 Sticks. That could be tricky to condense into a paragraph, but it needs to be done because it is architecturally distinct from the other approaches. I think Six-One Router doesn't have a way of coping with packets sent from non-upgraded networks. >> 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. >> I think Strategy C is completely impractical. > > You may be right. Nevertheless, I want to enumerate it as a strategy a > least until we have a strong consensus that we can't possibly build a > successful protocol that way. If nothing else, doing so will save us > from, "Why didn't you consider?" questions later on. Or at least arm > us with good answers. :) Yes, I agree. No-one is suggesting that SHIM6 is a solution. I guess this is covered by your initial description of being "resolutely rejected": http://www.irtf.org/pipermail/rrg/2008-November/000127.html Ran Atkinson and Steven Blake attest that ILNP is practical - but I don't know of anyone else who does. We have little consensus. I would have thought that the idea of changing all hosts and applications to solve the routing scaling problem would be resolutely rejected, but apparently not. See my previous message and some earlier ones for why I think a host-based solution is a can of worms. LISP, APT, Ivip, TRRP and Six-One Router seem to be based on the assumption that it is easier and/or better to add something to the routing system than to change all hosts so they need to be concerned with coping with changes in addresses of other hosts and/or with changes in connectivity in the routing system. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
