Re: Expertise on ND problems on OCB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Brian,

Le 14/04/2019 à 22:49, Brian E Carpenter a écrit :
Hi Alexandre,

On 15-Apr-19 04:38, Alexandre Petrescu wrote:

[...]
    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:

I do have expert knowledge on ND on OCB, although only at a certain level. It works.

Other people may claim ND does not work on OCB, but have they tried OCB at all?

It is the people who claim ND does not work on OCB should write the new version of the 'TBD' text.

It is very simple to try ND on OCB. I published a howto on the email list. A Hackathon w/o me was tried following that howto. A few other organisations that I work with tried it (w/o me). I did not received feedback from them about ND not working.

What is difficult to try is to reproduce the ND-over-OCB problem imagined by Pascal. It is difficult to try because it involves 4 cars (I dont have that many). It is also difficult to try because it seems to miss the fact that OCB can do high power. Maybe that high power solves the problems that appear in ND over low power.

For my part, I cant put text about ND on OCB without having an implementation of that problem.

It is for that reason that I asked Pascal, or anybody else claiming ND does not work on OCB, to try it and write that text 'TBD'.

Alex


     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.

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...

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



.







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux