Hi Dave On Fri, Mar 6, 2009 at 6:24 PM, David Meyer <[email protected]> wrote: >> The ISP would still have in their RIB >> all prefixes attached to the SP's network and the RIB also need to >> carry all global RLOC identifiers. But overall the growth of the >> entries in the routers' RIB and FIB would be reduced for each AS. >> When a client resolves a destination and found out the destination IP >> address it is forwarded to the network, if the destination is not >> found in the RIB/FIB it is forwarded to the closest ITR upon the >> default route. The ITR make a lookup from the MS and once the RLOC is >> found the packets are encapsulated and forwarded to the ETR. The ETR >> updates its cache on the information in the packet. Most likely the >> ETR has to inform the adjacent MS that it is dealing with this new EID >> entry. > > I'm not sure I understand. The map-server connects to the > ALT, which of course has a RIB, but it seems you're > talking about the DFZ RIB (RLOCs and all). Which one are > you talking about?
I got a little bit carried away here... I had my first architecture (that haven't been published) in mind which is close with the MS -except that instead of a MS I had a DNS server. It got complicated and after some discussions I decided to go after the host stack instead. So I'll try to explain what I have in mind. If you have a B-RAS with a very good IP-subnetting plan in place you will have only one IP subnet on the B-RAS. So applying ITR/ETR on that B-RAS will not reduce the size of the DFZ - we are mapping a subnet/RLOC 1-to-1. Also if you have very good aggregation in place LISP will not help that much. So I thought that the RLOC should be connected to the AS (or actually an area) somehow, let say you assign a block /23 to an AS (or geographical area) and the ISP are taking its RLOC identifiers from that block for its ITR/ETR. The ITR/ETR are located in the ISP network but not necessary at the edge routers - if you have ITR/ETR on the edge routers you need a lot of IP addresses and you need to replace a lot of hardware (costs have to be covered somehow). Instead you place them on strategic places in the network so you can have several edge routers behind one ITR/ETR. And to the ALT network you just advertise on prefix, the /23 and not the individual RLOC host prefixes. This becomes a sort of super aggregate, the AS or an area is shown behind one /23 RLOC prefix. Once everything is in place you could remove the current granular distribution of prefixes, only the /23 RLOC prefixes would be exchanged between the service providers. When this is finally in place I have in my own AS only the prefixes that are connected to my network and the /23 RLOC prefixes of other service providers. When a customer makes a connection outside my AS it will not be found in the RIB of my AS, the SYN will end up in the closest ITR. If the ITR doesn't have that entry in its cache, it need to lookup it from the MS. The MS returns the RLOC identifier for that prefix to the ITR and then the ITR can add the RLOC identifier to the packet, now it can be routed to the destination. So my routers have only - lets change to PSTN lingo - the domestic numbers and the country codes to make international calls. This way the RIB and the FIB can be heavily suppressed, every AS expand on their own and will not influence on the RIB/FIB of other AS. Don't know if this matches yours design, I perhaps assumed too much here. LISP-ALT will be the global directory, which IP prefix is connected to which RLOC identifier for time being and this directory will grow but it is disconnected from the forwarding plane so the FIB doesn't need to be upgraded - only in the AS that grows too big. But that is then up to the service provider, split the AS to two AS or buy new hardware - the ISP have a choice. But this can be achieved when every ISP have moved to LISP, will it happen? > >> Then we have the exhaustion of the IPv4 address space, when that >> occurs we have to upgrade the hosts anyway and my draft is trying to >> address that issue. I'm little bit early with my proposal but now I >> can see both fitting together on a high level. Then a commercial: >> draft 01 is on its way through the process - the LSR can be removed in >> the future and also "session based" multihoming can be achieved >> without the need to implement AS border routing. > > s/Then we have/If we have/ > We can agree that we disagree on this topic :-) One question for you, how are you going to deal with portsweep on the ITR? I have seen ISP using NAT on the B-RAS (along time ago), an end user could easily saturate the NAT table so that all customer behind that B-RAS lost connectivity. I think we should design LISP and LISP-ALT so that later on the functionality can be taken to the hosts, both options are needed so that the enterprise and service providers do have a choice. If the ISP charges too much the enterprise can upgrade its host or if the LISP service is cheap enough the enterprise doesn't need to upgrade the hosts Also much can be improved by going after the hosts, e.g. mobility and UDT features can be interesting for the enterprises and a good reason to upgrade. And finally I have to borrow something from a paper RJ Atkinson brought to the rrg list, IMHO, wise words -- patte http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf Regrettably, most current applications have been built around the assumption that IP addresses and ports do not change during a session – an assumption that was reasonable in the era of the static Internet. However, we believe that the end-to-end principle, which implicitly requires changes to be made at the end hosts, has repeatedly proven itself as the guardian of evolvability through openness [13]. The reliance on an overlay network is a logical step in facilitating the development of new technology but is an indication of the immaturity of that technology. As the technology matures and becomes more widely used, we believe that its natural home lies in the endpoints in common with similar technologies _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
