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

From: Robin Whittle <[email-masked]>
Date: Tue, 13 Nov 2007 13:51:06 +1100

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 [email-masked] 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

---

From: Scott Brim <[email-masked]>
Date: Tue, 13 Nov 2007 08:30:41 -0500

>    multiple ETRs, with different priorities.

- When you say "tunneled" to an ETR, what do you mean?  An ETR will
  strip a containing encapsulation and route based on the (then)
  outermost headers.  Are you saying your "micronet" always has yet
  another level of encapsulating header, between the ETR and the
  ultimate destination?  

- You are making an assumption about database organization.  It would
  be more efficient to have a single database entry, organized by EID
  prefix, with all information.  If you are positing that there might
  be a reason to have separate database entries for a single prefix
  with different priorities, please justify.  I assume "the database"
  means the authoritative information from which protocol messages are
  generated, not the protocol messages themselves or whatever other
  nodes might cache as a result of receiving those messages.

In any case I think this term is confusing and probably not helpful.
The term "microNET" implies that it describes a network.  Instead you
explain it in terms of a "block" of addresses ... which could be part
of a network or spread over several.  So already there is a gap
between what you are describing and the name you are applying.
Second, you tie that term to a particular way to organize information
about it.  Please figure out what it is you are trying to define -- a
topological arrangement, a database entry, or what.

> MAB - Mapped Address Block

... etc.  It seems like you want a new term because you want to be
able to have database entries for address ranges that span more than
one prefix.  Why not just say "address range"?

And the idea of routing on ranges instead of prefixes was discussed
for years and discarded as unnecessary.

> think it is a restriction which is likely to endure for a long time.)

Operational conventions for the use of BGP are tailored to its use in
mainline Internet routing, including the need to control rate*state.
They should not be assumed to apply to other uses of BGP -- if BGP is
used at all.

So what I see in this message is terminology we don't need and a
suggestion that was dealt with years ago.

swb

---

From: Robin Whittle <[email-masked]>
Date: Wed, 14 Nov 2007 02:15:53 +1100

Hi Scott,

Thanks for your comments.  As well as responding to your comments, I
also want to add a third term: UAB - User Address Block.  For now I
will stick with "Micronet" - but there may well be a better term for
this concept.

I want to make this terminology applicable to all the ITR-ETR
schemes, to aid discussion.  The terminology needs to allow for
certain ITR-ETR schemes to do certain things, without implying that
all or any of the schemes do this thing.

The largest, encompassing, address range is the MAB (Mapped Address
Block).  For instance, the ITR-ETR scheme handles the addresses
encompassed by these prefixes:

   11.22.0.0/16
   44.55.128.0/17
   66.128.0.0/9

Each of these is an MAB.  In practice, there could be hundreds or
thousands, but this is just a short example.

An ITR which receives a packet within any one of these prefixes will
either have mapping information for its destination address (and so
will tunnel the packet to the correct ETR) or will typically try to
get this mapping information so it can tunnel future packets with
the same destination address.  ITRs do not tunnel packets with
destination addresses outside the one or more MABs in the total
ITR-ETR system.

Addresses within the MAB are fundamentally different from ordinary
addresses, in that packets really need to be sent via the ITR-ETR
system in order to reliably get to the destination host (unless
perhaps the sending and destination address are in the same
network), since only the mapping database has the correct
information on which ETR should be used.  This depends somewhat on
how the scheme handles packets originated by hosts in the same
network as the final destination host.  With Ivip, all packets need
to go through an ITR and an ETR - but I think the other schemes
require or allow local routing systems to forward packets directly
when the destination host is in the same network.

Addresses within a MAB cannot be used for ETRs, or for various
servers on which the ITR-ETR system relies.

An end-user organisation by some means is assigned some space within
the first of these MABs.  Lets say it is 2048 addresses:

   11.22.16.0/20

I suggest the term "UAB" User Address Block for this.

