Re: [RRG] Text proposal: mapping granularity

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

Hi Tony,

Here are a few potential improvements to your draft text:

> 3.1.1.  Granularity
> 
>    The granularity of the mapping function controls the specificity of
>    the entries that make up the map.  Mapping large blocks of
>    identifiers to a common set of locators is highly efficient because
>    it reduces the amount of information needed in the mapping function,
>    but it sacrifices the ability for the mapping function to support
>    more specific information, at the expense of scalability.  Shifting
>    the scalability problem from today's routing protocols and forwarding
>    plane to tomorrow's mapping function simply moves the problem.  Thus,
>    any mapping solution that is going to have detailed granularity must
>    also have commensurate scaling properties.

A more thorough version of the last sentence might be:

     Thus, any mapping solution which can support more detailed
     granularity is in principle capable of supporting a separate
     mapping for every host identifier in the address space.  Since
     different mapping solutions have different practical upper
     limits on the number of mappings they can support, the ability
     of a mapping system to support individual host identifier
     granularity does not imply that a practical implementation
     could necessarily cope with such a large number of mappings.

This is a general discussion section, but the recommendation is that
the finally chosen mapping system will support individual IPv4/6
addresses (host identifiers).  Therefore, the astute reader will
note that the proposed mapping system is not required to support as
many mappings as there are IP addresses.

> 3.1.1.1.  Recommendation
> 
>    The identifier to locator mapping function should support mapping
>    entries for both host identifiers and their aggregates.

I suggest that "should" be replaced by "must".


I think there needs to be some clearer definition of "aggregate".

I figure most people accept that:

   12.34.56.0/32 is not an aggregate.

   12.34.56.0/31 is an aggregate.

   12.34.56.0/24 is an aggregate.

but would everyone agree that:

   12.34.56.1/24

is an aggregate?

Does "aggregate" imply the starting point have all zeroes to the
right of the prefix length number of bits to the left?


If aggregate means an arbitrary length of contiguous address space,
from any starting point, then I will be perfectly happy - but I
think most people see it as some starting point with a prefix length.


Do we need to say anything about how the system is designed to
optimise performance, for instance in terms of data compactness in
the mapping messages (both push and pull)?

Maybe not, but here are some thoughts on data compactness anyway:

Using 4 bytes for an IPv4 address plus 1 byte for the prefix length
is the obvious way of specifying any "aggregate" or single IP
address.  For Ivip I would use 4 bytes for the starting point and 3
bytes for the length, because I want very flexible micronet sizes,
so there is the greatest possible flexibility for slicing and dicing
the IPv4 space.

For IPv6, space is plentiful and I would probably stick with the
traditional prefix method of determining the length, and enforce the
starting point to have zeroes to the right of the prefix length
number of bits on the left.

With IPv6, there are two obvious ways of tackling this:

    8 + 1 bytes for IPv6 with /64 resolution and a prefix length

   16 + 1 bytes for IPv6 with /64 resolution and a prefix length

I intend Ivip to be optimised for the 8 + 1 bytes arrangement, with
the protocol being capable of supporting 16 + 1, but with this
option not used in general.  It could be implemented in the future
if it ever becomes worth the trouble, which I suspect it won't.

  - 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