[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] Text proposal: mapping granularity



% 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.
%
% 3.1.1.1.  Recommendation
%
%   The identifier to locator mapping function should support mapping
%   entries for both host identifiers and their aggregates.

The above seems to have already made some architectural assumptions.
It isn't  at all clear to me that the underlying assumptions are RG consensus
right now.

For example, in ILNP the primary mappings are forward FQDN->I and FQDN->L.;
of course there are also reverse lookups (equivalent to PTR lookups now).

However, no direct mapping I->L exists in ILNP -- because one is not needed.

The above text assumes in each case that (A) direct I->L mappings are
needed and (B) that direct I->L mappings exist and (C) the mapping
function in (B) has certain properties.

At least in the case of ILNP, all 3 of those assumptions (A, B, C) are not valid.

The simplest fix for the above text would be to insert some scoping text for
those paragraphs, perhaps starting with something like:

 "For an architecture where a direct I->L mapping is a functional
  requirement, ...

and ending with something like:

  "This section is not applicable for an architecture where a direct I->L
    mapping is not a functional requirement."

Yours,

Ran
rja@extremenetworks.com


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