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