Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb and draft-ietf-ipwave-vehicular-networking

[Alexandre Petrescu <[e-mail]>]

Brian,
Thanks for this.
It is surprising for me.

The events so happened that we are in this situation.  I am trying to 
improve it.

Alex

Le 16/04/2019 à 04:18, Brian E Carpenter a écrit :
> 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) <[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
>>>>>>>
>>>>>>
>>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>
>>
> 
>