On Thu, Sep 19, 2019 at 4:57 PM Ratliff, Stanley <[email protected]> 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. > I agree, there needs to be cooperation, I believe that it is the ADs that should make sure work is focused and directed in the right path. I think the work should be for IPWAVE WG, but AD may make it clear to solve the issue. AB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Regards, Stan From: lisp <[email protected] > <[email protected]>> On Behalf Of Sharon Barkai Sent: Thursday, > September 19, 2019 1:30 AM To: Victor Moreno (vimoreno) <[email protected] > <[email protected]>> Cc: [email protected] <[email protected]> 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) <[email protected] <[email protected]>> > 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 <[email protected] <[email protected]>> 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 >> > [email protected] <[email protected]> >> https://www.ietf.org/mailman/listinfo/lisp > <https://www.ietf.org/mailman/listinfo/lisp> > > _______________________________________________ > lisp mailing list > > [email protected] <[email protected]> > https://www.ietf.org/mailman/listinfo/lisp > <https://www.ietf.org/mailman/listinfo/lisp> > _______________________________________________ lisp mailing list > [email protected] <[email protected]> https://www.ietf.org/mailman/listinfo/lisp > <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. * > > > > > * _______________________________________________ its mailing list > [email protected] <[email protected]> https://www.ietf.org/mailman/listinfo/its > <https://www.ietf.org/mailman/listinfo/its> *
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
