This is very helpful Sharon. Thanks! Makes diving into the draft much more appealing now …
-v > On Sep 18, 2019, at 10:30 PM, Sharon Barkai <sharon.bar...@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) <vimor...@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 <farina...@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 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
