Subject: Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2018 08:50:17 +1200

I see that there has been no significant change in the -23 version.
The two contradictory statements are still present:
 
>    The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB
>    links is different than over 802.11 links.  In OCB, the link layer
>    does not ensure that all associated members receive all messages,
>    because there is no association operation.  The operation of ND over
>    802.11-OCB is not specified in this document.

ND can't be both "different" and "not specified".

Also, an IPv6 spec without neighbour discovery is incomplete and seems
likely to be unusable.

Regards
   Brian Carpenter

On 17/05/2018 04:37, Suresh Krishnan wrote:
> Hi Lorenzo,
> 
> On May 14, 2018, at 9:41 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
> 
> On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
> What I understand is that multicast is highly unreliable on OCB
> (as opposed to reasonably reliable on classical 802.11).
> 
> Because you not specify how neighbours are discovered, I don't
> see how an actual IPv6 service could be provided.
> 
> If that's true then that means this document does not actually specify a feasible scheme to implement IPv6 over this network type. As such, perhaps the 6man WG should recommend that this document should not be published until it either documents a working specification or at least clearly and unambiguously documents what works and what doesn’t.
> 
> Yep. That would be the right thing to do,
> 
> 
> Suresh, chairs - what's the best way forward here? Would it be a good idea to present this document at the 6man slot in Montreal to solicit input from other participants and see if together we can come up with better text?
> 
> I’d rather not wait till the Montreal meeting if we can make progress on this document before then. I will have a discussion with the ipwave/6man chairs and the document editor to work out a way forward
> 
> Regards
> Suresh
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 14 Jun 2018 03:02:23 +0000

Hi Brian,

> On Jun 13, 2018, at 4:50 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Yep. Agree. The ipwave WG is still discussing how to move forward. I will bring the draft back to 6man for review once they make some progress in resolving the issues raised.

Regards
Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 14:06:39 +0200

Lorenzo,

Le 15/05/2018 à 03:41, Lorenzo Colitti a écrit :
> On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> If that's true then that means this document does not actually specify a 
> feasible scheme to implement IPv6 over this network type. As such, 
> perhaps the 6man WG should recommend that this document should not be 
> published until it either documents a working specification or at least 
> clearly and unambiguously documents what works and what doesn't.
> 
> Suresh, chairs - what's the best way forward here? Would it be a good 
> idea to present this document at the 6man slot in Montreal to solicit 
> input from other participants and see if together we can come up with 
> better text?

I will not come to Montreal, for various reasons.  I am sorry about that.

But I am very interested to come up with better text.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 14:12:02 +0200

Le 10/05/2018 à 06:20, Lorenzo Colitti a écrit :
> On Thu, May 10, 2018 at 8:46 AM, Brian E Carpenter 
>     No. In
>     https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22#section-4.6
>     <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22#section-4.6>
>     we find:
> 
>     >>>  In OCB, the link layer
>     >>>  because there is no association operation.
> 
>     I can only interpret that to mean that multicast does not work,
> 
> 
> I don't agree with that interpretation. I don't think there is any link 
> layer that "ensures" that all associated members receive all messages. 
> For example, regular wifi e.g., (802.11a/b/g/n/ac) certainly doesn't. 
> The AP sends the packet out on the medium, and if a given STA doesn't 
> hear it or can't decode it, it just never receives it.

Lorenzo,

I am highly interested to pursue this discussion, but some 
implementation hints may be helpful in our debate.

We know for facts that ND over OCB works fine in many contexts.  Some 
tweaks can be added to make ND more performant.  But basically it works. 
  Just put the interface up, receive an RA and then ping and watch ND 
traffic with wireshark.

But, we do not know whether a regular android smartphone can work in OCB 
mode.

That is a key point of ND over OCB.

Once we know that, we can pursue the discussion of ND over OCB.

We can provide detail instructions for free about how to make OCB work 
on other linux and cheap wifi cards.  This could be useful to an android 
developper if s/he tried to make OCB work on an android smartphone.  But 
we never tried.

Alex

---

From: [email-masked]
Date: Fri, 15 Jun 2018 08:00:59 -0700

> On Jun 15, 2018, at 5:12 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> But, we do not know whether a regular android smartphone can work in OCB mode.
> 

Why are we blocking progress due to one implementation?

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 19:52:23 +0200

Mikael,

Le 09/05/2018 à 15:27, Mikael Abrahamsson a écrit :
> On Wed, 9 May 2018, Alexandre Petrescu wrote:
> 
>> Right.  For an introduction to the OCB concept one should read the draft
>> backwards: start with Appendices B, C and D and only then read the 
>> /middle.
> 
> Ok, that could be good text to add for the introduction text.

The first phrase in the Introduction refers to Appendix B.  That 
appendix explains why it's now called OCB instead of 802.11p.

>    This document describes the transmission of IPv6 packets on IEEE Std
>    802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see
>    Appendix B).

Would you like that we refer also to Appendix C and D, which are titled 
"Aspects introduced by the OCB mode to 802.11" and "Changes Needed on a 
software driver 802.11a to become a 802.11-OCB driver"?

Otherwise, know that in the IPWAVE WG the person François Simon is ready 
to do the necessary to better explain OCB.
[...]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 19:59:20 +0200

Mikael,

[...]

> It's my opinion that putting in MIB somewhere in the text without 
> further references makes it really hard to understand what's going on.

I suggest to insert the following in Appendix B, do you agree?

OLD:
> Appendix B.  802.11p
> 
>    The term "802.11p" is an earlier definition.  The behaviour of
>    "802.11p" networks is rolled in the document IEEE Std 802.11-2016.
>    In that document the term 802.11p disappears.  Instead, each 802.11p
>    feature is conditioned by the Management Information Base (MIB)
>    attribute "OCBActivated".