Ivip doesn't enforce any structure on how addresses within a MAB are
assigned to users, so a UAB is not necessarily a prefix - but most
or all other ITR-ETR schemes may enforce the rule that each end-user
gets a prefix.

It is possible that the entire MAB might be for one end-user, in
which case the MAB has only one UAB which is the exact same prefix
as the MAB.  Generally - or as I think all these ITR-ETR schemes can
and should be used - there are likely to be multiple end-users per
MAB, so each MAB would be comprised of several, many or even
thousands of UABs.  There could also be some space between these
UABs which is not assigned to any end-user, and which has no mapping
information.

Also, the end-user may not set up the mapping information for some
of the addresses within the UAB - so that packets to those addresses
will not be tunneled by an ITR to an ETR.  Other than these
unmapped, unused, addresses, the UAB is made up of one or more
micronets.

A micronet, as previously defined, is a range of addresses
(typically a prefix, probably always a prefix for ITR-ETR schemes
other than Ivip) which all share the same mapping information, and
which are part of the same UAB.

Two micronets, of different users (in different UABs), which are
adjacent and happen to map to the same ETR or prioritized set of
ETRs do not not constitute a single micronet.

You wrote:

> - When you say "tunneled" to an ETR, what do you mean?  An ETR
>   will strip a containing encapsulation and route based on the
>   (then) outermost headers.  Are you saying your "micronet" always
>   has yet another level of encapsulating header, between the ETR
>   and the ultimate destination?

No - I meant that any packet with a destination address within the
same "micronet" will always be handled by the ITR-ETR system in the
same way: typically it will be tunneled to one ETR.  If the ITR-ETR
scheme allows the mapping data to specify a prioritized list of
ETRs, each ITR may make a different decision about which ETR to
tunnel the packet to - but all packets addressed to any address in
the same micronet are still subject to the same, single, set of
mapping instructions.  Likewise, if the ITR-ETR scheme allows the
mapping data to specify load sharing between multiple ETRs.  In all
cases, this "micronet" range of addresses is all covered by the one
set of mapping data.

Maybe "net" isn't a good part of this term, since it may imply a
physical network, when all that is meant is a small - perhaps very
small (down to 1 IP address for IPv4, or perhaps to /64 for IPv6?) -
subnet of address space.

The fact that this definition doesn't imply that the micronet range
of addresses is a prefix does not at all preclude it being used for
an ITR-ETR scheme in which all micronets are defined as prefixes.
Likewise, the fact that the "micronet" definition allows for it
being as little as one IPv4 IP address doesn't mean that there is
any requirement for any or all ITR-ETR schemes to handle mapping for
such small increments of address space.

> - You are making an assumption about database organization.

I am trying to create an inclusive term which doesn't assume
anything about the database organisation.

>   It would be more efficient to have a single database entry,
>   organized by EID prefix, with all information.  If you are
>   positing that there might be a reason to have separate database
>   entries for a single prefix with different priorities, please
>   justify.  I assume "the database"  means the authoritative
>   information from which protocol messages are generated, not the
>   protocol messages themselves or whatever other nodes might cache
>   as a result of receiving those messages.

I think you probably misunderstood me.

I mean that "micronet" refers to whatever range of addresses for
which the ITR behavior is all specified by a single entry in the
mapping database.

In Ivip, that entry contains simply an ETR address, or zero.

Other ITR-ETR schemes involve more complex mapping data, including
for instance prioritized ETRs from which the ITR chooses, depending
on the ITR's impression of connectivity - and load sharing over
multiple ETRs at the same time.

So I should rewrite the definition a little.  The ", and are ..."
was meant as an example, not an extra set of conditions:

Micronet

    Following Bill Herrin's use of this term, this is a block
    of addresses which have a single entry in the mapping
    database.  This means this range of addresses is all
    controlled by one end-user and packets addressed to any address
    in this range will be treated in the same way by ITRs.
    Adjacent micronets, with identical mapping information -
    including those controlled by the same end-user - do not
    together constitute a larger micronet.

