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

[Alexandre Petrescu <[e-mail]>]

Le 15/04/2019 à 10:04, Pascal Thubert (pthubert) a écrit :
> Hello Alexandre.
> 
> I hoped I was clear before.
> 
> Take 4 cars,

HAve you taken them?  Or is it pencil and paper?

DEpending on that I will read further.

Alex

  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 <[e-mail]>
>> Sent: lundi 15 avril 2019 15:35
>> To: Pascal Thubert (pthubert) <[e-mail]>
>> Cc: Brian E Carpenter <[e-mail]>; NABIL BENAMAR
>> <[e-mail]>; Sri Gundavelli (sgundave)
>> <[e-mail]>; nabil benamar <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail]; draft-ietf-ipwave-ipv6-over-
>> [e-mail]
>> 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
>> <[e-mail]> 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)
>> <[e-mail] <mailto:[e-mail]>> 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"
>> <[e-mail] <mailto:[e-mail]>>
>>>>>>       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
>>>>>>