[RRG] Micronet & MAB terminology; MAB sizes and Ivip flexibility

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

In order to make discussion of ITR-ETR schemes easier and clearer, I
suggest we adopt two terms:

Micronet

   Following Bill Herrin's use of this term, this is a block
   of addresses which have a single entry in the mapping
   database, and are either tunneled to a single ETR, or
   for which there is one body of mapping information regarding
   multiple ETRs, with different priorities.

   I Googled "micronet" and found only a few generic and low-key
   tradename uses of the word.  I think it is ripe for repurposing!


MAB - Mapped Address Block

   (Google finds only about 5 instances of this phrase outside
    the ITR-ETR discussion.)

   This is a contiguous subset of the total address space which is
   managed by the ITR-ETR system.  In LISP (as originally conceived)
   and in eFIT-APT, addresses within the MAB are no longer handled
   by the global BGP system.  Likewise, I think, in TRRP as
   originally conceived.  However, as I noted in:

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

   LISP-CONS and LISP-NERD may now involve MAB addresses being
   advertised in BGP to support connectivity from non-upgraded
   networks.

   The distinguishing feature of a MAB is that the ITR-ETR scheme
   maintains a database for this range of addresses, so that
   ITRs can be told one or more ETR addresses for each
   address in the range, or more likely one or more micronets within
   the MAB.

   The entire ITR-ETR scheme could work with a single MAB, but
   I think that in general these schemes involve multiple MABs
   of various sizes, with the number growing as the scheme is
   adopted and more organisations (RIRs, ISPs and/or end-users)
   devote their address space to be managed by the ITR-ETR system.

   A MAB may typically have its entire space divided into micronets,
   but perhaps - or frequently - MABs would have parts of their
   address range not yet assigned to a micronet.  Mapping data for
   those addresses would indicate that there was no ETR to which
   packets should be sent.


Typically, but not necessarily, MABs and micronets are prefixes.  If
they are defined as prefixes, they may or may not fall on "binary
boundaries".  Is there a better term for this?

  11.22.32.00/23 } are on "binary boundaries".
  11.22.33.00/24 }

  11.22.33.00/23 is not, because this 512 address range
  does not start on an integer multiple of 512.

In IPv4, MABs are likely to be at least 256 addresses long, since
this is currently the smallest range of addresses which can be
either removed from the BGP system, or handled as a unit by it.
(I understand there is no formal definition of this /24 limit on the
advertisements BGP routers are typically configured to accept, but I
think it is a restriction which is likely to endure for a long time.)

In IPv4, micronets can be as short as a single IP address.  In Ivip,
there is no necessity of specifying a micronet as a prefix - it can
be specified simply as a start address and a range.

I think with the other proposals, the micronet is specified as a
prefix, including down to a /32 single IP address.

A MAB might contain a single micronet of the same size - that is the
entire MAB is mapped as a single micronet to one ETR (or to a list
of prioritized ETRs).

More likely, a MAB contains two or more - perhaps many more -
micronets.  An IPv4 /8 has 16,777,216 IP addresses, so in principle
it could contain this many single IP address micronets.

I intend that in general an IMAB (Ivip Mapped Address Block) be used
to serve the needs of many end-user networks, each with its own
micronet.  The other proposals could be used this way too - but it
is a formal aim of Ivip.

It would be possible to merge two MABs.  For instance if there was
initially one MAB:

   11.22.0.0/16

and then a second in a neighbouring block:

   11.23.0.0/16

then the two could be fused together to form a larger MAB:

   11.22.0.0/15

This would probably only make sense if the mapping information for
the two /16s MABs came from the same source.  Assuming there were
multiple databases, with the two /16 MABs controlled by different
databases, then it would be best to regard them as two separate
MABs, even though they are contiguous.


From the point of view of reducing the number of BGP advertisements,
it would make sense to merge neighbouring MABs into larger and less
numerous MABs.  However, with Ivip, which involves a stream of
mapping data composed of sub-streams from multiple RUASes (Root
Update Authorisation Servers), I think each separate MAB needs to be
controlled by a single RUAS.

Unless there was a merging of RUASes, it would be likely that even
if a complete /8 was controlled by Ivip, that it would be made up of
multiple adjacent MABs, of probably various sizes, such as /10 to
/16 (although in principle a MAB could be as small as /24).

This means more BGP advertisements - each IMAB has its own BGP
advertisement - but it provides more flexibility.  For instance, if
it was desired to load-split the task of an ITRD into two ITRDs, one
ITRD could advertise a subset of all MABs and the other could
advertise the remainder.  The fewer MABs there were, and the larger
they were, the less flexibility there would be for this sort of load
splitting.

Also, when introducing new address space to the ITR-ETR system, I
guess it would be helpful to be able to add it in small increments -
each new addition would be a new MAB, unless it was incorporated
into a neighbouring MAB.

Furthermore, with Ivip, I plan that the mapping information for each
MAB would be covered by a periodic CRC or whatever which is
transmitted in the stream of mapping data.  If an ITRD finds that
its copy of the mapping data for this MAB is corrupt, then it might
(should? must?) stop advertising this MAB until it had downloaded a
fresh set of mapping information and successfully brought it
up-to-date, perhaps as evidenced by the data matching a subsequent
CRC check.  (Withdrawing and re-advertising causes BGP activity for
some distance around the ITR, but not for the whole world, since
there are many other ITRs also advertising this MAB.)

If MABs were really large, such as a /8 (even assuming this huge MAB
was controlled by a single RUAS) then this sort of CRC checking and
advertising - withdrawing - re-advertising procedure would be more
of a headache, as would the task of downloading a recent snapshot of
the mapping data and bringing it up to date with the updates which
were after the snapshot time.

  - 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