Subject: [rrg] TARA critique

From: Robin Whittle <[email-masked]>
Date: Sat, 02 Oct 2010 19:37:49 +1000

Short version:   I don't think that souping up the interdomain routing
                 system, as is proposed with TARA, is the best
                 approach.  Even if I did, and so had sufficient
                 motivation to try to understand TARA in complete
                 detail, there are many parts of the draft which
                 I think are impossible to to understand or evaluate
                 in comparison to BGP.

Hello Heiner,

Thanks for your description of TARA:

  http://tools.ietf.org/html/draft-hummel-tara-00

There are several reasons why I don't think this could be a practical
solution to the routing scaling problem.  In summary:

  1 - Unbelievable and unsupported claims about IPv4 address space.

  2 - The geographical routing arrangements do not seem to provide
      operators with the control over packet flow which they need.

  3 - It is far from clear how the whole scheme would work at all -
      since a single 40 bit TARA Locator might apply to thousands
      of TARA routers in the one square arc-second of the Earth's
      surface.

  4 - It is not at all clear how the new system would be more
      efficient than BGP.

  5 - There's no reason to believe anyone would want to adopt this
      system initially - and even if they did, it is not clear how
      the system could be developed alongside the existing system,
      eventually to replace the old system.

  6 - I find some parts of your I-D impossible to understand in any
      way which makes practical sense to me.

Whenever confronted with a document that takes more than a few minutes
to read, I and I guess many people check it out to find some reason
why we don't have to bother with it at all.  If we can find one
important part of it which we think is completely unrealistic, then we
can probably forget the whole thing as a serious concept and spend our
time on something else.  (Nonetheless, even documents containing big
mistakes or outright lunacy can have something interesting within them
- perhaps something which prompts thoughts in a novel perspective,
leading to valuable new ideas.)

Such a judgement is easy to make for your TARA I-D, based on the
following text from page 2:

   Furthermore, the IPv4 address depletion will become a non-issue,
   because global uniqueness of the IPv4 address won't be required
   anymore.  Because the destination's  IP address is not evaluated
   prior having reached  the TARA-ETR, its  uniqueness is just
   required within the local scope between TARA-ETR and egress
   router.

What is the TARA-ETR?  What is the egress router?  There's no network
diagram or overall description of how TARA works.

There's no explicit mention of IPv4 hosts requiring new stack or
application capabilities, so the reader is entitled to assume that if
TARA was deployed fully, the above statement would apply to all
existing and future IPv4 hosts - both their unchanged stacks and
unchanged application programs.

  (In section 4.1, the first option involves the sending host
   doing a DNS lookup and affixing the TARA router to its outgoing
   packets.  This implies at least a change to the stack, and perhaps
   to applications in order to ensure each application does a DNS
   lookup rather than just operating with an IP address when sending
   packets.  The second option involves completely unmodified hosts
   doing the DNS lookup, and TARA routers snooping on the reply and
   later affixing the TARA header.)

Yet the entire basis of IPv4 communications on a global basis (apart
from anycast) depends on the uniqueness of global unicast IP
addresses.  The hosts require this of the external world - the routing
system and other hosts.

No matter how you run the routing system, the only way you could make
hosts work with re-use of IPv4 addresses (the 0.0.0.0 to
223.255.255.255 range currently used as global unicast) would be to
drastically alter host protocols in some way.  That is a complete
non-starter.

Some other statements which appear wrong, or at least unsupported by
evidence, include:

  TARA will abolish the crazily excessive RIB/FIB memory consumption!

Yet there's no comparison between current requirements of a BGP router
and what would be required for a router in the same position operating
according to TARA.

  Today, a BGP-router collects millions of downstream paths . . .

Meaning routes for prefixes.  With ~330k prefixes, if the router has
four neighbors, it would get a route from each such neighbour for each
such prefix, meaning a million routes.  Many routers have more than
four neighbors.

  and yet is unable to see and utilize any upstream path - neither for
  forwarding (detour), nor for traffic load handling.  TARA will
  abolish the crazily excessive UPDATE-churn! The hereby consumed
  CPU-performance may better be used for well concerted and well
  scoped traffic load notification messages.

