|
Hello Alex and all,
I have a few comments, although I have only briefly scanned the
OCB draft.
- RFC 8505 isn't just about low power. More to the point in
this discussion, it's about reducing interference by reducing
the number of multicasts needed in a multilink subnet. Please
note that I am neither discouraging nor advocating the use of
RFC 8505 for v6-over-OCB, but I think it would be better to
avoid suggesting that it is only useful for low-power mesh.
- Even if you did have four cars to run experiments, the results
could hardly be considered conclusive. Simulation can be very
helpful in such circumstances. You know the velocities and the
range of the signal. You have many many thousands of easily
accessible real-world topologies, and even the interference
characteristics.
- I made a quick scan of the draft and found this: "All nodes in
the subnet MUST be able to communicate directly using their
link-local unicast addresses.". Does this mean that the
solution is not applicable for topologies exhibiting the hidden
terminal problem? Or, does "directly" mean something else?
I think the draft could benefit from a very clear applicability
statement, specifically including the projected number of vehicles
in the subnet. If every vehicle on the subnet can expect deliver
of multicast packets to every other vehicle on the subnet, then
the problem is different than if hidden terminal effects occur or
if multicast is unreliable for some other reason. Maybe for
clarity it would be helpful to include a diagram of a general
target network with more than three or four vehicles.
You can also tell me that my opinion lacks relevance since I have
not carefully read the draft.
Regards,
Charlie P.
On 4/15/2019 4:54 AM, 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:
[...]
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:
I do have expert knowledge on ND on OCB, although only at a
certain level. It works.
Other people may claim ND does not work on OCB, but have they
tried OCB at all?
It is the people who claim ND does not work on OCB should write
the new version of the 'TBD' text.
It is very simple to try ND on OCB. I published a howto on the
email list. A Hackathon w/o me was tried following that howto. A
few other organisations that I work with tried it (w/o me). I did
not received feedback from them about ND not working.
What is difficult to try is to reproduce the ND-over-OCB problem
imagined by Pascal. It is difficult to try because it involves 4
cars (I dont have that many). It is also difficult to try
because it seems to miss the fact that OCB can do high power.
Maybe that high power solves the problems that appear in ND over
low power.
For my part, I cant put text about ND on OCB without having an
implementation of that problem.
It is for that reason that I asked Pascal, or anybody else
claiming ND does not work on OCB, to try it and write that text
'TBD'.
Alex
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.
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...
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
.
_______________________________________________
its mailing list
its@xxxxxxxx
https://www.ietf.org/mailman/listinfo/its
|
