Hello Alexandre. I hoped I was clear before. Take 4 cars, A, B, C, D separated by 100 meters each, such that all can hear C, though A has a bad quality, and A and D are too far apart. C advertises a prefix in RA(PIO), all can hear it. - Try pinging A from D using the address based on that prefix, won't ping. - Try configuring A's address on D it will be accepted, which means that DAD will not work either. This is nothing new, common to all the short/middle range radios we have looked at. You may try the same placing C at the corner of a street, A and D in orthogonal streets. This has nothing to do with low power and everything to do with radio propagation. The exception is Wi-Fi, and that's because the BSS emulates the broadcast domain, as I think I explained already. RFC 8505 recreates the Wi-Fi design but at L3... and the use cases above were made to work on other radios with similar properties. More in the 6TiSCH architecture I guess... Sorry you consumed all the time I could dedicate, and more. All the best, Pascal > -----Original Message----- > From: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> > Sent: lundi 15 avril 2019 15:35 > To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> > Cc: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; NABIL BENAMAR > <n.benamar@xxxxxxxxxxxxx>; Sri Gundavelli (sgundave) > <sgundave@xxxxxxxxx>; nabil benamar <benamar73@xxxxxxxxx>; > ietf@xxxxxxxx; its@xxxxxxxx; int-dir@xxxxxxxx; draft-ietf-ipwave-ipv6-over- > 80211ocb.all@xxxxxxxx > Subject: Re: draft-ietf-ipwave-ipv6-over-80211ocb-38 > > Pascal - do you know of a OCB use and some scenario where ND does not > work? > > (I mean some trials that you may have done with OCB; if you never played with > OCB and wiht IP on it, I think it makes no sense to describe speculations of it). > > Alex > > Le 15/04/2019 à 08:53, Pascal Thubert (pthubert) a écrit : > > This text is wrong, Alexandre. > > > > There is a distinction between performance issue and does not work. You > can not MUST a protocol that by design will only work in a subset of the > possible situations. > > > > What you can do is document in which situations it can be made to work > (P2P and full overlap of the broadcast domains) and explain the drawbacks (eg > if broadcast is sent at higher power or slower phy then it impacts unicast > communications). > > > > Then you want to open the door to using more suitable techniques in future > documents, which the MUST seems to discourage. > > > > > > Regards, > > > > Pascal > > > >> Le 14 avr. 2019 à 18:38, Alexandre Petrescu > <alexandre.petrescu@xxxxxxxxx> a écrit : > >> > >> Brian, > >> > >> Le 14/04/2019 à 04:20, Brian E Carpenter a écrit : > >>>>> All we need is a simple statement in the spec which puts some > >>>>> scope limits, w.r.t the missing ND pieces and issues. > >>> Yes, that is clearly essential, as well as an associated health > >>> warning that implementers must not rush ahead because of the risk of > >>> non-interoperability. > >> > >> There is already paragraph, and an Appendix, about potential ND issues. I > think that text qualifies as an associated health warning. > >> > >> I do not know what do you mean about the risk of interoperability. This ND > that works is interoperable between several OCB cards, IP Road Side Units, and > linuces. (I can cite brands that I al familiar with and that interoperate. > >> > >> This is the current paragraph and Appendix that qualify as a warning that > you suggest: > >> > >>> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used > >>> over 802.11-OCB links. Transmitting ND packets may prove to have > >>> some performance issues. These issues may be exacerbated in OCB > >>> mode. Solutions for these problems SHOULD consider the OCB mode of > >>> operation. The best of current knowledge indicates the kinds of > >>> issues that may arise with ND in OCB mode; they are described in > >>> Appendix J. > >> > >> > >> Alex > >> > >>> Regards > >>> Brian > >>>> On 14-Apr-19 13:58, NABIL BENAMAR wrote: > >>>> +1 Sri > >>>> > >>>> On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) > <sgundave@xxxxxxxxx <mailto:sgundave@xxxxxxxxx>> wrote: > >>>> > >>>> I understand your point Brian, but IMO there are enough reasons not > to > >>>> delay this work. > >>>> > >>>> There are many use-cases/applications where there is a stable > topology of > >>>> RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band allows > the > >>>> channel use for non-priority/non-traffic safety related applications. > For > >>>> example, a vehicle in a gas station can receive a coupon from the > >>>> 802.11-OCB radio (AP/RSU) in the gas station. There, its a stable > topology > >>>> that classic ND is designed for. In this operating mode, its perfectly > >>>> reasonable to use classic ND and it works. The authors have shown > enough > >>>> lab data on the same. > >>>> > >>>> Ideally, I agree with you that it makes lot more sense to publish both > the > >>>> specs at the same time. But, for what ever reasons the WG went on > this > >>>> path. Authors have spent incredible amount of efforts in getting the > draft > >>>> this far and we cannot ignore that. You can see the efforts from the > >>>> version number; when did we last see a draft version -037? > >>>> > >>>> We also need to distill the recent ND discussions and filter out the > >>>> threads that are clearly motivated to insert a ND protocol that is > >>>> designed for a totally different operating environment. An argument > that a > >>>> protocol designed for low-power environments is the solution for > vehicular > >>>> environments requires some serious vetting. Looking at the > >>>> characteristics, always-sleeping, occasional internet connectivity, > >>>> low-power, no memory, no processing power, no mobility ..etc, > meeting > >>>> vehicular requirements is some thing most people in the WG do not > get it. > >>>> > >>>> Bottom line, IMO, we should move this forward and publish the > document. > >>>> All we need is a simple statement in the spec which puts some scope > >>>> limits, w.r.t the missing ND pieces and issues. There are other > proposals > >>>> in the WG that will address the gaps and bring closure to the work. > >>>> > >>>> Sri > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 4/12/19, 1:28 PM, "Brian E Carpenter" > <brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>> > >>>> wrote: > >>>> > >>>> >On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote: > >>>> >>If you go back and check 2017 archives, I did raise many of these > >>>> >>issues. But, we clearly decided to limit the scope excluding address > >>>> >>configuration, DAD, ND aspect, link models. When there is such a > scope > >>>> >>statement, it should clearly move these comments to the draft that > >>>> >>defines how ND works for 802.11-OCB links. > >>>> > > >>>> >This is of course possible. In general the IETF hasn't done that, but > has > >>>> >followed the lead set by RFC 2464 with the complete specification of > >>>> >IPv6-over-foo in one document. > >>>> > > >>>> >However, I don't believe that publishing an RFC about the frame > format > >>>> >without *simultaneously* publishing an RFC about ND etc would be a > good > >>>> >idea. That would leave developers absolutely unable to write useful > >>>> >code, and might easily lead to incompatible implementations. Since > >>>> >we'd presumably like Fords to be able to communicate with > Peugeots, > >>>> >that seems like a bad idea. > >>>> > > >>>> >Regards > >>>> > Brian > >>>>
