Subject: [rrg] TIDR critique

From: Robin Whittle <[email-masked]>
Date: Tue, 26 Jan 2010 14:18:55 +1100

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.