I think you mean a router can tell others, which are sending it
packets, that it is getting congested.

As far as I know, this idea of altering routing according to
short-term traffic flows was abandoned many years ago because it was
difficult or impossible at the time to make it stable.   I guess if
you want to do this, you would need to research it assiduously and
devise some very clever algorithms which extensive modelling indicated
would be stable.

How would "update churn" be reduce in TARA?

Broadly speaking, TARA consists of either creating a new interdomain
routing system to replace the BGP system, or progressively converting
the BGP system into something which works on totally different
principles.  You mention using BGP to convey information between
routers:  (page 3)

  By means of BGP UPDATE extensions several (e.g. 5) differently
  zoomed i.e. differently skimmed topologies of the entire internet
  will be "produced".

but I understand you mean this to occur in a different manner
than the current BGP approach of evaluating routes offered by
neighbors for a given prefix, and then choosing one to use for packet
forwarding and as the basis of a route to to offer to neighbours.

Page 7 contains the information you want one router to send to each of
its neighbours.  If that goes only to the neighbour and no further,
then that's fine.  But how do the routers collectively work together,
using just these messages, so each one develops the various maps, in
various levels of detail, for each zoom level?

>From the description around page 9 I gather that there is a concept of
"flooding" information such as mentioned on page 7 to all routers
inside a geopatch - a square degree.  But that could be a very large
number of routers.  For each such message from a router XX, some other
router ZZ in the same geopatch could have 12 neighbours and so receive
the message from each of its 12 neighbours.  Maybe this is OK if it
only needs to happen infrequently.

Key concepts of TARA include:

   Geopatch      Geographical areas covered by integer units of
                 1 degree latitude x 1 degree longitude.  This is
                 60 nautical miles on each side, at the equator:
                 111.72 x 111.72 = 12,481 square km.

   TARA Locator  40 bits encoding of geographical location, in
                 units of degrees, minutes and seconds.

                 At the equator, 1 arc-second is 30.8 metres.

                 Still, that is enough to enclose an entire
                 multi-storey building with thousands of unique
                 end-user hosts, routers and other devices.

The section "3. TARA Concept" describes a complete topologically
detailed map of all router connections in the interdomain routing
system (I think this is the case, meaning the routers which are
currently BGP routers - not including routers inside end-user networks).

Any one router knows the full detail of topology in its "local area",
however defined, and has less and less detailed maps of progressively
larger areas, with itself in the middle of each area.   The highest
level area is one with the lowest detail - some kind of summary,
without detail, of the topology of the interdomain routing system of
the entire Internet (meaning the entire IPv4 Internet, or the entire
IPv6 Internet).  That would be zoom level 5.

Zoom level 1 means a detailed map of every device (TARA routers - I
think) in the geopatch.  But a geopatch is a huge area, for instance
about 90 km west of the centre of Manhattan and about 111 km north to
south (56 x 69 miles).

I think this approach is broadly understandable because it resembles
how we use real maps of roads etc.  However, it is not so clear how
routers would use such information, even if it could be developed
collectively between them.

TARA routers (page 10) forward packets according to the 40 bit TARA
Locator in the TARA header which is affixed to all packets in the
interdomain routing system.

If the destination TARA Locator is in another geopatch, then the
router forwards it to a particular router in that geopatch.  What is
to stop many or all of the routers in the world choosing the one TARA
router for this purpose in a busy geopatch, such as the one whose
eastern boundary is in the middle of Manhattan?  That chosen router
would have to handle most of the packets arriving for any host in any
network in that geopatch.

I think these headers are affixed as the packet leaves an end-user or
ISP network, and goes to another AS.  The router which does this needs
to be able to look up the IP address in the destination field and
obtain one or more TARA locators of routers which are handling this IP
address.  I understand it does this by already having this
information, by snooping on the reply to a DNS query which was
initiated by the sending host.

