Hi, I have just discovered a useful discussion of the multi-link problem here: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-08#section-5.1.1 The OCB draft doesn't refer to this draft, but only to its superseded predecessor draft-ietf-ipwave-vehicular-networking-survey. I think I will drop this discussion until ipwave gets its two main drafts properly synchronized. Regards Brian On 16-Apr-19 09:04, Brian E Carpenter wrote: > 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 >>>>>> >>>>> >>>>> >>>> . >>>> >>> >>> >> >
