[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Generic requirements on mapping mechanisms
Scott,
On 3/11/08 10:15 AM, Olivier Bonaventure allegedly wrote:
1. Locators and EIDs
Locators and EIDs will be allocated by a central authority, such as
IANA or deleguates like RIPE, ARIN, APNIC, ... This central authority
is important to ensure uniqueness of the locators and of the EIDs.
s/authority/authorities/. The authorities for Locators and EIDs could
be independent,
Agreed
and different EID address families could also use
different authorities.
Agreed, but I hope that there won't be too many EID address families.
To avoid the scalability problems that we have today with interdomain
routing, the owner of the EIDs should support the cost of using small
EID sets. A possible way to ensure this would be to force the an owner
of an EID block to always reply with a mapping that is valid for the
entire block and optionnally add mappings for subsets of the EID
block, e.g. for traffic engineering purposes.
You imply that if long prefixes are "advertised", nodes other than the
owner will suffer.
If long prefixes are advertised, and the worst case are host-specific
prefixes, then other nodes may suffer depending on the mapping system.
Not necessarily -- depending on the mapping system
design.
If the design of the mapping system ensures that other nodes do not
suffer, that's fine.
Would your real requirement be that nodes not be required to
maintain the entire EID prefix set?
Another way to express the requirement could be that nodes are not
forced to use the more specific mappings that they receive. These more
specific mappings may improve the performance but they decrease
scalability and using these more specific mappings should only be an
optionnal optimisation, not the default.
4. A mapping will have a limited lifetime.
No mapping can be permament and the mapping reply should contain the
lifetime of this mapping. This is similar to the TTL in the DNS. A
long lifetime will favor scalability while a shorter lifetime will
ease traffic engineering by allowing a site to update regularly its
map replies. As for requirement 2, the cost of using short lifetimes
should be supported by the site that is using those short lifetimes,
not by the entire mapping system.
I don't know how to do that. Can you give an example?
In the case of the DNS, some of the cost of using short TTLs is
supported by the owner of the domain names with a short TTL. The
resolvers of nodes that resolve those domain names also suffer some
cost, but the nodes that do not contact these domain names do not suffer
the additional cost. In this case, there is some cost (replying to
more DNS requests) for the domain that chooses to use short lifetime.
This is not perfect since the resolvers that contact this domain also
support some cost.
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