Excerpts from Brian E Carpenter on Mon, Jan 05, 2009 09:39:31AM +1300: > > Strategy B: There are no properly documented proposals. > > > > > ILNP may be a Strategy B approach but it is not > > properly documented as a scalable routing > > solution. There is no Summary and Analysis in the > > RRG wiki. > > It's unclear to me that ILNP belongs in B since it has > characteristics of A as well. Whether it's jumped through the hoops > of the wiki strikes me as uninteresting; it seems to be well > documented.
ILNP has multiple modes of operation. One shouldn't be cataloging entire "packages" because many of them cross taxonomic lines. If you must talk in terms of packages, allow a package to be in more than one category. > > HIP has been mentioned, but no-one seems to be > > proposing it as a scalable routing solution. > > I think Pekka observed that this wasn't even a goal. It's not one of HIP's goals, but HIP can help create a routing solution by making it possible for locators to be assigned hierarchically. > (My quick answer > is that it only becomes a routing solution if it solves the same > mapping problem that strategy A generates.) I don't understand this. Strategy A's "mapping problem" is to find a mapping from a locally-routed locator to a (more) globally-routed one. Perhaps what you're saying is that we need a mapping from HIP identifier to locator? If so, I don't believe that's true. If I, a session initiator, am starting from scratch, I could look up both your location and your HI in parallel, or I could connect to you and discover your HI during authentication, and so on. > But I fully agree: strategy B == IPv6. If identity is based in transport-layer-or-above, as in Trilogy multipath, you can have a "B" that could work with IPv4 or v6 (even both simultaneously). > > Also, I argue that any approach which involves pushing > > responsibilities and management traffic to all hosts (all > > potential Strategy B approaches) is fundamentally flawed: > > > > http://www.irtf.org/pipermail/rrg/2008-November/000233.html > > Highly distributed = scaleable. And in any cases, hosts have always > been responsible for traffic management (that's called TCP) and > approaches like SCTP and the proposed multipath TCP extend that. So > I don't think we should condemn this in the abstract. One of the places we clearly get into trouble pushing responsibility to endpoints is path selection (with or without failures). First you may get a lot more control traffic. Second, endpoint activities can be at odds with SP activities -- each optimizing for the same thing differently. See previous discussion. > Exactly. Which is why my preference is to recommend development work > on strategy A and continued R&D on strategy B; I'd be very concerned > if we shrugged our shoulders and dropped it for 12 years. +1 on that. Scott _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
