Hi Robin, thanks for taking the time to have a look on the draft! Comments inline
On Sun, Mar 1, 2009 at 6:47 AM, Robin Whittle <[email protected]> wrote: > Hi Patrick, > > While I haven't been able to understand exactly how your proposal > > http://tools.ietf.org/html/draft-frejborg-hipv4-00 > > would work, I think it could not be considered as the best approach > to the scalable routing problem for the following reasons: > > 1 - It involves extensive changes to host stacks, APIs and > applications. > > In order to be effective, such as enabling a billion or > whatever large number of multihomable end-user networks, > without causing scaling problems, the solution needs to be > very broadly accepted by most end-user networks of all types and > sizes. They will only do this if there is immediate benefit to > them (in months) and very little in the way of risks and costs. > > A primary functional benefit of the Internet is 100% reachability > of all hosts. Any proposal such as yours which involves a new > addressing system relying on host changes, means that all hosts > adopting the new addressing system will be unreachable by those > which have not upgraded their stack, API and applications. That is the characteristics of the IPv6 solution > > Therefore, your new addressing scheme would only be useful to > most users once everyone has adopted it. In the meantime, there > are only costs (actually, impossibility of having all > applications rewritten, even if you got the stacks rewritten) > and few benefits for anyone who adopts it - so it would never in > fact be adopted widely. This proposal is compatible with the current IPv4 stack, the normal applications will never be aware of the new extended IPv4 stack - it is only the raw socket applications that will need to be modified. And the new and old addressing scheme is compatible as long as the current distribution of IP prefixes are in place - once the routing information is started to get suppressed the old IPv4 stack can no longer communicate outside their AS. Within the AS we will use the legacy IPv4 stack, now and forever. The stack will be modified but the API is still the same with some extensions needed for the raw socket applications. Also if you add new features (such as mobility) to the stack you can create a demand to have it upgraded, also the OS vendors needs something to create a need for upgrades... I don't see this as a showstopper, it is all about communication. > > 2 - Likewise, for routers and ISPs. > Nope, no changes to the forwarding plane. Only adding a new element per AS. Control plane issue is not that hard to improve, similar has been done for MPLS > 3 - Your proposal doesn't help with IPv6. This would be widely > regarded as a show-stopper, on the assumption that IPv6 is > going to be the future Internet, replacing the IPv4 Internet. > > I am not convinced this is going to happen at all, or any time > soon, but for most people in this field, any scalable routing and > addressing solution must also have a solution for IPv6. I am > working on solutions for both IPv4 and IPv6. I think IPv6 > is likely to achieve significant adoption, at least for cellphone > systems, in the next decade. > > The architectures used by the core-edge separation schemes LISP, APT, > Ivip and TRRP could all work for both IPv4 and IPv6, without > requiring host changes, while supporting packets from non-upgraded > networks, without creating any new address spaces. They convert > parts of the existing IP address space into a special kind, which I > call "Scalable PI" space, which is highly suitable for end-user > networks needing multihoming, inbound TE and portability between ISPs. > True, but it makes it difficult to implement and harder to maintain If we look around a little bit on other systems they have more than one dimension to find a destination. PSTN, they have a hierarchical numbering structure in place - country code and subscriber number. But also the mail system, if I need to send you a packet I have to put street address, city and country on the label. If the mail system would use a flat addressing scheme we should change all street addresses to be globally unique - it is doable since we could mix the letters and numbers so that every street has its own name. Good for computers but human mind just flip with such approach. This core-edge separation is like having the post office to fill in the final addresses for you, why can't I do it myself since I can lookup the final address if the addressing structure supports that??? And if you don't know the address you probably can get the longitude and latitude values so you can put that in your GPS in order to get to the final destination. In today's Internet we have only longitude available, thus we have these problems - we are living in flat world and the only thing we think is behind the horizon is the edge and once we are close enough we will fall of that cliff. Adding latitude and we get the following. When I need to contact a server in Sydney the DNS tells me that the server is located in an AS with certain RLOC identifier. Here in Finland I don't need to know anything about the Australian prefixes, I just need to know the Australian RLOC identifier (and the Finnish prefixes). I put the AU RLOC as the destination IP address, send the packet towards Sydney and once the packet is arriving at Sydney the packet just need to get swapped with a new destination IP address (that has been carried with the LISP header) so that the packet gets routed upon the prefixes in Sydney's local RIB/FIB. There is nothing wrong with the routing architecture, it is the addressing scheme that is broken. > > I have had some thoughts about creating a new (third . . . ) Internet > using a 64 bit address space built by extending IPv4 IP addresses > into a gateway for another 2^32 addresses in the new system. > However, I think there are probably as many problems changing the > world over to such a new network as there are changing the world over > to IPv6. > > You wrote: > >> I do have a presentation available, but lacking a FTP server resource > > I can provide a stable home for it and any other material you have > under some directory such as http://www.firstpr.com.au/ip/xxx/ . I'll send you the presentation, it is easier to follow how the packet is routed between AS and also the issues that arises. Thanks! And we can get rid of the LSR in very long term, once the forwarding plane is upgraded. The new forwarding plane needs to do the following: if the destination IP address matches the local RLOC the forwarder must move the pointer to the EID field of the LISP header and forward instead on that IP address. But it requires that the following routers supports this functionality and also that the stack is aware of this kind of possibility. This is very very very long term...Not sure if I add this to the draft, have to think about it for a while... -- patte > > - Robin > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