NEW:
> Appendix B.  802.11p
> 
>    The term "802.11p" is an earlier definition.  The behaviour of
>    "802.11p" networks is rolled in the document IEEE Std 802.11-2016.
>    In that document the term 802.11p disappears.  Instead, each 802.11p
>    feature is conditioned by the IEEE Management Information Base (MIB)
>    attribute "OCBActivated".

(remark addition of the word 'IEEE').

[...]
>>> I tried to figure out how the entire thing is supposed to work, but 
>>> failed. There is text about router advertisement sent from an ANR 
>>> (Access network Router). I have no idea what this is or how it's 
>>> supposed to be deployed.
>>
>> Well, we struggled to use a term to stand for a router along the road to
>> which the car connects, hands over to, from.  The ANR term is from
>> RFC3753.  Other proposals were made, like Road-Side Unit, or Router -
>> each with its own difficulties.
>>
>>> Two cars out on the road in the middle of nowhere, are they not going
>>> to be able to talk to each other?
>>
>> YEs yes, they should.  The presence of an ANR is not mandatory in order
>> for two cars to talk to each other.
>>
>> Maybe we should clarify saying: "the presence of an IP-RSU, or an ANR,
>> is not mandatory in order for two cars to communicate directly"?
> 
> That's a good clarification to make in the document, yes.

Rather, I suggest we leave that clarification out of the document at 
this time.

I hope there will be other work about to specify how two cars 
communicate to each other directly.

[...]
>>> These kinds of basic questions in understanding how everything is 
>>> supposed to work is hindering ability to be able to comment on the 
>>> document in any meaningful way.
>>
>> I think this is a request for some sort of addressing architecture
>> document, with an example deployment?
>>
>> But, RFC2464 (a classic IPv6-over-foo document) does not describe such
>> an example.  So why should this IPv6-over-foo document do it?
> 
> Sure, and you do reference section 5 for link-local in the document. In 
> 4.6 of the OCB document there is talk about forming a subnet. I think 
> there should be wider explanation about what this means. Is this like a 
> "bubble" around the car? Is it really a subnet then?

I think we should leave this explanation out of this document.  I think 
we should write a separate document about the bubble and subnets areound 
the car.

I kindly invite you to participate in the discussion in the IPWAVE WG 
about this topic.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jun 2018 11:17:12 +1200

> Why are we blocking progress due to one implementation?

Well, the fact that the explanation of how ND and SLAAC actually work
on OCB is incomplete is really what's blocking progress. Alexandre
has said that ND has been observed to work (he didn't mention SLAAC,
but I guess it must have worked too). But I still can't reconcile that
with the explanation that OCB nodes missing packets is a normal, rather
than exceptional, situation. How does ND work when there's a radio-frequency
barrier between two nodes?

With that explained, I imagine that the Android team could decide whether
to support IPv6 over OCB. I agree with you that this is not an IETF
matter; our business is to publish a complete spec.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Jun 2018 09:02:36 -0400

> barrier between two nodes?

It sounds like they need to profile RFC6775 or
https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/

They solve ND when broadcast is not complete.
However, they depend upon having a deice to keep track of things.
That it turn is facilitated (but not required) by having a routing protocol
that creates an DAG and creates an up direction which makes it obvious
where the DAR/DAC packets go to/come-from.

This might be a problem in a regularly changing convoy, but shouldn't be a
problem within a vehicle.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Jun 2018 19:28:17 +0200

Le 16/06/2018 à 15:02, Michael Richardson a écrit :
> [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT DANGEREUSES]
> 
> Ce message contient des pieces jointes potentiellement dangereuses car susceptibles de contenir des virus. Pour lutter contre l'expansion de ce type d'attaque, les documents [null] ont ete retires du message original ci-dessous. Pour les documents Office, le CEA recommande l'usage exclusif des formats plus recents exempts de macros comme DOCX, XLSX, PPTX, merci de le signaler a votre expediteur.
> 
> Pour de plus amples informations ou pour connaitre les mecanismes de mise en quarantaine, vous pouvez vous rapprocher de votre service informatique ou consulter le site USCIpedia - rubrique PureMessage.
> 
> ----------------MESSAGE ORGINAL ci-dessous------------------
> 
> 

If we want to profile something, we would need first to have a problem. 
What is the problem?

As a side note, for my part I do not approach RFC6775 "Registration 
Extensions for 6LoWPAN Neighbor Discovery" because OCB is not 6lowPAN.

These two technologies are very much different: different frequencies, 
ranges, application goals and more.  Nobody thinks of using 6lowpan to 
communicate between moving cars.  You could if you wanted to play, but 
not sure why.  It's like working on ATM and somebody points rather to FDDI.

Ironical: of course, we could also block an RFC because it does not 
refer to all other RFCs.  Irony ended.

Alex

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Jun 2018 13:39:37 +1200

> If we want to profile something, we would need first to have a problem. 

How does ND work when there's a radio-frequency barrier between two nodes?
 
   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 17 Jun 2018 17:41:56 +0200

> How does ND work when there's a radio-frequency barrier between two nodes?

A PHY barrier will be avoided with a PHY mirror.  In some context people 
put PHY mirrors in the middle of the intersection.  In others the 
mirrors are naturally on the building walls along the road.  It is also 
possible that there are no PHY mirrors, at which point ND will break. 
Because neither multicast nor unicast work when there are PHY barriers.

Is RFC6775 offering PHY mirrors?

(a PHY mirror is like the disco club mirrors on globe for IrDA 
technology; for 5.9GHz it is a Road-Side Unit with a repeating bridge)

Alex