On Sat, Dec 27, 2008 at 9:50 AM, Stefanos Harhalakis <[email protected]> wrote: >> http://bill.herrin.us/network/rrgarchitectures.html >> PMTUD: Strategy A describes a range of architectures which could > > There is always the possibility to add PMTU information to the routing > protocol (or something like that) like EIGRP does. As mentioned in the page, > the approach looks like a "tunneling method", so the "tunnel endpoints" can > reply with an ICMP fragm. needed when a packet of size S would be sent to a > "tunnel destination" with PMTU P with P<S (and DF bit set). This way, no > intermediate core router will ever return such an ICMP message to the end > nodes.
Hi Stefanos, That could work. It sets constraints on the placement of ITRs and ETRs... The origin of the core route can only advertise an MTU that is the smallest supported betweeen the route origin and the ETR. On the other end, the ITR would have to consult the core routing table for each ETR and it would need a routing table feed to know when the path MTU changes. It wouldn't be possible to divorce the ITR's operation from what's happening in the core. Do you think it's important to add this variant? Since I didn't hear it in the months the document was open to casual additions, I'm inclined to ask you to collect a consensus to add it late. >> 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. > > (Here I may repeat some of your words, just to make clear we see it the same > way) > > Let me split the problem to: > > a) GUID/LOC/SID separation > b) Mobility/Multihoming > c) Routing table size > > (b) depends on (a) and (c) can be greatly helped by (a), but (b) has nothing > to do with (c). I don't agree with that last statement. I believe the relationship is this: (c) is a harsh technical and economic problem that impedes the growth and improvement of the Internet. Because we didn't do (a), (b) drives (c). One approach to solving (c) is to go back and do (a). If we do (a) then (b) will no longer drive (c) so (c) will cease to be a problem. This is strategy B in a nutshell. The other six strategies recognize that going back and doing (a) at this late date will break things. So, they do a partial job of (a) (strategy A), they muck with (b) directly (strategy C) or they try to suppress (c) directly (strategy E). > Perhaps even (a) should be seen as 2 different problems (which is what some > parts of the document indirectly say): > a1) LOC - IP separation > a2) IP -> SID/GUID separation > > Isn't (a1) all that is needed for solving (c) and (a2) all that is needed for > solving (b) ? Yeah, that's more or less right. > If yes, then the problem comes to: > > a) Add LOC to Internet (core only?) to reduce routing table size > b) Add SID support to IP (either directly to the protocol or indirectly to the > TCP/IP suite) to support mobility > > Those are two different problems that can be solved in parallel. Solving them > as one seems to me like living 35 years ago and and trying to implement TCP > and IP as one (wrong?). They don't quite solve in parallel. The LOC and SID already exist; they're not new. TCP and UDP tangle the LOC in the SID. You have to untangle that in order to do something useful in either problem space. >> Our focus though, is multihoming. You'll note that the words "mobile" >> and "mobility" do not appear in the architectures summary. > > As you said eariler, most probably multihoming (for nodes) and mobility mean > the same thing. I was referring to something like this quote: > > "Link state changes in the coreward path are satisfied by renumbering instead > of rerouting". > > which I interpret as "address (GUID) change" (a.k.a. mobility) Not quite. In that case, the node's GUID is something external, another number or a DNS name. The LOC change gets pushed into the GUID map but the GUID itself remains static. The next client that tries to originate communications with the GUID finds the new LOC numbers. >> 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 > > TCP can always be extended in different ways. There is a draft [1] for > providing extra options space for TCP segments and this space may be used to > store SID. Of course TCP seems to need to be modified but we may come up with > a better solution. As you're saying, even this way, UDP will still have > problems and a solution may be incompatible with SCTP. Also bear in mind that TCP already has a SID, composed of the source and destination ports and IP addresses. If you add a SID to the options, it has to supercede the existing SID. That creates a heck of a mess with devices like firewalls which expect the original SID to be valid. What do you do when extending TCP? Drop both ports to 0 to signal that the SID is contained in the options? What then becomes the GUID and how do you map it to the LOCs? The API only has a spot for "IP address." Do you change the underlying API semantics so that the 32-bit or 128-bit number the application passes gets looked up in a GUID to LOC map instead of being used directly as the LOC? > There is always the possibility to be able to do the separation while keeping > backwards compatibility. I don't have something to propose, but (and I > believe that you'll agree) history and experience shows that at the beginning > of something like this the implementation should follow the theory and not > the reverse. (Shouldn't we think abstract?) If you don't think about compatibility at the start and you don't keep thinking about compatibility throughout the process, you rarely get compatibility at the end. If compatibility is a desirable output, you have to keep it front and center throughout. >> > 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. > > Isn't this almost impossible by definition when having multihomed nodes? With the current semantics on the IP address, yes it is. Doesn't that mean that left unaddressed, an explosion of multihoming aggravates the spoofing problem? >> 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. > > You assume here that each user / ip address will have a different route > (multihoiming+mobility ?)?. If not, then when my ISP gets a /20 IPv4 block, > those 4k addresses will mean about 2$ per person per year. Far less than what > I pay. The number becomes a lot smaller for much larger IPv6 blocks (an ISP > can have just one (lets say) /96 block). It isn't an assumption. Each time I introduce a multihomed system into the backbone, I consume at least $6000/year of router resources worldwide. That's not $6000 of my money; it's $6000 of your money. I'm taking it right out of your pocket. If you don't want me to take your money today, you have to discourage or prevent me from introducing my own multihomed system. Which is precisely what the RIRs do, and they do it so well that despite the Internet's size there are less than 30,000 multihomed systems. > Again, thanks for the introduction :-) You're welcome. 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
