Re: [RRG] Text proposal: mapping granularity

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

Hi Tony,

I am happy to agree with everything you wrote:

> |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.
> 
> Seems reasonable.  Any objections?

Great!


> |>    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 hesitate to go there, as then some folks will infer that we're trying to
> use RFC 2119 standards terminology.  As we're writing an informational
> recommendation that is, by prior agreement, not standards track, that would
> be out of bounds.  Of course, "should" is also defined by 2119, but would
> hopefully not set folks off.

OK - I understand the context and "should" does the trick.


> |I think there needs to be some clearer definition of "aggregate".
> |
> |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.
> 
> How about we just rephrase it to be "contiguous blocks of identifiers"?

This would be great.  It would be brief, unambiguous and would mean
that the mapping system wasn't constrained to provide micronets (EID
prefixes) with lengths only in powers of two.


> |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)?
> 
> Not in this section.  ;-)
> 
> It sounds very much like what you're talking about is an engineering
> optimization, which shouldn't be part of our recommendation anyway.

That's fine - but maybe someone found it interesting to see how I
was thinking about the size of the micronet description on the wire.

  - 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