Re: [Int-dir] draft-ietf-ipwave-ipv6-over-80211ocb-39

[Alexandre Petrescu <[e-mail]>]

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