Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

[Nabil Benamar <[e-mail]>]

Hi Pascal,

We are converging :)

See below


Best regards
Nabil Benamar
-------------------
نبيل بنعمرو



On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hello Nabil:
>
>
>
> I removed the places where we already agree. Please see below for the
> remaining details
>
>
>
> Ø  This should be out of scope and inherited from IPv6 over WiFi. If the
> draft does not exist then let us do one, at 6MAN.
>
> Yes, I support this idea to initiate a new draft in 6MAN. I'm in!

> Ø  The introduction should clatify the scope, which appears to be do with
> what existing stacks can do and (sometimes) see what’s missing.
>
> Here is the new introduction (first paragraph), are we missing something
else?

"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, Appendix C and Appendix D). This involves the layering

of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC

layer. Compared to running IPv6 over the Ethernet MAC layer, there

is no modification expected to IEEE Std 802.11 MAC and Logical Link

sublayers: IPv6 works normally over a single IEEE 802.11-OCB link,

with an LLC layer. Multi-link scenarios are out of scope for the

present document."


>
>
> Pascal, I have just received a detailed review from some IEEE-802.11
> members, thanks to Dorothy! One of the recommendation is to remove section
> 4.2.1 completely.
>
>
>
> Ø    Good, we are converging.
>
>
>
>
>
>
>
> I agree. It seems that by describing specific values, the text is
> redundant with what’s already in IEEE Std 802.11-2016
>
>
>    - In the <reference> tag to the IEEE spec just use <date/> . This
>    actually removes the date. Also please remove -2016 from the spec name,
>    just leave generic 802.11 dateless.
>
> Ok.

>
>    -
>    - Placing a date is misguided since we do not have a dependency on one
>    particular version of 802.11. Indeed we want your spec to apply to all
>    versions starting current, which is what is implied by dateless.
>
> That's perfect.

>
>    -
>
>
>
>
>
>
>
> Ø  Are we sure of that, don’t we map QoS from ToS bits as usual with 11e?
>
>
>
> Here is the new text to replace that paragraph:
>
>
>
> " “The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
> by a Logical Link Control (LLC) header and an 802.11 header. In the LLC
> header, and in accordance with the EtherType Protocol Discrimination (EPD,
> see Appendix E
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>),
> the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to
> the 802.11 data service MUST use a ‘priority’ value of 1, which specifies
> the use of QoS with a “Background” user priority."
>
>
>
> Ø    Can’t we use different QoS values like we can on WiFi?
>
That was the recommendation of IEEE 802.11 members, and I updated the draft
based on your review and their recommendations. Please feel free to suggest
other text here.

>
>
>
>
>
>
>    To simplify the Application Programming Interface (API) between the
>
>    operating system and the 802.11-OCB media, device drivers MAY
>
>    implement an Ethernet Adaptation Layer that translates Ethernet II
>
>    frames to the 802.11 format and vice versa.  An Ethernet Adaptation
>
>    Layer is described in Section 4.2.1.
>
>
>
> Ø  Do not call that an adaptation layer. The may refers to using an
> Ethernet stack and then a translation from Ethernet Frames to 802.11 frames
> as specified by IEEE.
>
> What do you suggest instead?
>
>
>
>
>
> Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464
> and then a frame translation from 802.3 to 802.11 in order to  minimize the
> code changes”.
>
> Ø    If minimal impact on the stack is the actual goal of this draft,
> which I think it is. This is what justifies publish this hastily and then
> do the real work that implies larger changes.
>
> Ø
>
Sounds good for me!

>
>
>
>
>
>
>
>
> 4.4.  Stateless Autoconfiguration
>
>
>
>    There are several types of IPv6 addresses [RFC4291], [RFC4193], that
>
>    MAY be assigned to an 802.11-OCB interface.  This section describes
>
>    the formation of Interface Identifiers for IPv6 addresses of type
>
>    'Global' or 'Unique Local'.  For Interface Identifiers for IPv6
>
>    address of type 'Link-Local' see Section 4.3.
>
>
>
> Ø  Not really interesting. More important is to say that autoconf is
> defined in RFC 4862 and that is missing.
>
> Didn't get your point! What is missing?
>
>
>
>
>
>
>
> Ø    IPv6 autoconf is described in RFC 4862. This section does not refer
> to it, but rather duplicates the previous about address types, which is far
> from interesting.
>
> Ø    I suggest you remove the text above and add a sentence that roughly
> introduce RFC 4862. Note that RFC 8505 does not change the
> autoconfiguration though it changes the way DAD is achieved.
>
>
>
>
>
> Ok. I will include it in -46
>
>
>
>
>
> Ø  MUST +> MAY. Say the scope of this doc only considers ND but neither
> RFC 8505 nor IPWAVE drafts.
>
>
>
> Here is the new text as agreed last time with Brian:
>
>
>
> "The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be
>
> supported over 802.11-OCB links."
>
>
>
>
>
>
>
> Ø   Yes, that works.
>
>
>
>
>
> Ø  Remove or turn it the other way around like future solutions to OCB
> should consider solutions for avoiding broadcast.
>
> I will reformulate in the following manner:
>
>
>
> Transmitting ND packets may prove to have some performance issues.  These
> issues may be exacerbated in OCB
>
>    mode.  Future solutions to OCB should consider solutions for avoiding
> broadcast.  The best of current knowledge indicates the kinds of issues
> that may arise with ND in OCB mode; they are described in Appendix J.
>
>
>
>
>
> Ø    Good
>
>
>
>
>
>
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
>
>
> Thank you once again.
>
>
>
> I will publish version 46 soon.
>
>
>
>
>
>
>
> Ø    Please ping me when done; do not forget to scope the document so
> that it is minimizing changes to existing stack and leveraging Ethernet
> implementation, with IPv6 ND and so on, and a focus on P2P over link local.
>
>
>
> All the best,
>
>
>
> Pascal
>

Thank you, Pascal for your time.