Hi Luigi,
I am not suggesting that discussion of cache scaling and control overhead be
dropped. This discussion is very helpful to the reader.
I suggest only that we run with Joel's proposal to add a disclaimer. The
disclaimer should say something like:
>>>>>> we do not know what the
> >>>> impact on cache size and control overhead will be, as the studies
> >>>> that have been made have been disputed as to their relevance to the
> >>>> core Internet case
Furthermore, we should extend the disclaimer to say:
"We do not know what the impact of cache size and control overhead will be
upon {x, y, and z}".
Ron
> -----Original Message-----
> From: Luigi Iannone [mailto:[email protected]]
> Sent: Wednesday, April 01, 2015 9:40 AM
> To: Ronald Bonica
> Cc: Damien Saucez; LISP mailing list list; BRUNGARD, DEBORAH A (ATTLABS)
> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
>
> Hi Ron,
>
> > On 31 Mar 2015, at 19:48, Ronald Bonica <[email protected]> wrote:
> >
> > Damien,
> >
> > In his email below, Joel asks:
> >
> >>>> if we modified the section to say that we do not know what the
> >>>> impact on cache size and control overhead will be, as the studies
> >>>> that have been made have been disputed as to their relevance to the
> >>>> core Internet case, would the document still meet the IESG
> >>>> requirements for evaluating the impact
> >
> > I support Joel's request, so long as the disclaimer is complete.
>
> Agreed that we need to clarify (via a disclaimer) what are the assumptions of
> the studies, and that outsides these assumptions we have no information.
>
>
> > If cache size and control overhead have impact, they must have impact
> upon something. Do we know what they will impact? If so, tell us. If not, tell
> us that.
> >
>
> Let me try to understand here. What you are suggesting is that any
> discussion on the scalability of cache and control overhead should be
> dropped (they are in the papers anyway), and only the aspects that have an
> impact (and on what they have an impact) should be maintained.
>
> Is my reading correct?
>
> BTW, Deborah was also suggesting to simplify some sections which are
> cluttered with to much numbers. This seems to me inline with your
> suggestion (if I got it correctly).
>
> ciao
>
> Luigi
>
>
> >
> > Ron
> >
> >> -----Original Message-----
> >> From: Damien Saucez [mailto:[email protected]]
> >> Sent: Monday, March 30, 2015 7:19 PM
> >> To: Ronald Bonica
> >> Cc: Joel Halpern; Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS);
> LISP
> >> mailing list list
> >> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
> >>
> >> Ron,
> >>
> >> As one of the authors I can say I am not frustrated :-)
> >>
> >> We are looking on how to address in the best way the comments of this
> >> thread.
> >>
> >> Just that it is unrealistic to hope a new full study on the cache
> >> size from research partners as such a study takes a lot of time and
> >> resources (to produce the experimentation, then to get reviewed in a
> >> conference or journal and finally get published) and would not change
> >> any conclusion with regards to the analytical studies reference in
> >> the draft already and that draw general conclusions.
> >>
> >> The best solution could be to ask your customers to provide me the
> >> necessary information so that I could evaluate the impact of LISP for
> >> their needs. Without that, I am afraid that the only thing that we
> >> can reasonably provide is theoretical/analytical studies.
> >>
> >> The disclaimer you propose to add is just incorrect. It is not true
> >> that we don't know the impact of cache size. Actually, in the draft,
> >> we already reference the analytical study [CCD12] that demonstrates
> >> analytically that it is possible to link cache size, traffic pattern, and
> >> miss
> rate.
> >>
> >> Here is the paragraph present in the draft:
> >>
> >> [CCD12] generalizes the caching discussion and proposes an analytic
> >> model for the EID-to-RLOC cache size when prefix-level traffic has a
> >> stationary generating process. The model shows that miss rate can be
> >> accurately predicted from the EID-to-RLOC cache size and a small set
> >> of easily measurable traffic parameters, meaning that operators can
> >> provision the EID-to-RLOC cache of their ITRs according to the miss
> >> rate they want to achieve for their given traffic.
> >>
> >> That is clear enough for me and unless someone can prove the model
> >> wrong I am perfectly fine with this observation that is supported by
> empirical data.
> >>
> >> Cheers,
> >>
> >> Damien Saucez
> >>
> >> On 30 Mar 2015, at 17:17, Ronald Bonica <[email protected]> wrote:
> >>
> >>> Brian, Deborah,
> >>>
> >>> I realize that the authors are frustrated. Maybe we can run with
> >>> Joel's
> >> proposal if we make the disclaimer complete.
> >>>
> >>> Shouldn't the disclaimer read something like, "We do not know the
> >>> impact
> >> of cache size and control overhead on {x, y, z}", where x, y and z might
> >> be:
> >>>
> >>> - LISP scaling
> >>> - LISP security
> >>> - LISP resiliency
> >>> - other ???
> >>>
> >>> Given that, might we draw some conclusions regarding LISP's
> applicability?
> >>>
> >>> Ron
> >>>
> >>>> -----Original Message-----
> >>>> From: lisp [mailto:[email protected]] On Behalf Of Joel M.
> >>>> Halpern
> >>>> Sent: Sunday, March 29, 2015 9:55 PM
> >>>> To: Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS)
> >>>> Cc: LISP mailing list list
> >>>> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
> >>>>
> >>>> Brian, Deborah, if we modified the section to say that we do not
> >>>> know what the impact on cache size and control overhead will be, as
> >>>> the studies that have been made have been disputed as to their
> >>>> relevance to the core Internet case, would the document still meet
> >>>> the IESG requirements for evaluating the impact. I don't want to
> >>>> ask the authors if they can live with a certain change if that
> >>>> change will cause other necessary reviewers to complain.
> >>>>
> >>>> I do not see it as sensible to hold up the publication of this and
> >>>> the other LISP work while researchers go off to see if they can
> >>>> calculate
> >> better results.
> >>>> Particularly not when publishing this document is required to do
> >>>> other
> >> work.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 3/29/15 9:50 PM, Ross Callon wrote:
> >>>>> I suppose that there are two options:
> >>>>>
> >>>>> 1. Admit that we have no clue what the cache size or control
> >>>>> overhead will be.
> >>>>>
> >>>>> 2. Repeat the cited studies, but with a pessimistic (worse case)
> >>>>> rather than optimistic (better than best case) assumption about
> >>>>> cache granularity.
> >>>>>
> >>>>> The second option would allow us to actually have some idea what
> >>>>> would happen if LISP were deployed on an Internet-wide scale, but
> >>>>> would of course take more time and more work.
> >>>>>
> >>>>> Ross
> >>>>>
> >>>>> PS: I will be offline at meetings all of this week, so I might be
> >>>>> a bit slower to respond for the next few days.
> >>>>>
> >>>>> -----Original Message----- From: Joel M. Halpern
> >>>>> [mailto:[email protected]] Sent: Sunday, March 29, 2015 9:36 PM
> >> To:
> >>>>> Ross Callon; Luigi Iannone; LISP mailing list list Cc:
> >>>>> [email protected] Subject: Re: [lisp] WG Last
> >>>>> Call
> >>>>> draft-ietf-lisp-impact-01
> >>>>>
> >>>>> Putting aside the TBD (which of course needs to be fixed), I have
> >>>>> trouble figuring out what you want us to say about the main issue
> >>>>> in your review. On the one hand, this is the very issue that we
> >>>>> have been asked to comment on, and on the other hand you say that
> >>>>> we don't know. What do you think it is reasoanble to say?
> >>>>>
> >>>>> Yours, Joel
> >>>>>
> >>>>> On 3/29/15 9:03 PM, Ross Callon wrote:
> >>>>>> 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
> >>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> lisp mailing list
> >>>> [email protected]
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>
> >>> _______________________________________________
> >>> lisp mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/lisp
> >
> > _______________________________________________
> > lisp mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
