On Fri, Mar 6, 2009 at 7:39 AM, Dino Farinacci <[email protected]> wrote:
> >> So now we have two ETRs and two MSes which need to be >> coordinated. The two MSes both announce the one EID prefix >> on the ALT network. Yet they are supposed to still be >> coordinated during outages. > > The 2 Map-Servers will converge into a topology that will aggregate the > site's Registered EID-prefix so we can have a smaller ALT core. Smaller > meaning, a small number of EID-prefixes needing to be stored in the core of > the ALT network. > Dino, I think the Map-Server proposal is great and I can see synergies with my hIPv4 framework proposal. Because the Map-Server is not put in the forwarding path, it is similar to a DNS solution, why can not the Map-Server contain all prefixes and their RLOC identifiers, i.e. the Map-Server would become the new DFZ and Map-Severs (MS) are tied together with BGP? The MS is decoupled from the forwarding fabric, it is more or less a database and "signaling" instance, right? A powerful server with a lot of memory should be able to deal with the RIB churn. I have also a feeling that every service provider would prefer to have their own MS and therefore the ITR/ETR of that service provider are adjacent with the MS of the ISP. 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. When a EID changes location the ETR is updating the MS and BGP is announcing to all MS the change. The MS should then flush the adjacent ITR/ETRs, if they have "subscribed" for that specific EID during the last , e.g. 24 hours. The update churn is not "flat" anymore, all MS will be influenced but not all ITR/ETR, except if they have been using the affected EID. Or have I misunderstood something? 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. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