> In any case I think this term is confusing and probably not
> helpful.  The term "microNET" implies that it describes a network.
> Instead you explain it in terms of a "block" of addresses ...
> which could be part of a network or spread over several.

I accept that the term may be confusing.  It is a cute little term
which has been lazing around in a purposeless generic and tradename
limbo existence for years.  I thought we could give it some useful
work to do, for this important concept which is at the heart of
every ITR-ETR scheme.  However, there may well be a better term.  I
am trying to avoid mind-numbing acronyms - but not wanting to
overload some commonly used term with another meaning.

> So already there is a gap between what you are describing and the
> name you are applying.  Second, you tie that term to a particular
> way to organize information about it.  Please figure out what it
> is you are trying to define -- a topological arrangement, a
> database entry, or what.

I hope what I have written resolves these questions.

> able to have database entries for address ranges that span more
> than one prefix.  Why not just say "address range"?

I want "micronet" and UAB not to be constrained to binary
boundaries, prefixes etc.

I was not suggesting that an MAB be some arbitrary range of
addresses which can't be expressed as a prefix.  As far as I can
see, each MAB either needs to be excised from the BGP system, or
treated in some way different by it (such as "anycast ITRs in the
core").  Since BGP specified address space in the form of prefixes,
I think an MAB needs to be an address range which BGP can specify
just as it does advertised prefixes.

> And the idea of routing on ranges instead of prefixes was
> discussed for years and discarded as unnecessary.

I am not suggesting that ordinary BGP routers behave any
differently.  ITRs will be doing new and demanding things.

>> (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.)
>
> Operational conventions for the use of BGP are tailored to its use
> in mainline Internet routing, including the need to control
> rate*state.  They should not be assumed to apply to other uses of
> BGP -- if BGP is used at all.

I was trying to make an observation that, as far as I can see, each
MAB in IPv4 will be in increments of 256 addresses.  What I wrote
was not so clear, and perhaps gave the impression that there could
be an MAB of 257 addresses, for instance.

What I mean to say is that, unless the IPv4 BGP system changes from
its current maximum prefix length of /24 (for accepting
advertisements from other systems) that all MABs are going to be
composed of an integer number of /24s.  So MABs are going to be
address ranges just like those usually advertised in BGP today, not
things of arbitrary length.  Nor are they likely to be obtuse
prefixes such as 11.22.33.0/8, which is a prefix, but which goes all
the way to 12.22.32.255 and is not at all neat.

> suggestion that was dealt with years ago.

I think we do need some common terminology, otherwise we get someone
trying to explain, critique or discuss an ITR-ETR scheme using terms
which are very hard for most folks to understand.

Christian Vogt wrote a thoughtful critique of some difficulties he
saw with Ivip:

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

but using language which is very different from that of the Ivip ID.
 I figure he was trying to find a generalised terminology to
describe his perception of Ivip, and I think that it would be good
to have some generally agreed terms for the various divisions of
address space to avoid each person trying to invent a common set of
terms.

I hope that the three concepts exemplified here:

  MAB1 {  UAB1 [ 11.22.0.0/17      < Each of these is a "micronet"
       {       [ 11.22.128.0/18    < - though in these examples they
       {       [ 11.22.192.0/18    < are rather large.
       {
       {  UAB2 [ 11.23.0.0/24      < Two smallish "micronets".
       {       [ 11.23.1.0/24      <
       {
       {  UAB3 [ 11.23.2.0/30      < A bunch of small "micronets"
       {       [ 11.23.2.4/30      <
       {       [ 11.23.2.8/29      <
       { ...

can be defined in and open enough way as not to constrain how an
ITR-ETR scheme applies the concepts, whilst still being useful.

I do not want to get into an endless discussion such as arose on the
RAM list about how exactly to define "identifier" and "locator"!

  - Robin