> 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.
How about a more obvious example. ARP. ;-) > 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. The LISP-ALT was an overlay control-plane so filtering COULD HAVE been less of an issue because less parties would be involved in running it versus the number of people/organizations that run BGP today. Dino > > Best, > R. > > > On Sun, Oct 12, 2014 at 1:51 AM, Ronald Bonica <rbon...@juniper.net> 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 >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > 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
