RE: [RRG] Consensus check: mapping granularity

[Sheng Jiang <shengjiang@huawei.com>]

*> >>> The identifier to locator mapping function should support mapping
*> > entries
*> >>> for both host identifiers and their aggregates.
*> >> 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.
*
*i suggest to refine the requirement: one is the nature / 
*structure of the identifier itself, the other is in terms of 
*scalability ("aggregation" of identifiers), and the last one 
*in terms of ID-to-Loc mapping function.
*
*> > Hi Tony and Olivier,
*> > 
*> > Does this requirement imply that the identifier must be a
*> hierarchical label
*> > (not flat label) so as to be aggregatable?
*> 
*> I don't think that a hierarchy is necessary. 
*>
*> What is required is a mapping system that deals with blocks of 
*> identifiers and not with individual identifiers.
*
*agreed. aggregates of identifiers shall be defined though to 
*complete the initial requirement. what's relationship between 
*block & aggregate of identifiers ?

I have two points to make here:

a, we can have aggregatable identifiers and also keep part of identifiers flat at
the same time. For instance, normal identifiers are aggregatable, any identifiers
starting with 000 are flat. This design can meet special requirements too, such as
id privacy.

b, for me, aggregatable id has almost  the same meaning with hierarchical id. If an
id block is not hierarchical, it means there is no guarantee these ids are
topological together. If ids are distributed, one has to deal them individually,
then, they are not aggregatable. In another word, IDs has to be hierarchical in
order to be aggregatable. One may argue virtual aggregation mechanisms, similar to
CRIO, may be used to aggregate distributed IDs. It is true. But it is a much worse
choice only when we can not make topological aggregation. By design a new
architecture, there is no point for us to choose a worse and more complicated
solution. As a summary, hierarchy may not be necessary, but it is a better and
natural choice.

BR,

Sheng

*-d.
*> Olivier
*> 
*> --
*> http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium
*> 
*> --
*> 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
*> 
*
*--
*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
*



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