Generally I think that this document needs more work before it will
be ready to submit for publication. Some comments on
draft-ietf-lisp-impact-01:
First of all, I assume that the TBD at the end of section 3 will
be fixed. This reads:
TBD: add a paragraph to explain the operational difference while
dealing with a pull model instead of a push.
Also in section 3, the third paragraph begins:
In addition, Iannone and Bonaventure [IB07] show that the number
of
mapping entries that must be handled by an ITR of a campus network
with 10,000 users is limited to few tens of thousands, and does
not
represent more than 3 to 4 Megabytes of memory.
Reference [IB07] is of course:
Iannone, L. and O. Bonaventure, "On the cost of caching locator/id
mappings", In
Proc. ACM CoNEXT 2007, December 2007.
This paper states:
In our analysis, we assume that the granularity of the
EID-to-RLOC mapping is the prefix blocks assigned by
RIRs. We call it /BGP granularity. In particular, we
used the list of prefixes made available by the iPlane
Project [15], containing around 240,000 entries. Using
/BGP granularity means that each EID is first mapped
on a /BGP prefix. The cache will thus contain /BGP
to RLOC mappings.2 This is a natural choice, since
routing locators are supposed to be border routers.
The authors should be aware that there is some aggregation /
summarization being done in the operation of BGP routing, and that
the granularity of routes which appear in the default-free BGP
routing tables is fundamentally different from the granularity of
enterprise network / ISP boundaries across which traffic is
exchanged.
The same paragraph cites Kim et al. [KIF11], which is Kim, J.,
Iannone, L., and A. Feldmann, "Deep dive into the lisp cache and
what isps should know about it", In Proc. IFIP Networking 2011,
May 2011. From this document:
In addition, we use a local BGP prefixes
database, fed with the list of BGP prefixes published by the
iPlane Project [17].
The database is used to group EID-to-RLOCs mappings with the
granularity of
existing BGP prefixes, because, as for today, there is no
sufficient information
to predict what will be the granularity of mappings in a
LISP-enabled Internet.
I agree that "there is not sufficient information to predict what
will be the granularity of mappings in a LISP-enabled Internet".
However, not knowing what the mapping granularity will be does not
justify using an extremely optimistic guess, and then acting as if
the results are meaningful. These assumptions are clearly off by
some number of orders of magnitude, but how many orders of
magnitude is unknown. We will note that the current internet
default-free routing table includes a few hundred thousand entries
(roughly twice the 240,000 entries that existed when this study was
done).
For example, we might assume that the intended global deployment
model involves xTRs at the boundary between enterprise networks and
service providers, and might note that there are several million
companies in the USA alone (most of these are relatively small
companies, of course). Thus there may be very roughly on the order
of a hundred million or so companies worldwide. If each one had a
separate entry in the mapping table, then the number of entries
will be nearly 1,000 times larger than BGP-prefix granularity.
Section 4 mentions as one possible use of LISP: "enable mobility
of subscriber end points". If individual end points are advertised
into LISP, then the granularity of the mapping table may be on the
order of individual systems. In this case the number of mapping
table entries that could exist globally might be on the same order
of magnitude as the number of people in the world, or very roughly
7 Billion entries. This would suggest that the mapping table might
be roughly 30,000 times finer grained than was assumed in the
referenced studies.
I don't see how we can accurately predict the control plane load of
LISP without some sense for what the granularity of the mapping
table will be. It should however be possible to bound the control
plane load. The referenced studies give a lower bound on possible
control plane load (it won't be any less), but give neither an
accurate measurement nor an upper bound on the potential control
plane load. I don't think that the document can claim to explain
the impact of LISP without there being an attempt to measure an
upper bound on the control plane load.
Finally, perhaps I missed it but I didn't see any discussion of
the volume of overhead related to OAM traffic used for liveness
detection (the need for ITR's to determine the reachability of
ETR's).
Thanks, Ross
*From:*lisp [mailto:[email protected]] *On Behalf Of *Luigi
Iannone *Sent:* Monday, March 09, 2015 10:22 AM *To:* LISP mailing
list list *Cc:* [email protected] *Subject:*
[lisp] WG Last Call draft-ietf-lisp-impact-01
Hi All,
the authors of the LISP Impact document
[https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested
the Work Group Last Call.
This email starts a WG Last Call, to end March 30th, 2015.
Because usually the pre-meeting period is already overloaded, the
LC duration is set to three weeks.
Please review this updated WG document and let the WG know if you
agree that it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain
what it would take to address your concerns.
Any raised issue will be discussed during the WG meeting in
Dallas.
Thanks
Luigi & Joel
_______________________________________________ lisp mailing list
[email protected] https://www.ietf.org/mailman/listinfo/lisp
