Re: [RRG] Future mapping DB size, small micronets/EIDs

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

Hi Brian,

You wrote:

>> Regarding maximum length of LISP EID prefixes, you wrote:
>>
>>> I think we've had that conversation (at least, I was having it
>>> with Tony). My conclusion is that the longest prefix is
>>> undoubtedly /32 or /128, but that doesn't answer the important
>>> question of how many prefixes need to be mapped, which depends
>>> on how many sites need to be mapped and what is their size
>>> distribution.
>> While I understand the mapping data format for LISP will enable a
>> /32 IPv4 to be specified, I wonder whether it makes sense to have
>> ITRs all over the world tying to divide the IPv6 address space any
>> finer then /64.
>>
>> To allow for /128 in the data format rather than limiting it to /64
>> adds another 8 bytes to every EID record, although it is going to be
>> very long anyway, since there will be multiple 128 bit RLOC
>> addresses for the ETRs.
> 
> The EID format is going to be variable length anyway, so we could
> have three lengths: IPv4/32, IPv6/64, IPv6/128. Or make it
> completely variable length, if redundant bits are really an issue.

It clearly needs to be 32 bits for IPv4.  There could be two
different classes for IPv6, but since we need one (Ivip) or multiple
(LISP, APT & TRRP) multiple full 128 bit ETR addresses for each
mapping entry/update, having two types just to save 64 bits in many
or most cases may not be worth the trouble.  Data compression might
be able to help with long strings of zeros anyway. Alternatively the
format could have the prefix length first, and then that number of
bits - assuming the rest of them were to be zero.

>> I also think that allowing /128s will complicate the design of every
>> ITR, or at least bloat it or slow it down if someone really uses a
>> /128 EID prefix.
> 
> Certainly, but I think that we shouldn't exclude it by design. That
> would be like repeating the classful addressing error in IPv4-RFC791.

I agree.

   - 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