Re: [RRG] Consensus check: mapping granularity

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

Hi Olivier,

I understand from what you wrote:

> For scalability reasons, I would propose to define this requirement as
> follows :
> 
> The identifier to locator mapping function MUST support mapping entries
> for aggregates of identifiers. It MAY also support mapping entries for
> host identifiers.
> 
> My reasoning is that to be scalable, a mapping system must deal with
> aggregates. However, some devices, perhaps for some destinations may
> request or agree to receive map entries for host identifiers. Mapping
> individual host identifiers is clearly not scalable and should only be
> an option while the default should be to map aggregates.

I don't understand what the problem is with having one, many, or
most EID prefixes (LISP) or micronets (Ivip) being a single IPv4
address.

I think that with IPv4, more and more end-users will have smaller
and smaller chunks of space - many of them will be happy with a
single IP address.  Likewise, the only scenario where billions of
end-users each want their own address space is mobile phones /
computers.  Virtually all those users would be happy with a single
IPv4 address or a /64 in IPv6.

Nor do I see a problem with many EID prefixes / micronets being /48s
or /64s in IPv6.  I think it would be a bit nutty having ITRs having
to trawl through 128 bits, but I think the protocol by which the
mapping is sent (push or pull) should be able to accommodate
individual IPv6 addresses.

That is what we are discussing, isn't it?  The characteristics of
the protocol by which the mapping system communicates EID prefix /
micronet details to whatever requests them, along with the mapping
for that EID prefix / micronet.

What happens inside the mapping database - centralised or
distributed - is a private matter for whoever implements it.  The
innards of the mapping database storage system does not need to be
standardised.

I don't see any scaling problem with how the EIDs or micronets are
defined.  All I see is some efficiency and flexibility issues.  The
following examples assume IPv4.

One way is to have 32 bits for the base address and 5 bits for the
prefix length.  That is nice and compact - 5 bytes.

Ivip would use 32 bits for the base address and probably 24 bits for
the length.  That is 7 bytes rather than 5, but enables arbitrary
lengths of micronets.  Since IPv4 space is so precious, I think
these 2 extra bytes would be a good price to pay for the benefit of
more flexible slicing and dicing.

Your specification doesn't enable me to construct examples of what
you want in terms of bits and bytes to represent a micronet.  Could
you give some examples?

For instance, 3.4.5.0/31 is an aggregate, but takes no less bits to
specify than 3.4.5.0/32.

If your proposal is not motivated by compactness of representation
of the EID prefix's starting and ending point, then what is your goal?

Your statement:

> My reasoning is that to be scalable, a mapping system must deal
> with aggregates.

doesn't convey to me why you believe that being able to specify
individual IP addresses presents a scaling problem.

Surely you don't mean that you assume a mapping system can only have
a certain number of entries, and that to cover the address space
with this limited number of entries, most of them must cover a large
number of IP addresses?

One of the major benefits of ALT (actually, the only one, I think)
is that it can have endless divisions of the address space, without
burdening the ITRs, since they only cache whatever mapping they need
at the time.  So there's no scaling problem due to the number of
EIDs in terms of the ITRs or the conceptual nature of the ALT system
- you just add more ETRs and/or more storage capacity in these ETRs.

 - 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