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

I wonder why is the draft using 64bit id's and not variable length id's.

I wonder whether the hexagon style can be applied in 3D where drone 
taxis need to follow a certain traffic regulation, potentially a 3D 
extension of regular (2D) traffic lights.

I wonder whether the H3 geospatial indexing is the same as 
what3words.com.  Because the what3words recent presentation I have seen 
did not mention anything similar, neither does H3.  Yet they seem so 
similar to me.

Alex

Le 19/09/2019 à 16:50, Ratliff, Stanley a écrit :
> 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-bounces@ietf.org> *On Behalf Of *Sharon Barkai
> *Sent:* Thursday, September 19, 2019 1:30 AM
> *To:* Victor Moreno (vimoreno) <vimoreno@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) 
> <vimoreno@cisco.com <mailto: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 
> <mailto: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 <mailto:lisp@ietf.org>
>  >> https://www.ietf.org/mailman/listinfo/lisp
>  > _______________________________________________
>  > lisp mailing list
>  > lisp@ietf.org <mailto:lisp@ietf.org>
>  > https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org <mailto: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.
> 
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
> 