Thanks Stan, there is but its focused on establishing IP connectivity to vehicles.
We assume IP connectivity is there cellular or other, and focus on geo-state routing as a LISP use-case and as means of avoiding direct vehicle to vehicle / vehicle to infrastructure communications (safety, privacy, interoperability etc.). Should defiantly make ipwave wg aware of LISP in-general, and addressable geo-state using LISP in particular. Different problem space networking wise, but, with intersection at high-level eg safer-roads, maintenance, alerts, traffic flow. Thats a very good point. Thanks! --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Sep 19, 2019, at 5:50 PM, Ratliff, Stanley <sratl...@idirect.net> wrote: > > This looks like interesting work. But, don’t we already have a WG addressing > vehicular networks? Has there been any collaboration with the ipwave WG? Just > curious. > > Regards, > Stan > > From: lisp <lisp-boun...@ietf.org> On Behalf Of Sharon Barkai > Sent: Thursday, September 19, 2019 1:30 AM > To: Victor Moreno (vimoreno) <vimor...@cisco.com> > Cc: lisp@ietf.org > Subject: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt > > ***WARNING! THIS EMAIL ORIGINATES FROM OUTSIDE ST ENGINEERING IDIRECT.*** > > 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 > > > > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary and/or > confidential. It is intended solely for the use of the individual or entity > to whom they are addressed. If you are not the original recipient or the > person responsible for delivering the email to the intended recipient, be > advised that you have received this email in error, and that any use, > dissemination, forwarding, printing, or copying of this email is strictly > prohibited. If you received this email in error, please delete it and > immediately notify the sender.
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
