Re: draft-ietf-ipwave-ipv6-over-80211ocb-38

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

 



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





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

  Powered by Linux