So AAA is in some network NN and does a DNS lookup for the FQDN of
host BBB, which is in some other network QQ.  The DNS query is assumed
to go out of NN via some TARA equipped border router BR1, and BR1 is
then supposed to look at the reply packet, which the DNS server will
ensure contains the TARA Locators of the one or more BRs of QQ which
are ready to accept packets addressed to whichever prefix matches
AAA's IP address.

I have some concerns about this:

  1 - How can the DNS reply contain separate sets of TARA Locators
      for each of multiple IP addresses when multiple are returned
      as part of a round-robin load sharing system?

  2 - BR1 would need to be sure the reply is from a genuine DNS
      server.  For instance, an attacker inside NN could send a
      request to look up AAA's FQDN to its own malicious DNS server.
      BR1 would dutifully cache the IP address and TARA Locators
      in the reply.  But then when a host in QQ sends a packet to
      this address, BR1 will append a TARA header with one of these
      bogus TARA Locators.  For instance, at T=0, the host does
      a DNS lookup and BR1 gets the proper TARA Locators from the
      reply.  At T=1, AAA sends packets to BBB, and BR1 prepends
      them with a TARA header with the correct TARA Locator.  Then
      at T=2, the attacker does the bodgy DNS request and BR1
      reads the bogus TARA Locator for this same IP address (AAA's
      IP address) and subsequently affixes the bogus attacker's
      TARA Locator to packets sent from AAA to BBB.  So after this,
      the attacker gets the packets which should have been sent to
      BBB and can make itself an on-path attacker, at least in this
      direction.

  3 - How could you be sure that AAA would make a DNS request?
      If AAA is simply replying to a packet from BBB, it would not
      need to make any such request.

  4 - How could you be sure that the DNS request by AAA would go out
      the same BR1 that the later AAA to BBB packet would go out of,
      and how could you be sure the reply would come back through
      BR1 too?  I suspect you can't, which would mean that all
      the BRs of NN would need to share all the information they
      obtain from any DNS reply.  That is an instant scaling problem
      for larger networks, and leads to an easy DoS vulnerability:
      an attacker controlling a host in NN, or by means of
      manipulating the behavior of a host in NN, can cause a large
      number of DNS queries to go out, to legitimate or attacker-
      controlled DNS servers.  The replies can be very long, and
      the BRs of NN would be required to convey the contents of each
      reply to all the other BRs.

I wasn't able to completely follow the description of forwarding on
pages 10 and 11.  However, since you argue that this is less
burdensome than current BGP arrangements, I think you should provide
some worst-case quantitative analysis of why this is so.

I understand (page 10) that when a TARA router receives a packet whose
destination TARA Locator is not in its own geopatch, that it looks up
a pre-computed table with an entry for each of the 64,800 geopatches
and uses GRE tunneling to send the packet to another TARA router in
the destination router's geopatch.  So in addition to the TARA header,
which must be at least 40 bits long, due to the Locator being 40 bits,
there will be a GRE header as well.  But does the GRE header have a
TARA header too?  All these headers lead to serious problems with Path
MTU Discovery (PMTUD).

It is not clear how a network operator should determine the TARA
Locators of its routers if the router is physically mobile.

Also, since there could be thousands of TARA routers in the same
square arc-second, I don't understand how TARA could work at all.

In a single square second, there could be hundred or thousands of TARA
routers, operated by dozens or hundreds of separate organisations, all
with completely different positions in the actual topology of router
connections, and all with completely unrelated IP addresses.

In section 4.1, page 12, you contemplate a host adding a TARA header,
but the routers in its network not being TARA routers.  What is the
TARA header?  How could ordinary routers be expected to deal with it,
unless it begins with a conventional IPv4 or IPv6 header?  If the TARA
header begins like this, then how are TARA routers supposed to
determine that this is actually the start of a TARA header, rather
than of a normal packet?  They could only do this via traversing
deeper into the packet, which would be inordinately expensive for
every packet handled by the RIB.

You don't provide a diagram or definition of "TARA ETR", "TARA ITR" or
"TARA xTR".

The second paragraph in 4.2 is one of many which raise too many
questions in my mind to mention now.

Likewise, how can you (page 12) embed a TARA locator in a MAC address?
 MAC addresses are 48 bits and TARA locators are 40 bits.  How could
