Hi Ron, Route pull is not unique to LISP. Just take a look at RTC or ORF .. those are classic route pull mechanisms already deployed in many networks for BGP today for various AFs.
What I however find positively unique to LISP is a boundary less (read no domain/as boundary) IP encapsulation for various kinds of data traffic + as Dino already mentioned an overlay mapping plane to distribute the bindings. The only alternative I see for the analogy of such boundary less encapsulation would be ILNP, but both are a bit different in their respective architectures. As we know ILNP is host based and LISP is network based solutions. Each have their pros and cons and I we have already went in RRG on pages of discussions reg both. Sure as we speak there are efforts to carry remote next hops in BGP to sort of allow for similar boundary less encapsulation, but carrying those inbound of BGP is subject to be filtered anywhere in the path sort of breaking the game. Hence having separate mapping plane does solve that problem quite well. Best, R. On Sun, Oct 12, 2014 at 1:51 AM, Ronald Bonica <[email protected]> wrote: > Folks, > > In Section 2.1, we say that LISP is built on top of four basic design > principles: > > - Locator/Identifier split > - Overlay architecture > - Decoupled data and control-plane > - Incremental deployability > > However, none of these design principles are unique to LISP. The IETF has > produced many overlay architectures over the years and nearly all of them > share these characteristics. > > Oddly, the one design principle that *is* truly unique to LISP is omitted > from the list. That is, the route pull model. > > Likewise, In Section 7, we site several use cases to which LISP might be > applied. However, we say nothing about why LISP might provide a better > solution than any of the other overlay architectures that the IETF has > produced in years gone by. Does LISP provide a superior solution because of > its one unique characteristic? > > In order to fix these problems, I suggest that we make the following changes > to Section 2.1: > > - add a bullet concerning route pull > - add a sentence saying that route pull is the only principle that is unique > to LISP > > A use case should be included in Section 7 only if route pulling makes the > LISP solution superior to existing solutions. > > Ron Bonica > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
