Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
And note having a control-plan-less implementation in the vehicles allows for LISP to run in a small footprint. That is, memory, CPU, and bandwidth challenged environments. Plus, lowers OpEx complexity in managing millions of vehicles. The network operations of LISP in this use-case can be done by the edge-RTRs. Which are orders of magnitude less in numbers. Dino > On Sep 18, 2019, at 10:30 PM, Sharon Barkai > wrote: > > 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) >> 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 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
Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
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 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 On Behalf Of Sharon Barkai > Sent: Thursday, September 19, 2019 1:30 AM > To: Victor Moreno (vimoreno) > 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) > > 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 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
Re: [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. I had presented draft-ietf-lisp-predictive-rlocs to IPWAVE a couple of years ago. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [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 On Behalf Of Sharon Barkai Sent: Thursday, September 19, 2019 1:30 AM To: Victor Moreno (vimoreno) 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) > mailto: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 >> mailto: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<mailto:lisp@ietf.org> >> https://www.ietf.org/mailman/listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp> > ___ > lisp mailing list > lisp@ietf.org<mailto:lisp@ietf.org> > https://www.ietf.org/mailman/listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp> ___ lisp mailing list lisp@ietf.org<mailto: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 pers
Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
This is very helpful Sharon. Thanks! Makes diving into the draft much more appealing now … -v > On Sep 18, 2019, at 10:30 PM, Sharon Barkai > wrote: > > 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) >> 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 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
Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
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) > 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 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
Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
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 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
Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
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
Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
I appreciate the work Sharon has put in revising this document of late. His revisions reflect some preliminary comments I have gotten on the privacy issues. In reviewing this for that purpose, I was struck by how under-specified this document had been. (It is MUCH better.) This does however lead me to a question. Does the working group actually care about this document? Based on the lack of comments about the absence of detail from WG members, it seems that no one actually tried to figure out how this would work from the document. This suggests that the WG as a whole does not care. Before I get more privacy feedback (if I do) I want to know 1) does the WG actually care about this? 2) Is it ready for more extensive review? 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. Thank you, Joel On 9/16/2019 4:46 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network-Hexagons: H3-LISP Based Mobility Network Authors : Sharon Barkai Bruno Fernandez-Ruiz S ZionB Alberto Rodriguez-Natal Fabio Maino Albert Cabellos-Aparicio Dino Farinacci Filename: draft-barkai-lisp-nexagon-10.txt Pages : 18 Date: 2019-09-16 Abstract: This document specifies combined use of H3 and LISP for mobility-networks: - Enabling real-time tile by tile indexed annotation of public roads - For sharing: hazards, blockages, conditions, maintenance, furniture.. - Between MobilityClients producing-consuming road geo-state information - Using addressable grid of channels of physical world state representation The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-barkai-lisp-nexagon/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-barkai-lisp-nexagon-10 https://datatracker.ietf.org/doc/html/draft-barkai-lisp-nexagon-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-barkai-lisp-nexagon-10 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
