[RRG] Ivip end-users' dependencies

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

Hi Christian,

In message http://psg.com/lists/rrg/2007/msg00532.html you wrote
about LISP proxy and NAT systems to provide connectivity from
non-upgraded systems.  I don't understand what a LISP "proxy" or NAT
would entail in sufficient detail to comment further.

You also wrote:

> Ivip avoids the dependency on a single proxy by grouping multiple
> providers to do the proxying for redundancy.  An edge network's
> EID space is then advertised by multiple providers.

Using the MAB (Mapped Address Block), UAB (User Address Block) and
micronet terminology I proposed in:

  http://psg.com/lists/rrg/2007/msg00533.html
  http://psg.com/lists/rrg/2007/msg00535.html

I would restate this as:

   Ivip avoids the dependency on a single ITR for handling packets
   from non-upgraded networks by having multiple providers run
   multiple ITRs to attract packets from non-upgraded networks and
   to tunnel those packets to the correct ETRs.  This spreads the
   load, provides redundancy and generally reduces the path lengths.
   So an edge network's micronet is advertised in BGP by multiple
   ITRs of multiple providers, as part of a larger MAB (actually, an
   IMAB - Ivip Mapped Address Block).

> To reduce the number of routing table entries, Ivip also groups
> edge networks, and it uses one EID block per edge network group.

I think you are describing how each MAB contains one or more UABs,
each of which contains one or more micronets - and how the MAB has a
single advertisement in BGP.


> The Ivip model creates new dependencies, though:
>
> - Providers in a group are bound to other providers in the group.
> They must coordinate their BGP advertisements because a customer
> edge network of one provider is also a customer of the other
> providers in the group.

The Ivip proposal doesn't mention "groups" of ISPs.  It is assumed
that anyone who runs an ITR in "the core" (meaning it accepts
packets from the BGP routers of other ISPs and end-user networks)
does so in a way which is coordinated on a global basis, by making
sure the ITR gets a reliable feed of mapping update information, and
making it not advertise a MAB if it no longer has up-to-date mapping
information for it.

This is assuming there is a single Ivip system and all the ITRs in
the core (those which advertise MABs and so attract packets from
networks which have no ITRs, or just caching ITRCs, which can't
handle all packets with destination addresses within a MAB) handle
every MAB in the whole system.

The current Ivip-arch-00 ID assumes that each ITRD (ITR with a full
database, via a full feed of realtime updates) handles every MAB -
although it would be possible to load-split between multiple ITRDs
by having each ITRD advertise a subset of the total set of MABs.

The ID also assumes that an ITRD has the full database for all the
MAB it advertises.

Another possibility, suggested by Bill Herrin, is that a particular
ITR might have the full database (be an ITRD) for one or more MABs
but be a caching ITRC for other MABs.  This was also suggested, I
think, by Noel Chiappa, regarding regions:

  http://psg.com/lists/rrg/2007/msg00492.html

I haven't written about this, but I think any ITR which is only
caching the mapping data for a particular MAB should not advertise
this MAB.  Caching ITRs (ITRCs) are good for tunnelling packets to
ETRs when those packets are passing through them.  However, an ITRC
shouldn't pretend to be the destination for packets addressed to a
particular MAB when it is only caching the mapping for that MAB -
unless the ITRC has a reliable way of passing on the packets it has
no mapping for to an ITRD.  If an ITRC was advertising the MAB, it
would need some private tunnel arrangement to an ITRD for this
purpose, since it couldn't simply emit the packet - the packet would
simply be attracted back to the same ITRC.

> - Edge networks in a group are bound to other edge networks in
> the group because they cannot leave the group without
> renumbering.

I would say that since a MAB (or at least an IMAB, as I define it)
is a block of address space with the mapping controlled by a single
body (Root Update Authorisation Server - RUAS - in Ivip), it follows
that the end-user networks using the micronets in a single IMAB must
all depend on this RUAS.

Figure 4 at:

   http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html

shows a single RUAS receiving mapping update information from
multiple other Update Authorisation Server (UAS) companies, each of
which receives mapping updates from end-users, other UASes, or from
multihoming monitoring systems appointed by the end-users.  Each
RUAS would control the mapping of one or more IMABs.

The system need not be this complex.  An RUAS could also deal with
end-users directly, and run its own internal multihoming monitoring
system which generates mapping updates.


> - Edge networks are bound to their provider group because they
> cannot move to a provider in a different group without
> renumbering.

I think what you are referring to as a provider group is in fact the
RUAS which is authoritative for the mapping for the MAB which the
end-user's network's address space is within.

Without Ivip, there are two dependency scenarios:

1 - The end-user has PI space.  They are not bound to any ISP -
    only to the RIR who gave them the PI space.  These end-users
    can multihome, have portable address space etc.  But each
    such end-user adds an advertisement to BGP for every division
    they make of their address space.  In practice, with IPv4, the
    granularity of PI space divisions is 256 IP addresses.

2 - The end-user has no PI space, so they are bound to whatever
    single ISP they choose.  They can't do multihoming (unless they
    use SHIM6 or Six-One) and the PA address space their ISP gives
    them is not portable.  They can get as much or as little space
    as their ISP allows, without the 256 address granularity imposed
    by current (and probably persistent) IPv4 BGP practices.

    The good thing is these end-users don't add to the number of BGP
    advertisements.  The bad thing is there are a growing number of
    these folks, they are not happy.  If we don't invent a good
    multihoming and  portability scheme, they will each want and
    probably get PI space and so add one or more advertisements to
    the global BGP routing table - seriously burdening every ISP.


With Ivip (or probably the other ITR-ETR schemes if they worked
well), there is a third state an end-user network can be in:

3 - The end-user gets some address space from some organisation X
    in a MAB for which the mapping information is controlled by a
    particular RUAS organisation Y.

    The end-user also chooses one or more ISPs with ETRs, which they
    depend upon at any one time, but are not bound to.  They remain
    bound to organisation X and are also dependent on the particular
    RUAS.

    Perhaps X is an RIR, or an ISP.  Perhaps the RUAS organisation Y
    is the same as X.  Perhaps it is a specialist RUAS organisation
    or a domain name registry company.

    So this is a dependency basically on X, which either runs its
    own RUAS or chooses some other company Y to do so.

    A more complex set of dependencies would exist if the end-user
    got its address space from company C, which got it from B, which
    got it from A, which got it from X.  In that case, the end-user
    needs to look behind C to find out who else they are becoming
    dependent upon.  Of course, such complex arrangements are only
    going to exist if the relevant RIR allows address space to be
    used in this way.

    The end user can slice and dice their address space with
    complete freedom, including down to single IP addresses,
    each of which can be mapped to an ETR in any ISP the end-user
    chooses to use.  As long as the relationship with X persists,
    the address space is multihomable and portable to any ISP which
    has an ETR.  There is no extra burden on the BGP routing system
    by all this slicing and dicing, or changes to this.

I don't think that the Ivip model necessarily involves dependencies
much more problematic than those of an end-user with PI space.

Since the RUAS X has no geographic limitations, and does not involve
the end-user in any particular ISP or access network, the
dependencies in Ivip are far less onerous than those of an end-user
who has PA space at present.


   - Robin

--
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