Here is a 500 word critique of TIDR, after revisions resulting from discussing an earlier draft with Juanjo Aden.
I will send a Word file to Lixia and Tony. The Tunneled Inter-Domain Routing ID, summary and references are: http://tools.ietf.org/html/draft-adan-idr-tidr-01 http://www.ietf.org/mail-archive/web/rrg/current/msg05538.html - Robin TIDR is a Core-Edge Separation architecture from late 2006 which distributes its mapping information via BGP messages which are passed between DFZ routers. This means that TIDR cannot solve the most important goal of scalable routing - to accommodate very much larger numbers of end-user network prefixes (millions or billions) without each such prefix directly burdening every DFZ router. Messages advertising routes for TIDR-managed prefixes may be handled with lower priority, but this would only marginally reduce the workload for each DFZ router compared to handling an advertisement of a conventional PI prefix. Therefore, TIDR cannot be considered for RRG recommendation as a solution to the routing scaling problem. For a TIDR-using network to receive packets sent from any host, every BR of all ISPs must be upgraded to have the new ITR-like functionality. Furthermore, all DFZ routers would need to be altered so they accepted and correctly propagated the routes for end-user network address space, with the new LOCATOR attribute which contains the ETR address and a REMOTE-PREFERENCE value. Firstly, if they received two such advertisements with different LOCATORs, they would advertise a single route to this prefix containing both. Secondly, for end-user address space (for IPv4) to be more finely divided, the DFZ routers must propagate LOCATOR-containing advertisements for prefixes longer than /24. TIDR's ITR-like routers store the full mapping database - so there would be no delay in obtaining mapping, and therefore no significant delay in tunneling traffic packets. The TIDR ID is written as if traffic packets are classified by reference to the RIB - but routers use the FIB for this purpose, and "FIB" does not appear in the ID. TIDR does not specify a tunneling technique, leaving this to be chosen by the ETR-like function of BRs and specified as part of a second-kind of new BGP route advertised by that ETR-like BR. There is no provision for solving the PMTUD problems inherent in encapsulation-based tunneling. ITR functions must be performed by already busy routers of ISPs, rather than being distributed to other routers or to sending hosts. There is no practical support for mobility. The mapping in each end-user route advertisement includes a REMOTE-PREFERENCE for each ETR-like BR, but this used by the ITR-like functions of BRs to always select the LOCATOR with the highest value. As currently described, TIDR does not provide inbound load splitting TE. Multihoming service restoration is achieved initially by the ETR-like function of BR at the ISP whose link to the end-user network has just failed, looking up the mapping to find the next preferred ETR-like BR's address. The first ETR-like router tunnels the packets to the second ETR-like router in the other ISP. However, if the failure was caused by the first ISP itself being unreachable, then connectivity would not be restored until revised mapping (with higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the second ISP propagated across the DFZ to all ITR-like routers, or the withdrawn advertisement for the first one reaches the ITR-like router. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
