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

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

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:

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


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

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.


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

> So what I see in this message is terminology we don't need and a
> 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


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