Re: [RRG] ALT's strong aggregation often leads to *very* long paths

[Robin Whittle <rw@firstpr.com.au>]

Hi Xu,

You wrote:

>> LISP-ALT routers are deployed in a hierarchy which matches the
>> EID prefix allocation hierarchy.  LISP-ALT routers at each
>> level in the this hierarchy are responsible for aggregating all
>> EID prefixes learned from LISP-ALT routers logically "below"
>> them and advertising summary prefixes to the LISP-ALT routers
>> logically "above" them.

> Does LISP-ALT seem like a variation or a simplified instance of
> LISP-CONS? Both of them introduce a hierarchical overlay network
> which is topology-independent.

I think CONS and ALT are driven by a common goal - to build a new
network of routers in which aggregation is achieved to a very high
degree.  On the face of it, this should make the network highly
efficient - but this won't be true when the routers are physically
scattered all round the world, with their geographic location having
little or nothing to do with the prefixes they are handling.

It probably should have been clear to me that this was a problem
with CONS too.  I didn't clearly recognise this because I had too
much difficulty understanding how CONS would work anyway.


> The difference is: in LISP-CONS, the overlay network is just used
> for mapping query and reply.  While in LISP-ALT, the overlay can
> also be used for forwarding the initial traffic in order to solve
> the initial packets loss in ITR when cache missed. Is that
> correct?

This is one difference, and in principle it is a nifty thing to do
with the ALT network - sending the initial traffic packets and using
them as mapping requests.  This is the same nifty technique APT
caching ITRs use with their Default Mapper - but that APT is
practical, since the Default Mapper is local, with low delays, low
communication costs and high reliability.  APT's default mapper
tunnels the traffic packet directly to the ETR it chooses, in the
usual ITR fashion - whereas ALT is used to deliver the traffic
packet to the appropriate ETR via a probably circuitous path over
the ALT topology.

Another difference is that ALT is made from existing protocols - GRE
and BGP.  This saves defining new protocols and writing a bunch of
new software for each implementation.

Another critique of ALT (and I think CONS) is how to secure the way
ETRs advertise their EID prefixes.  How can any or all of the ALT
routers verify that some device, ostensibly the (or one of the)
authoritative ETR really is authoritative, right now, for the EID it
is advertising?

The ETR(s) chosen by the end-user will be changing from
time-to-time.  I think there needs to be some crypto and a method of
 verifying these advertisements before traffic packets are sent to
the device which advertises these EIDs.  That has to have some
degree or centralised and/or distributed coordination which I think
is not covered by the ALT ID.

The security of Ivip's mapping information depends on some crypto
protection of the multiple streams of mapping updates (and likewise
downloads of the current maps, for ITRD/QSD start-up) and on the
Root Update Authorisation Server ensuring it only accepts mapping
changes from users via an authenticated method:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-01#page-60

This makes security a lot easier.  It also completely separates the
mapping database part of the system from the ETRs, though there is
nothing to stop an end-user embedding mapping update functions in
their ETR(s), with the required username and password for accessing
the Update Authorisation Server system which handles their micronet.


>> This is presumably impossible at the edge of the network, since
>> the location of ETRs for a given EIDs are scattered around the
>> place with little or no correlation with geography.
>
> ...
>
>> By mandating the structure of the ALT network be strongly
>> driven by address aggregation, this means the connections
>> between one router and the next in the hierarchy will have
>> little or no relation to geography.  Therefore, the average
>> length of inter-router distance will be far longer than for
>> ordinary BGP routers, where the network structure is based
>> primarily on linking to geographic neighbours, and not at all
>> on address aggregation.
>
> If the overlay network is used for traffic forwarding, what you
> mentioned is inevitable.


My understanding is that the ALT network has 3 or 4 functions:

  1 - ITR sends map query.  ALT network forwards this to an
      authoritative query server, which is typically one of
      the currently active ETRs.

  2 - That ETR (or whatever responds to the query) sends the
      query back through the ALT network.  However, this is
      not required and the ID says it can be sent back
      directly to the ITR.  (The same option was added to
      CONS, or at least acknowledged as a possibility on
      the mailing list, after I questioned why the reply
      had to go back through the CONS network.)

  3 - The ITR encapsulates a traffic packet (raising PMTU
      and fragmentation problems ...) and the ALT network
      forwards it as for a mapping query.  It functions as
      a mapping query and also, ideally, gets to the ETR -
      so no traffic packets are lost.

  4 - I think there is some suggestion ("gleaning") of
      piggybacking some EID-RLOC mapping information onto
      1 or 3 above, on the basis that the ETR is (or is
      near) and ITR which will soon want to know the mapping
      of the sending host.  My understanding may be quite
      wrong.

So I don't think that ALT is unworkable only if it is used to
forward initial traffic packets.  I think it is unworkable because
it is a global query server system.  I think it is even more
unworkable because the path for queries, traffic packets and perhaps
replies would often criss-cross countries and oceans.  Living in
Australia, I know all about the latency of the Pacific Ocean, under
which most packets to the outside world travel.


> And if the usage of PI address is
> desired and encouraged, the major assumption of ALT will have not
> a leg to stand on and the things will become worse.

I think ALT is completely unviable.  I am keen for the the LISP team
respond to my critique - now beautifully illustrated by K. Sriram.

  - Robin            http://www.firstpr.com.au/ip/ivip/



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg