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

[Sharon Barkai <[e-mail]>]

Thank you RR for further clarifying the details behind the effort to date in providing mobility networking that meets latency needs on roads.

I think that all on both lists believe that networking can and should be used to extend on-vehicle sensors beyond their line-of-site to prevent accidents by sharing sensor data between vehicles, and, between vehicles and infrastructure.

The technical interoperability and business challenges should be clearer also to the lispers reviewing the domain from your and William comments. Theres actually no clear market entity measured on maximizing throughput, minimizing accidents of any specific street or road on a moment-by-moment basis. This is unlike airport concourses / taxi lanes for example. Not car companies, insurance, gov-muni, or networkers, though all mean well!

Hoping to attract review and contribution from interested parties to the H3-LISP addressable geo-state  draft attempting to focus solely on the virtual IP or EID layer:

- for leveraging multi-application investment in low-latency cellular IP/edge

Eg single digit msec cellular/edge field test beds in Detroit, Atlanta, Plano, EU, Seoul ..

- for allowing features that enable mobility networks to pay for themselves    

Eg saving dedicated maintenance survey costs or non safety related free-parking  detection 

Thanks again!

--szb
Cell: +972.53.2470068
WhatsApp: [phone]

> On Sep 20, 2019, at 1:40 AM, Dick Roy <[e-mail]> wrote:
> 
> Some additions and possible clarifications to William’s comments (with which I generally agree) …
>  
> RR
>  
> From: its [mailto:[e-mail]] On Behalf Of William Whyte
> Sent: Thursday, September 19, 2019 11:20 AM
> To: Ratliff, Stanley; Sharon Barkai; Victor Moreno (vimoreno)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [ipwave] [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
>  
> 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.
> [RR] The spectrum was and still is dedicated DSRC spectrum (5.850-5.925GHz) which is above the 5GHz ISM band (5GHz Wi-Fi), one channel of which (ch172) was set asidec for safety of life and property applications such as the BSM sending application.  There are other applications that use ch172 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,
> [RR] FYI, WSMP has NO layer 3 addresses, so you could call it (and some do) a null-networking protocol:^))) As such, its an extremely efficient broadcast protocol for RF neighborhoods, while also suitable for unicast or groupcast on LANs (and vLANs).
> TCP over IPv6 and IDP over IPv6. These are specified in IEEE 1609.3 and other IEEE 1609 standards
> [RR] I think he meant UDP, not IDP.  Furthermore, there were no restrictions on the transport layer protocol so others such as SCP could be used.  TCP and UDP were mandated as a minimum set.  Similarly, while IPv6 was mandated, IPv4 can and is implemented in some OBUs and RSUs.
> * Applications that use the system and messages that the applications use are defined in IEEE 1609.11 
> [RR] To clarify, 1609.11 is a standard specifying how the European toll system as specified in ISO14906 and ISO 15628 (called European DSRC to make matters confusing) could be implemented on a WAVE device using WSMP.
> 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).
> [RR] ETSI also specifies the access layer called G5, and while it is virtually identical to US DSRC, there is currently one major difference that makes the two systems (technically) non-interoperable. For those in the know, US uses EPD and the ETSI still insists on LPD.
> 
> >>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.
> [RR] This is a really long story, however, C-V2X is being specified as an alternative to US DSRC, not as a cellular access technology since that’s already available and deployed.  The reason LTE Release 14 and successors is being specified has nothing to do with its lineage as a child of cellular; in fact, it is provably a square peg being forced into a round hole and we all know how that generally ends up, and that’s a story for another day
> The 5G evolution is supposed to match the latency of peer to peer WiFi.
> [RR] 5G is nothing but hype at the moment and simply matching the latency would be no reason to switch from DSRC to another access technology for V2V safety, though nothing prevents the addition of 5G NR access technologies in ITS stations (aka OBUs) for other uses.
>  
> RSUs are not required to be actively involved in V2V safety.
> [RR] Though nothing prevents them from being involved for example sending red-light warning messages etc.. It’s a bit complicated.
>  
> 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.
> [RR] and for it to be of any use, ALL immutable identifiers on all active media should change at the same time, and this is not a trivial task generally.
>  
> 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)
> [RR] While this may seem logical, there are other opinions on the subject.
> 
> >> 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.
> [RR] Machine vision is an application that uses sensor inputs including LIDAR and there is nothing in the communication protocols that prevents their implementation, nor sharing of the information they generate  
>  
> 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 <[e-mail]> On Behalf Of Ratliff, Stanley
> Sent: Thursday, September 19, 2019 10:50 AM
> To: Sharon Barkai <[e-mail]>; Victor Moreno (vimoreno) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail]> On Behalf Of Sharon Barkai
> Sent: Thursday, September 19, 2019 1:30 AM
> To: Victor Moreno (vimoreno) <[e-mail]>
> Cc: [e-mail]
> 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: [phone]
> 
> > On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno) <[e-mail]> 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 <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lisp
> > _______________________________________________
> > lisp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> 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.