Excuse top posting. As I've said, I am no expert, but I do know some physics, and it seems pretty clear to me that if there are multiple lanes of traffic, a large truck can easily shield signals between two cars and the shielding will be intermittent, regardless of how much wireless power is allowed, depending on traffic movement. So it's a highly dynamic mesh network. That's a very interesting problem that has been much studied, and it's fundamentally different from the ND design scenario. So I find it hard to believe that nobody can write the TBD text. Regards Brian On 15-Apr-19 23:26, Alexandre Petrescu wrote: > Hi Brian, > > Le 14/04/2019 à 22:49, Brian E Carpenter a écrit : >> Hi Alexandre, >> >> On 15-Apr-19 04:38, Alexandre Petrescu wrote: >>> 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. >> >> That's exactly the text that I find problematic. I can't write a new >> version because I lack your expert knowledge, but IMHO it should be >> more specific: >> >> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used >> over 802.11-OCB links. However, as on any wireless link, transmission >> of multicast ND packets may fail in OCB. In particular, scenarios >> where TBD TBD TBD are likely to be unreliable and SHOULD NOT be >> deployed until an alternative standardised solution is available. >> The best of current knowledge indicates the kinds of issues that >> may arise with ND in OCB mode; they are described in Appendix J. > > I can agree with that formulation and put it in the text. > > But I need an indicat that TBD is defined soon. The time commitments of > Pascal seem to be saying he is no longer interested in writing that TBD. > > I wait a little for this to clarify. > >> Also I don't like this phrasing in Appendix J: >> >> Early experiences indicate that it should be possible to exchange >> IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR >> (Address Resolution). >> >> Could you rather say the opposite: >> >> Early experience indicates that it is possible to exchange >> IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR >> (Address Resolution) in good conditions. However, this does not >> apply if TBD TBD TBD... > > This is an appendix. I could put TBD there now. > > Alex > >> >> Regards >> Brian >> >> >>> >>> >>> 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 >>>>> >>>> >>>> >>> . >>> >> >> >
