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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Sri

If the document was clearly scoped to P2P link local communication it would need correcting, like stop paraphrasing IEEE but it would eventually pass.

Beyond that scope it is a matter of use cases and solutions. I do not know what the WG decided for the former. The latter starts with applicability of existing work, in particular WiND.

If the group needs such functions I claim that we can already do hub and spoke subnets with either a single node as hub (a BSS at L3) or several nodes (that would be RSUs) connected by a high speed transit link. This can be done using Wireless ND and can be described in a few pages.

I claim we can already do mesh in relatively stable situations, e.g., relaying over cars in a parking lot to the RSU that provides Internet. 

I claim we can couple that with NEMO in the car and maintain global reachability while on the road.

What’s harder is to figure what’s reachable at which time. DNA and when to form new addresses. Discover services. How to use the fixed infrastructure to relay between cars while driving. These are some of the real and interesting problems left to be solved by the WG whereas reinventing the wheels could be a waste of time.

All the best,

Pascal

Le 16 avr. 2019 à 05:11, Sri Gundavelli (sgundave) <[e-mail]> a écrit :

>> 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.
> 
> 
> Part of the problem is that we have not clearly put some limits on the
> use-cases. These unbounded limits is opening up these discussions on
> ad-hoc full mesh network formations and the resulting challenging ND
> scenarios. But, again I always assumed this discussion is for the ND
> document and there should be no bearing on this document.
> 
> V2X communications involves V2V, V2I and V2P communication modes. From the
> point of view of vehicular safety, its about exchange of BSM (Basic Safety
> Messages) between vehicles as per SAEJ735 standard. These safety
> communications is always one-hop communication and for very good reason
> IEEE WAVE standards did not bother to require IPv6 transport for carrying
> these messages. The WSMP message which carries these safety elements are
> defined to be carried over layer-2 payloads. Personally, I never thought
> we will replace this L2 safety communication mode with layer-3 mode
> (IPv6-over-80211-OCB). But the use of IPv6 is more for allowing
> applications in the vehicle to communicate with the infrastructure. For
> example, a vehicle using DSRC radio to access some traffic application in
> the cloud. 
> 
> In one sense, this is like a mobile node using 802.11-OCB like any other
> radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its communications.
> In this context, its always about vehicle to infrastructure
> communications. Now, there are other interesting peer to peer use-cases,
> where one vehicle is streaming some video to another vehicle without using
> any infrastructure. While these later examples are very cool, personally,
> I did not expect this WG to solve those use-cases day-1. For us to support
> those use-cases, we need to figure out many more things including
> approaches for exchanges prefixes between two vehicles that come in
> proximity. In my mind, these are very forward looking and the only
> relevant application is platooning. I am not interested in solving this
> V2V problem, but was more interested to enable V2I communications, where
> the focus is about link model, prefix hosting approaches, mobility support
> (building a large L2 domain over RSU’s, or routed approaches with mobile
> IP type protocols) ..etc. In one realization, there may be a P2P link
> assumption between the vehicle and the RSU, eliminating most of these ND
> issues. But, those discussions are for the other document and that clearly
> should remove these ND concerns from this document.
> 
> Sri
> 
> 
> 
> 
> 
> 
> On 4/15/19, 2:04 PM, "Brian E Carpenter" <[e-mail]>
> 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
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> .
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>