On Mon, Nov 17, 2008 at 8:24 PM, Robin Whittle <[EMAIL PROTECTED]> 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
Hi Robin, 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. > 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." > 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. > 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. 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. > 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 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. > 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. :) Regards, Bill -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
