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

[Nabil Benamar <[e-mail]>]

Hi Russ, Pascal


That was exactly what I was thinking about the "minimal" term in the title!

'Basic'...works for me.

On Wed, May 29, 2019, 21:39 Russ Housley <[e-mail]> wrote:

> I worry that "minimal" sounds like something was left out, but that is not
> the case.
>
> Russ
>
>
> On May 29, 2019, at 5:21 PM, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
>
> On second thoughts basic reads as barebone but in fact the Ethernet stack
> is complex. What we do is minimal changes to it.
>
> So why exactly does basic seem better to you Russ?
>
> Pascal
>
> ------------------------------
> *De :* Russ Housley <[e-mail]>
> *Envoyé :* mercredi, mai 29, 2019 10:51 PM
> *À :* Pascal Thubert (pthubert)
> *Cc :* [e-mail]
> *Objet :* Re: Title of draft-ietf-ipwave-ipv6-over-80211ocb-45
>
>
> Pascal, I think that Basic support ..." would be a better title.
>
> Rus
>
>
> On May 28, 2019, at 9:52 AM, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
>
> Dear all:
>
> Nabil and I are converging on the draft. One open item that deserves the
> group’s attention is the title.
>
> The current title seems to indicate that the draft is **the** way of
> doing IPv6 over OCB when in fact it is the way to do that with minimal
> change to existing stacks.
> As written, it indicates that IPWAVE is done and can close when in fact
> the work is just starting with 8 other drafts in progress. My suggestion is
> to change the title to add Minimal in it like we did multiple times at
> 6TiSCH.
>
> Suggestion: change the title to:
>
> Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside
> the Context of a Basic Service Set
>
> This leaves opening for draft-jeong-ipwave-vehicular-mobility-management,
> draft-jeong-ipwave-vehicular-neighbor-discovery, and so on.
>
> Does that make sense?
>
> Pascal
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mardi 28 mai 2019 10:49
> *To:* Nabil Benamar <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* RE: [ipwave] rereview of
> draft-ietf-ipwave-ipv6-over-80211ocb-45
>
> Hello Nabil:
>
> In the next rev I expect to see text in the intro that states the scope of
> reusing legacy stacks with minimal changes.
>
> Expressed that way, the discussion on legacy ND only and using the
> Ethernet distribution system and then a frame translation to 802.11, all
> makes full sense.
> Also, this prepares for the work that the group has already started, which
> involves new stack elements better suited for OCB.
>
> This should also be in the title. Suggestion for the new title:
>
>
> Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside
> the Context of a Basic Service Set
>
>
> The ‘minimal’ avoids the risk that the reader thinks that this draft has
> it all and that IPWAVE can close after that.
>
> All the best,
>
> Pascal
>
> *From:* Nabil Benamar <[e-mail]>
> *Sent:* lundi 27 mai 2019 17:12
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [ipwave] rereview of
> draft-ietf-ipwave-ipv6-over-80211ocb-45
>
> 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.
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>