> Hi all > > What about this (as a new item in section 2.1)? > > * Pull Architecture: With this principle the network state is stored > at the control-plane -in a potentially distributed database- and > retrieved on-demand by the data-plane. Pull architectures allow to > push important routing mechanisms such as Traffic Engineering to the > control-plane, alleviating the data-plane. At the same time they > require of additional techniques to handle data-plane events, such as > network failures.
Well even though we like to stress a Pull architecture with LISP, we all know well that if xTRs run LISP-ALT that it is very much a push archtecture. See (I hope Alia is listening), it is not about a LISP versus BGP control-plane, because one of the RFC documented mapping database transport system is LISP-ALT which IS BGP. LISP is indeed a "cached architecture" which means the FIB needs to be populated on demand. But if the state is local in a database, LISP-ALT BGP RIB, then the information is available locally. When I was at cisco, we did some customer testing where the customer wanted to use BGP as the mapping database so FIB hardware lookups cache-missed, then the BGP RIB was consulted. They had requirements to not go outside of the box to get the cache populated. Turns out they wanted small hardware FIBs and had large software RIBs, hence using LISP to push via BGP was a naturual fit. Dino > > Albert > > On Mon, Oct 13, 2014 at 4:31 PM, Dino Farinacci <farina...@gmail.com> wrote: >>> >>> The only remaining question is whether or not we want to add a bullet >>> concerning the push/pull model & Mapping database >> >> Well since a large portion of the document discusses the mapping system, I >> would say yes. >> >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
