Sriram and I had a few exchanges to clarify the picture with his
design; he also further clarified with Dino the earlier comments on
this scheme. Below is an updated critique, mostly by Sriram.
Lixia
------------------
Critique of “Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes”
This scheme (see http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf
for details) represents one approach to mapping overhead reduction,
and it is a general idea that is applicable to any proposal that
includes prefix or EID aggregation. A somewhat similar idea is also
used in Level-3 aggregation in the FIB aggregation proposal (“An
Evaluation Study of Router FIB Aggregatability,” GROW WG, IETF76).
There can be cases where deaggregation of EID prefixes occur in such
a way that bulk of an EID prefix P would be attached to one locator
(say, ETR1) while a few subprefixes under P would be attached to other
locators elsewhere (say, ETR2, ETR3, etc.). Ideally such cases should
not happen, however in reality it can happen as RIR's address
allocations are imperfect. In addition, as new IP address allocations
become harder to get, an IPv4 prefix owner might split previously
unused subprefixes of that prefix and allocate them to remote sites
(homed to other ETRs). Assuming these situations could arise in
practice, the nature of solution would be that the response from
mapping server for the coarser site would include information about
the more specifics. The solution as presented seems correct.
The proposal mentions that in Approach 1, the ID-Locator Mapping (ILM)
system provides the complete mapping information for an aggregate EID
prefix to a querying ITR including all the maps for the relevant
exception subprefixes. The sheer number of such more-specifics can be
worrisome, for example, in LISP. What if a company’s mobile-node EIDs
came out of their corporate EID-prefix? Approach 2 is far better but
still there may be too many entries for a regional ILM to store. In
Approach 2, ILM communicates that there are more specifics but does
not communicate their mask-length. A suggested improvement would be
that rather than saying that there are more specifics, indicate what
their mask-lengths are. There can be multiple mask lengths. This
number should be pretty small for For IPv4 but can be large for IPv6.
Later in the proposal, a different problem is addressed involving a
hierarchy of ETRs and how aggregation of EID prefixes from lower level
ETRs can be performed at a higher level ETR. The various scenarios
here are well illustrated and described. This seems like a good idea,
and a solution like LISP can support this as specified.
As any optimization scheme would inevitably add some complexity; the
proposed scheme for enhancing mapping efficiency comes with some of
its own overhead. The gain depends on the details of specific EID
blocks, i.e., how frequently the situations arise such as an ETR
having a bigger EID block with a few holes.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
