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 <[email protected]> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/lisp
>
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
