Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

And note having a control-plan-less implementation in the vehicles allows for LISP to run in a small footprint. That is, memory, CPU, and bandwidth challenged environments. 

Plus, lowers OpEx complexity in managing millions of vehicles.  The network operations of LISP in this use-case can be done by the edge-RTRs. Which are orders of magnitude less in numbers.

Dino

> On Sep 18, 2019, at 10:30 PM, Sharon Barkai <sharon.barkai@getnexar.com> wrote:
> 
> Thank you Victor.
> 
> Quick recap of mobility networks evolution:
> 
> 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was specified over WiFi spectrum with basic safety messages (BSM) in which cars conveyed their GPS and kinematics sensor events like hard-brake, sharp-turn.
> Additional payment and information messages were specified as well.   
> 
> 2. For privacy considerations road-side-units (RSU) were specified as well to hand  MAC keys to be used so cars will not be tracked. This double infrastructure presented a barrier so DSRC over cellular was specified CV2X.
> The 5G evolution is supposed to match the latency of peer to peer WiFi. 
> 
> 3. The peer to peer challenges however remained, the need to test every product with every other product is a barrier for extending the protocol to support  on vehicle vision and sensory annotations which evolved since - such as machine vision and liadr. Also timing sequence for relaying  annotations between vehicles remains a problem since both DSRC and CV2X have no memory and cars drive away.
> 
> Addressable geo-states brokering solves timing, interoperability, and extendability limitations, and, edge-processing address latency needs => demonstrated in single-digit latencies in production environments, sub 5msecs in labs.
> 
> From here selecting LISP as the layer3 protocol of choice the road is short and explained in the draft:
> 
> o  The support for logical EIDs for states based on (de-facto) geo-spatial standard grids
> 
> o controlling latency and high availability by routing to states at the edge
> 
> o supporting ephemeral EIDs for vehicles
> 
> o signal-free-multicast for limited cast of many geo-spatial channels
> 
> o the distributed connectionless scale
> 
> o the multi-vendor interoperability that allows for “bring your own XTR” to protect geo-privacy
> 
> o the ability to overlay multiple cellular network providers and multiple cloud-edge providers
> 
> .. are some of the features which make LISP a good choice for mobility VPNs. Hope this helps.
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> 
>> On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno) <vimoreno@cisco.com> wrote:
>> 
>> I think a thorough understanding of mobility requirements and dependencies and how LISP may or may not accommodate these scenarios is key. I would like to see us work on this and other mobility related drafts (e.g. Ground based LISP).
>> 
>> Victor
>> 
>>> On Sep 18, 2019, at 11:18 AM, Dino Farinacci <farinacci@gmail.com> wrote:
>>> 
>>> I’m a side author on this document and more of a reviewer. But I’ll answer your questions on behalf of a WG member.
>>> 
>>>> Before I get more privacy feedback (if I do) I want to know
>>>> 1) does the WG actually care about this?
>>> 
>>> I do. Because understanding in deep detail the use-cases, allows us to understand if LISP has the necessary protocol features.
>>> 
>>>> 2) Is it ready for more extensive review?
>>> 
>>> Yes.
>>> 
>>>> I realize we have not adopted this document.  Some of this feedback is to help the chairs judge what to do when the authors do ask for adoption.
>>> 
>>> We are at a point of the protocol’s life where working on use-cases allows more adoption. I am for making this a working group document (even though the authors have not formally requested).
>>> 
>>> 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