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

[Russ Housley <[e-mail]>]

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] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[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] <mailto:[e-mail]>> 
> Sent: lundi 27 mai 2019 17:12
> To: Pascal Thubert (pthubert) <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[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] <mailto:[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.