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

On Thu, Sep 19, 2019 at 4:57 PM Ratliff, Stanley <sratliff@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.
>

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 <lisp-bounces@ietf.org
> <lisp-bounces@ietf.org>> On Behalf Of Sharon Barkai Sent: Thursday,
> September 19, 2019 1:30 AM To: Victor Moreno (vimoreno) <vimoreno@cisco.com
> <vimoreno@cisco.com>> Cc: lisp@ietf.org <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) <vimoreno@cisco.com <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 <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 <lisp@ietf.org> >> https://www.ietf.org/mailman/listinfo/lisp
> <https://www.ietf.org/mailman/listinfo/lisp> >
> _______________________________________________ > lisp mailing list >
> lisp@ietf.org <lisp@ietf.org> > https://www.ietf.org/mailman/listinfo/lisp
> <https://www.ietf.org/mailman/listinfo/lisp>
> _______________________________________________ lisp mailing list
> lisp@ietf.org <lisp@ietf.org> 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
> its@ietf.org <its@ietf.org> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its> *