Can add that we don't want to scale a mapping service like dns or x500. rather take full advantage of no-sql tech that wasn't available at the time to create a flat pub-nub like service for overlays, scaled based on underlay regular IP. No bootstrap loop.
The effect on mobile can be dramatic, any packet coming up from the base-station, no matter the address space or transience can be considered Gi. No need for a whole different sets of framework for network functions pre Gi and post Gi. There's the RAN and there's virtual IP (NVO3). Or rather (flat ) directory-assisted virtual IP. traffic going back and forth: Mapping | | RAN <> NVO3 <> IP <> NVO3 <> Internet | | Functions Functions (scheduling) (peering) --szb On Sep 28, 2016, at 1:30 PM, Dino Farinacci <farina...@gmail.com> wrote: >> Am 28.09.2016 um 05:02 schrieb Dino Farinacci: >>>> When I spoke to some of the 5G folks this was clearly the direction and in >>>> fact Dino's LISP was one of the strongest candidates there as control >>>> plane. >>> The IETF’s LISP-DDT borrows ideas from DNS but does not need to be >>> structured like the DNS deployed today. There is hierarchy for scale with >>> iterative lookups, but we don’t have to allow it to get out of hand with >>> too many levels of hierarchy. >> What do you mean by that exactly? What's the problem with DNS and what's >> the advantage of LISP-DDT? > > These were the main reasons we didn’t consider DNS as a mapping system back > in the RRG days when we were designing the mapping system for LISP: > > (1) DNS didn’t work easily on bit boundaries. So delegation would have to be > on byte boundaries and that restricts the flexibility of how EID address > allocation occurs on the LISP-DDT hierarchy. > > (2) DNS doesn’t have a pub/sub model. LISP needed notification support so old > RLOCs new when an EID has moved to a new set of RLOCs. > > (3) Architecturally, we didn’t want routing information to be in an > applicaiton Directory. Since DNS depends on routing, we didn’t want routing > to depend on DNS and cause a circular dependency to be created. > > (4) And we thought it would be too hard to get IETF to allow network layer > information to be stored in what is really a application level database. > > So the architectural definition of a LISP EID would be in the DNS pointed to > by names and the dynamic binding of EIDs to RLOCs would be in a new network > layer database, which we refer to as the LISP Mapping System. > > Dino > >> >> Michael >> >>> >>> 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 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp