Re: [Ideas] [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

[Sharon <[e-mail]>]

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