you change a MAC address when you move the device to a different place
geographically?

I will pass over 5.1 entirely.

In "5.2 Multihoming", how is the device which prepends the packet with
a TARA header meant to choose which of multiple TARA Locators to use
in that header?  There could be several, each being an ETR-like TARA
router which can forward packets to the destination end-user network,
just like LISP.  As with LISP, you need to create a way the header
appliers can decide which of these Locators to use - and that would be
based on which was reachable.  However, the TARA router at that
locator needs to be more than reachable - it also needs to be able to
deliver packets to the destination network.  The first problem is
difficult enough to solve - and I think it can't be done in a
sufficiently robust and scalable manner, with LISP or any other
approach such as TARA.  The second problem is even harder to solve, at
least with LISP, since there's no way the header applier (an ITR in
LISP) can find out in a timely, robust and scalable manner whether the
ITR can send packets to the destination network.  (These problems do
not occur in Ivip.)

Its not at all clear how TARA would do this - and it has to be the
TARA routers doing this "Locator liveness" testing, or if you have
TARA hosts adding the headers, it is the hosts which need to be doing
it.  That would present even more scaling problems than if it was only
routers doing it, since there will typically be more sending hosts
than ITR-like routers handling their outgoing packets.

I will pass over 5.3 and the rest of the draft.

I don't understand how you can use a 40 bit geographical Locator to
forward packets, since there could be thousands of ETR-like TARA
routers in the one square arc-second.

Even if you could make all this work, how can ISPs and other networks
enforce the policy they want for forwarding packets to various
neighbors, according to which prefix the destination field matches, in
a manner which is more efficient in TARA then with the current BGP
arrangements?

On page 7 you mention the Internet has 10,000 DFZ routers.  Where did
you get this figure?  In August 2007 I researched this a little and
concluded tentatively that no-one really knew how many routers there
are in the DFZ, but that the estimate of 210,000 was a minimal figure:

   Routers in DFZ - reliable figures from iPlane  August 2007:
   http://www.ietf.org/mail-archive/web/rrg/current/msg00257.html
   http://www.ietf.org/mail-archive/web/rrg/current/msg00259.html
   http://www.ietf.org/mail-archive/web/rrg/current/msg00261.html
   http://www.ietf.org/mail-archive/web/rrg/current/msg00266.html

I have only a vague understanding of much of what you describe about
TARA.  When trying to understand exactly what you mean, I think I
would need to spend many days working through the I-D sentence by
sentence, writing questions and getting you to answer them.  But I
won't try this because I believe there are fundamental objections to
any approach such as this.  See

  http://www.firstpr.com.au/ip/ivip/#recrw

for what I think should happen.

 - Robin

---

From: [email-masked]
Date: Sat, 2 Oct 2010 15:24:17 EDT

Robin, thanks for your long critique.
Find my answers inline
Heiner

In einer eMail vom 02.10.2010 11:37:52 Westeuropäische Sommerzeit schreibt  
[email-masked]:

Hello  Heiner,

Just the opposite: By advertising (typically) loose links from across  its 
network an ISP can 
propagate to the outside world a rough picture of its network - later  on 
these links may also get some policy specific  attributes.With current BGP 
this rough picture is just a single "star  node". Also: I have always despised 
AS-PATH length manipulations i.e.  adding the own AS# more than once. I 
have never been impressed by this kind of  policy routing. 

3 - It is far from clear how the whole scheme would work  at all -
since a single 40 bit TARA Locator might  apply to thousands
of TARA routers in the one square  arc-second of the Earth's
surface.
If the goal is only to eliminate the scalability problem, then it is  only 
necessary that each of the DFZ-routers has a unique  TARA-locator. 
Hereby clashes can be avoided by different means. The simplest one is  
cheating. It is sufficient that each TARA-DFZ-router within the  same 
square-degree-geopatch has a unique i.e. different  TARA-locator . It 
wouldn't matter at all if none of them had the very  correct TARA-locator wrt 
square-minute/long./ and or lat.-second !
 
