Cheers! and please do. Will all share these roads:) --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794
> On Sep 19, 2019, at 10:22 PM, William Whyte <wwh...@qti.qualcomm.com> wrote: > > No worries, thanks for taking it in good grace. I haven’t looked closely at > LISP but I appreciate that it’s a real problem you’re trying to solve and one > you’ve thought about hard. I may (*may*) be able to make time to look at it > properly over the next while. > > Cheers, > > William > > From: Sharon Barkai <sharon.bar...@getnexar.com> > Sent: Thursday, September 19, 2019 3:06 PM > To: William Whyte <wwh...@qti.qualcomm.com> > Cc: Ratliff, Stanley <sratl...@idirect.net>; Victor Moreno (vimoreno) > <vimor...@cisco.com>; lisp@ietf.org; i...@ietf.org > Subject: [EXT] Re: [ipwave] [lisp] I-D Action: > draft-barkai-lisp-nexagon-10.txt > > Thank you William. > > Sorry if my summary did some injustice to the DSRC spec trying to account for > the adaptation challenges and the budgets considered necessary by gov-muni. > > But I think you would agree that specifying only the virtual ip geo-state > grid-brokering is a different approach. > > It may or may result in different adoption pattern, it may be limited in the > end to be a kind of an in-network live-map of furniture, signs, defects etc, > or, it may cover the whole spectrum of hazards, alerts, breaches in the end. > Testing level at this point is limited to a few thousands of cars in the > major US cites. > > v2i testing has also been limited to junction traffic light cameras, so > overall v2v v2i has been focused mainly on creating an H3 machine vision > puzzle using LISP. > > Regardless hope you feel this H3-LISP direction is worth a shot. > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > > On Sep 19, 2019, at 9:19 PM, William Whyte <wwh...@qti.qualcomm.com> wrote: > > Hi all, > > Some of the history below is wrong, so I’d like to correct it (with no > comment on LISP itself): > > >> 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. > > The V2X system specified by the DSRC/WAVE standards in IEEE and SAE covers > the whole stack (not just layer 2) and supports both broadcast and unicast > operations (it’s not inherently peer-to-peer, though some of the defined > applications are peer-to-peer). > > For example, in the US: > * Layers 1 and 2 are defined in 802.11p, now incorporated into the main > 802.11 standard as 802.11 *O*utside the *C*ontext of a *B*asic Service Set > (OCB) > * Supported transport and network layer protocols include WSMP, a single-hop > protocol best suited to broadcast, TCP over IPv6 and IDP over IPv6. These are > specified in IEEE 1609.3 and other IEEE 1609 standards > * Applications that use the system and messages that the applications use are > defined in IEEE 1609.11 and (mainly) in SAE J2735 and the SAE J2945/x series > of standards. The process of specifying applications is ongoing – the para > above makes it seem like a set of applications was defined and then the > specification process stopped. > > (The situation in Europe is similar except that the lower layers above layer > 2 are specified in ETSI and the higher layers are specified in CEN, with some > overlap; there is also a series of standards from ISO TC 204 which address > the same area). > > >>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. > > RSUs are not required to be actively involved in V2V safety. > > Vehicles use certificates to sign messages, not MAC keys. > > Anti-tracking is important, agreed! This is achieved by giving vehicles a > large number of simultaneously valid certificates and allowing them to switch > between them periodically. > > There is no “double infrastructure”. > > C-V2X uses the same security system as DSRC and was proposed not so much > because of technical shortcomings with DSRC as because of a business model > failure – DSRC hasn’t been deployed because of concerns that it wouldn’t be > widespread enough to be effective and the hope is that C-V2X will have > synergies with other communications hardware on the car that will lower the > total cost of ownership (as well as providing a migration path to > higher-capacity channels) > > >> 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. > > There is no need to test every product with every other product. OmniAir and > ETSI run conformance test services that test conformance to the standards, > and products that implement the standards in general interoperate. This is > similar to how not every WiFi chip needs to be tested against every other > WiFi chip; instead, each chip can be individually certified and give a high > confidence of interoperability. > > >> Also timing sequence for relaying annotations between vehicles remains a > >> problem since both DSRC and CV2X have no memory and cars drive away. > > Memory of “annotations” would be implemented higher up the stack – whether or > not the layer 2 protocol maintains the information is immaterial. Some > architectures (like the ETSI and ISO ITS Station) identify functional > components within the devices that would maintain that state; some (like the > IEEE WAVE device architecture) leave it as an implementation choice. I agree > that the existing standards don’t fully address this issue, though. > > Hope this corrects some misunderstandings. > > Cheers, > > William > > > > > > > From: its <its-boun...@ietf.org> On Behalf Of Ratliff, Stanley > Sent: Thursday, September 19, 2019 10:50 AM > To: Sharon Barkai <sharon.bar...@getnexar.com>; Victor Moreno (vimoreno) > <vimor...@cisco.com> > Cc: lisp@ietf.org; i...@ietf.org > Subject: [EXT] Re: [ipwave] [lisp] I-D Action: > draft-barkai-lisp-nexagon-10.txt > > 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
