[RRG] APT: no need for islands?

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

Short version:    Use tunnels between APT networks which have no
                  direct BGP physical links to carry the APT
                  mapping information with a BGP link over the
                  tunnel - but don't use this link for
                  traffic packets.  Then there is a low cost
                  method by which isolated networks can join any APT
                  island.  So for no significant extra cost there
                  can be a single APT "island" for the entire Net.

                  Ensuring there is a single global APT system
                  would overcome a major objection to APT as
                  currently defined: that there is an effective
                  limit with IPv4 on the smallest size of
                  end user networks which have full freedom to
                  use any APT ETR: no end-user prefix can be
                  longer than /24.


Some of the problems I perceive with APT relate to the concept of
islands.  For instance, if there are two islands, both are
restricted by the current (and likely to remain) /24 limit of the
DFZ BGP system to a /24 granularity in the prefixes their ITRs
advertise, for the purpose of catching packets from networks without
ITRs.

This means that if an end-user's micronet (EID prefix) is longer
than /24, such as a /25, then it can't very well be used with APT,
since the whole /24 it is located within would need to be advertised
by ITRs at the edge of the island.  That would mean the rest of the
/24 couldn't be used by end-users in other APT islands.  So APT
would be messy, with end-users with /25s or longer only able to
attach their sites to ISPs in any one island.

This problem would disappear if there was no APT islands - only a
single APT system.   This assumes that all participating networks
trust each other, but they already trust each other by participating
in the Internet and using BGP.

Two substantial APT islands are shown in the diagram below.
Networks doing APT are Ax and Bx.  Networks not doing APT are Nx.


   A1---A2---A3---N1---B1---B2---B3
   |    |    |       / |    |
   A4---A5---N2---N4---N5---B4---B5
        |    |  \ |    |  /      |
        A6---A7---N6---B6---B7---B8


I was wondering how much disincentive there would be for N1 to join
both islands together.  Firstly, its routers would be the only path
for the flooding of APT mapping data, but that is a pretty light load.

I wondered whether all inter-island traffic would have to flow
through N1 - for APT-mapped address space or ordinary prefixes.
That would be a serious disincentive.  There's no reason why traffic
addressed to non APT prefixes would be confined to APT-equipped
ISPs, but what about the tunnelled packets, from ITRs in one part of
the island to ETRs in any other part?

For instance, assuming N1 does join the two islands into one, then
if an end-user network E1's ETR is connected to A6, and an ITR in B8
receives a packet addressed to that end-user's EID prefix, I
wondered whether the encapsulated packet would have to flow through N1.

It wouldn't, as far as I know, since the ITR encapsulates the packet
and sends it via the standard BGP routing system to the ETR.  In
this example, the shortest path would probably be B8, B7, B6, N6, A7
and A6.  Note the ITR to ETR traffic flows through one or more
non-APT networks.

So this means there is very little burden on N1 for joining the two
islands.

Furthermore, I think it would be possible for the two islands to be
joined perfectly well into one island, by making a tunnelled link
from A3 to B3 *not* using N1 at all.  Physical links between border
routers would not be required.

The tunnelled link would pass through whatever networks there were,
APT or not, and would carry the BGP traffic which floods APT mapping
information from all sources (ETRs?) to all destinations (Default
Mappers) in the now larger "island".  I figure this could be done
without making that tunnelled link carry any traffic packets, by
applying appropriate policy at the routers at the end of each tunnel.

Taking this further, there is no need for APT islands at all.  Even
an isolated network, with no physical links to any other APT
network, can easily (essentially zero cost) participate in an APT
island simply by making a tunnel to some other APT network which is
in the global "island".

Therefore, as far as I can see - there's no need for APT islands at all.

If so, the specification could be revised to assume all APT sites
share the flooding of APT mapping information via these no-cost,
arbitrary distance, tunnels.  Multiple such tunnels could links
widely dispersed APT networks, in addition to flowing along
conventional physical router links between peer ASes.

Then, there would be no problem using APT to slice and dice address
space very finely, down to single IPv4 addresses if desired, as
LISP, Ivip and TRRP can do.  Since there is a single global body of
APT mapping information, it would be fine for a customer with a /25
to use an ETR at any APT ISP, knowing that the ITRs of all the other
APT ISPs will have mapping for that /25.  Then, traffic packets
originating in APT networks get tunnelled directly to the
appropriate ETR, and packets from outside APT networks are attracted
to border routers which advertise the encompassing prefix (a /24 or
shorter), with each such border router acting as an ITR.

This way, APT could slice the space up into individual /32s without
any restrictions - since each end user can use any ETR in any APT
ISP.  Ivip can already do this, and so can LISP - though this is not
necessarily what its designers intend.

Allowing these lightweight tunnels for BGP flooding of APT mapping
would simplify the proposal considerably - the concept of multiple
isolated islands would not be necessary.

  - 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