If you want more, then extend the TARA-locator  e.g. 2 more  bytes - 1 byte 
to subdivide each longitude second by 256, 2 byte to subdivide  each 
latitude second by 256. Great:  then we may do TARA forwarding  from source host 
to dest.host (with both being TARA-nodes ; I haven expected  this step right 
away.
Also: It might   be reasonable to start with a 7 or even 8  bytes-sized 
TARA-locator with 3 octets being reserved for  later. 

4 - It is not at all clear how the new system would  be more
efficient than BGP.
Robin, I am talking about a new era in routing technology. You may say "I  
haven't got the clue yet", but I know at least enough about BGP so that I 
can  say "there are worlds between DV and TARA".
 
Instead of wasting another seven years, would you mind to accept an  
EXE-file from me? I can send you that exe-file which not only produces an  
ALL-LINKS-SPANNING-TREE as can be seen on my webpage, but which would also   
properly judge the inverse direction of all the shown arcs ? That  capability, 
that algorithm, is the starting point for a new era in routing  technology.

Are you sure? Imagine: Being able to retrieve the next hop 20 times faster  
without needing that sophisticated hardware which makes the today's leading 
 vendors so superior ? You don't think this could be persuasive?
The old system is terribly bad !!! Otherwise, neither Dima's hyperbolic  
mapping solution nor TARA were ever tried !

Obviously no one has taken my emails seriously over the last seven  years.
o-tone Lixia, e.g.: "I get a new algorithm from my students every  week" 

What is the TARA-ETR?  What is the egress router?   There's no network
diagram or overall description of how TARA  works.
the endpoint of TARA-forwarding. From there, forwarding will be done as of  
today.

You see, I did mention it: 1 solution which affects the hosts, 1 solution  
which doesn't.

Yet the entire basis of IPv4 communications on a global  basis (apart
from anycast) depends on the uniqueness of global unicast  IP
addresses.  The hosts require this of the external world - the  routing
system and other hosts.
I think, I mentioned that during the incremental deployment phase the IPv4  
addresses have to be 
globally unique. This means: Hurry up !

I do the same like LISP: Fuller's default mapper concept is required to  
attract packets, so that they get from a non TARA aware source host to the  
nearest TARA-router.

TARA will abolish the crazily excessive RIB/FIB memory  consumption!
Instead of a RIB with millions of paths TARA needs presumably 5 x 500  
TARA-links to be stored by any TARA-router. Instead of a growing FIB it needs  
what I called table t1 with 64800 elements, plus a table t2 with 3600 
elements  plus few tables t3 and t4 with 60 elements each.
When all routers have become TARA routers the current RIBs and FIBs shrink  
to zero.

correct

I think you mean a router can tell others, which are sending  it
packets, that it is getting congested.
What is your suggestion, in case the shortest path is blocked and the only  
alternative is via
a node which is even more remote? Would you say: sorry,packet must be  
dropped !???
Would you say this is valid forever ?

If others have failed, well this is not my fault.

Broadly speaking, TARA consists of either creating a new  interdomain
routing system to replace the BGP system, or progressively  converting
the BGP system into something which works on totally  different
principles.
Yes, of course. BGP being world-wide deployed is not a hurdle, it is a  
gift to be utilized.

You mention using BGP to convey information between
routers:  (page  3)

right.

Page  7 contains the information you want one router to send to each of
its  neighbours.  If that goes only to the neighbour and no further,
then  that's fine.  But how do the routers collectively work together,
using  just these messages, so each one develops the various maps, in
various  levels of detail, for each zoom level?
Having received the same set of TARA-links, each router is able to compute  
the same well-skimmed representative topology. What is needed are some 
rules as  to apply a specific scale ratio:
 
If there are only a few nodes in a vast desert area the scale ratio can  
even be 1:1 i.e. no skimming.

yes.

right.

Still, that is enough to enclose an entire
multi-storey building with  thousands of unique
end-user hosts, routers and other devices.
correct. But given that there are only 10 000 DFZ-routers altogether, I can 
 hardly expect more than 3600x3600=12,960,000 per square-degree-geopatch.

The section "3. TARA Concept" describes a complete  topologically
detailed map of all router connections in the interdomain  routing
system (I think this is the case, meaning the routers which  are
currently BGP routers - not including routers inside end-user  networks).
Well, it depends. Imagine a big end-user network where prefix-building is  
also a pain in the neck
and where 20 times faster forwarding is also appreciated ?!

right. In general, the TARA-links become looser and looser, the less the  
zoom.
Exception: Strict TARA-links across some hemisphere and similar ones.

Zoom  level 1 means a detailed map of every device (TARA routers - I
think) in  the geopatch.  But a geopatch is a huge area, for instance
about 90 km  west of the centre of Manhattan and about 111 km north to
south (56 x 69  miles).
First answer : yes. 
But also: Being advertised to outside from the intra-domain, such links may 
 already be loose ones, whereas distributed within the intra-domain ISP 
network  each strict link is propagated. 

I think this approach is broadly understandable because it  resembles
how we use real maps of roads etc.  However, it is not so  clear how
routers would use such information, even if it could be  developed
collectively between them.
A router has to build a single common TARA-map by combining the 5  
differently zoomed maps.
There are some difficulties involved, because a TARA-link which combines  
two differently  zoomed maps
consists of 2 parts: one from the more zoomed map, one from the less zoomed 
 map. And this is not enough: These 2 parts may vary as to support  
scrolling.

If the destination TARA Locator is  in another geopatch, then the
router forwards it to a particular router in  that geopatch.
towards a particular router in that geopatch, i.e. to the respective next  
hop router

What is
to stop many or all of the routers in the world choosing the one  TARA
router for this purpose in a busy geopatch, such as the one  whose
eastern boundary is in the middle of Manhattan?  That chosen  router
would have to handle most of the packets arriving for any host in  any
network in that geopatch.
See previous answer: the packet is forwarded to the respective next hop.  
Getting closer to the destination
the actual TARA-router would have a different closest zoomed map, and that  
one in the egress geopatch
would use three lookups in order to determine the next hop.

right.

see RFC1712.

1 - How can  the DNS reply contain separate sets of TARA Locators
for each of multiple IP addresses when multiple are returned
as part of a round-robin load sharing system?
You are welcome to contribute a solution. I have never thought of such a  
case.

I appreciate any help. Or better said: this is all up to YOU in the general 
 sense.
YOU know much better than me what is required to make a protocol  safe.

3 - How could you be sure that AAA would make a DNS  request?
If AAA is simply replying to a packet from  BBB, it would not
need to make any such  request.
All I can say: TARA needs the destination's TARA-locator. How to get it ?  
DNS-query (RFC1712) is one possibility way. There are certainly additional  
ones.

4 - How could you be sure that the DNS request by  AAA would go out
the same BR1 that the later AAA to  BBB packet would go out of,
and how could you be sure  the reply would come back through
BR1 too?   
I am open for suggestions. Exchanging a nonce ?. I am sure, there are more  
experienced folks who can take care of that.

I  suspect you can't, which would mean that all

Well, the best solution is  if the source user made the query.  Microsoft 
updates my computer every now and then anyway ( I know you like  to call this 
being a non-starter, but I disagree; that wouldn't be a  problem).

I  understand (page 10) that when a TARA router receives a packet  whose
destination TARA Locator is not in its own geopatch, that it looks  up
a pre-computed table with an entry for each of the 64,800  geopatches
and uses GRE tunneling to send the packet to another TARA router  in
the destination router's geopatch.  So in addition to the TARA  header,
which must be at least 40 bits long, due to the Locator being 40  bits,
there will be a GRE header as well.  But does the GRE header  have a
TARA header too? 
table t1, offset by the destination's square-degree# (from the resp.  
TARA-locator) will yield the next hop info:
which indicates either a strict next physical link or LSP to GRE-tunnel to  
the next TARA-router.
The GRE-header is to hide that there is something different (TARA) going  
on, i.e. is without locator.

All  these headers lead to serious problems with Path
MTU Discovery  (PMTUD).

It is not clear how a network operator should determine the  TARA
Locators of its routers if the router is physically  mobile.
Some router recognizes: I am the egress according to the provided  
dest.-TARA-locator. Next: it realizes that the destination IPv4 address is not  
"attached". It can start a broadcast search well-scoped within the same  
geopatch.

Also, since there could be thousands of TARA routers in the  same
square arc-second, I don't understand how TARA could work at  all.
This assumption is not true, if we assume: the user's TARA-locator is in  
compliance with the location of its
home-ISP's closest DFZ-router.
Again, I wouldn't oppose if 3 bytes of the TARA-locator were reserved  for 
later.

see above.

In  section 4.1, page 12, you contemplate a host adding a TARA header,
but the  routers in its network not being TARA routers.  What is the
TARA  header?  
Similar to LISP-header with locators for source AND destination !
( I can also, per party, imagine 2 locators, one armed, one disarmed which  
may be swapped eventually as to perform multipath routing, e.g. via 
multi-home  routers)

How  could ordinary routers be expected to deal with it,
unless it begins with a  conventional IPv4 or IPv6 header?  If the TARA
header begins like  this, then how are TARA routers supposed to
determine that this is actually  the start of a TARA header, rather
than of a normal packet?  They  could only do this via traversing
deeper into the packet, which would be  inordinately expensive for
every packet handled by the  RIB.
I cannot do magic things: In order to pass non-TARA-networks, I will  need 
3 nested headers:
a classic GRE-header encapsulating a TARA-header encapsulating either an  
IPv4- or IPv6-header or
e.g a (new) E.164-header without the enum mapping.

You don't provide a diagram or definition of "TARA ETR",  "TARA ITR" or
"TARA xTR".
well, this is more or less LISP-language or RRG-language.

Likewise, how can you  (page 12) embed a TARA locator in a MAC address?
MAC addresses are 48 bits  and TARA locators are 40 bits.  How could
you change a MAC address  when you move the device to a different  place
geographically?
5 octets fit into 6 octets, right? The MAC address is (should be) just  
globally unique. Just like the TARA-locator. I don't see that anyone is  
concerned that  the containing OUI really reflects the indicated  company.Hence 
any exchange with another globally unique identifier won't cause  problems.  

In "5.2 Multihoming",  how is the device which prepends the packet with
a TARA header meant to  choose which of multiple TARA Locators to use
in that header?  There  could be several, each being an ETR-like TARA
router which can forward  packets to the destination end-user network,
just like LISP.  As with  LISP, you need to create a way the header
appliers can decide which of  these Locators to use - and that would be
based on which was  reachable.  However, the TARA router at that
locator needs to be more  than reachable - it also needs to be able to
deliver packets to the  destination network.  The first problem is
difficult enough to solve -  and I think it can't be done in a
sufficiently robust and scalable manner,  with LISP or any other
approach such as TARA.  The second problem is  even harder to solve, at
least with LISP, since there's no way the header  applier (an ITR in
LISP) can find out in a timely, robust and scalable  manner whether the
ITR can send packets to the destination network.   (These problems do
not occur in Ivip.)
You fairly provide the answers yourself.Some additional bits in the  
TARA-header will do.
But compared with others: The TARA-locators are not dump numbers. They  
contain geographical orientation. 
This afternoon I had to drive my car while the navigation system was fed  
with the wrong destination. What a
crazy fight against the navi's recommendations! Now imagine, the  packets 
shall take a West-bound route from Europe to China without fighting  
permanent overruling commands between Europe and let's say San Francisco ! 

you know yourself: this is not so hot.

really? I think 10,000 was mentioned on this RRG-list by some who  know
But if 210,000 is the right figure, then I will rather make a jumpf  of joy:
 
Let's have 6 or seven zooming levels, no problem.
And   forwarding might as well be like this:
Is dest-square-degree# the same as my own one?
If no, use it to offset table t11(with 64800  elements)
If yes: Is dest-square minute# the same as my own one?
if no, use it to offset tablet12 (with 3600) elements)
else
find via t3 and t4 the right TARA-egress node within the own square-minute  
geopatch !
 
No big deal !

- Robin