On Fri, Dec 26, 2008 at 6:07 PM, Stefanos Harhalakis <[email protected]> wrote: > On Wednesday 24 December 2008, William Herrin wrote: >> http://bill.herrin.us/network/rrgarchitectures.html > > I'm new to this list/area (so be gentle :-) and I've just read the above page.
Sure, but let me push it off into a different subject line. > I find it weird that while the title is "Routing table size problem" there is > a lot of talk about mobility (plus other things like PMTUD (?)). Even though > those are real-world problems, I see that you're trying to address them at > the same time. AFAICT from the document, this complicates things a lot. That's actually a big question. Let me offer the direct answers and ask you to tell me how to expand on them from there. PMTUD: Strategy A describes a range of architectures which could replace the routing system we have now. One common characteristic of most of the strategy A architectures is that they add information to the packets in transit, increasing the packet length. Where the endpoints are still speaking normal TCP/IP, this creates an issue with Path MTU discovery. The endpoints don't know what to do when an ICMP message comes back that the modified packet is now too large... unless you somehow intercept and translate that too. The other solution strategies don't appear to impact path MTU discovery. Mobility: The need to multihome drives the routing scalability problem. As we look at different ways of multihoming than what we do now, some kinds of mobility look a lot like multihoming. If we're disconnecting and reconnecting links in the topology graph, it might not matter that the reconnected links are in a different location than the disconnected ones. Our focus though, is multihoming. You'll note that the words "mobile" and "mobility" do not appear in the architectures summary. > For example, criticism #1 for strategy B seems only related to mobility and I > see it as a problem no matter how routing works (except perhaps from an > unknown-yet very-special case). > > From what I understand from the document, if there is ever a GUID/SID/LOC > breakup, the core routing will only deal with LOC, while the TCP (strategy B, > criticism 1) will have to do with SID. Hence criticism #1: TCP does not deal with a SID divorced from the GUID and locator, nor is it clear that there is an reasonable evolutionary change to TCP where it can construct a SID that doesn't borrow from the GUID or Locator. So, if we want to correct the design defect in the protocol suite and separate out the GUID, SID and LOC, it may not be possible to preserve compatibility with the old TCP, UDP, and the applications which use them. Compare that to most of the strategy A approaches. The GUID, SID and LOC are not separated out at all, so TCP continues to function. A new remote LOC (RLOC) is introduced that's only valid within the network core and the scalability issue is left untouched in local routing where it seems to be more tractable. By mitigating the design defect instead of correcting it, the strategy A systems preserve backwards compatibility. Most everything that uses TCP now should still work. > Also, shouldn't firewalls have to work > with GUIDs instead of LOCs ? (strategy B, criticism 2) I would think so, yes. But that's not the only way firewalls are used today. They're also used to block "spoofing" and similar attacks on the IP address that are more closely associated with the IP address's locator semantics. > for Strategy E: Assuming that managers, politics and economy will efficiently > solve a technical issue that IETF and technicians can't, seems somehow... > well... wrong... :-) We're in the rejection phase. Ask for a consensus call that we reject strategy E. > for Strategy F: 6000$ per year per prefix seems like a small amount. Then I respectfully ask you to mail me $6000. :) The premise of strategy E is that if you can bill for it, that $6k is perhaps not unreasonable as the entry fee for multihoming. The premise behind strategy F is that as an Internet user with two ISP's, I can remove $6000 from your pocket any time it pleases me to do so and you just have to deal with that as a cost of being online. Regards, Bill Herrin -- 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
