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

Russ Housley <housley@vigilsec.com> Wed, 29 May 2019 21:39 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AC7120094 for <its@ietfa.amsl.com>; Wed, 29 May 2019 14:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK_U5w7MpChy for <its@ietfa.amsl.com>; Wed, 29 May 2019 14:39:11 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EE91201D8 for <its@ietf.org>; Wed, 29 May 2019 14:39:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EC71300AA8 for <its@ietf.org>; Wed, 29 May 2019 17:19:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R7udtiLKmfdZ for <its@ietf.org>; Wed, 29 May 2019 17:19:49 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B066300A0B; Wed, 29 May 2019 17:19:49 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <53B60400-7A82-483F-A580-424D9714AB0B@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E67DC8CE-752D-4AA7-8AA4-EA7D337C8FF2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 29 May 2019 17:39:06 -0400
In-Reply-To: <MN2PR11MB35651333D728E6340704E5E2D81F0@MN2PR11MB3565.namprd11.prod.outlook.com>
Cc: "its@ietf.org" <its@ietf.org>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <MN2PR11MB35654179C2A7114D18F9C1C7D81E0@MN2PR11MB3565.namprd11.prod.outlook.com> <FA0E8622-BA32-4462-A93C-3C8F4990525D@vigilsec.com> <MN2PR11MB35651333D728E6340704E5E2D81F0@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/jLVVkc4xOuUfCkNA0CafAbii-QU>
Subject: Re: [ipwave] Title of draft-ietf-ipwave-ipv6-over-80211ocb-45
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 21:39:16 -0000

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) <pthubert@cisco.com> 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 <housley@vigilsec.com <mailto:housley@vigilsec.com>>
> Envoyé : mercredi, mai 29, 2019 10:51 PM
> À : Pascal Thubert (pthubert)
> Cc : its@ietf.org <mailto:its@ietf.org>
> 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) <pthubert@cisco.com <mailto:pthubert@cisco.com>> 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 <benamar73@gmail.com <mailto:benamar73@gmail.com>>
>> Cc: its@ietf.org <mailto:its@ietf.org>
>> 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 <benamar73@gmail.com <mailto:benamar73@gmail.com>> 
>> Sent: lundi 27 mai 2019 17:12
>> To: Pascal Thubert (pthubert) <pthubert@cisco.com <mailto:pthubert@cisco.com>>
>> Cc: its@ietf.org <mailto:its@ietf.org>
>> 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) <pthubert@cisco.com <mailto:pthubert@cisco.com>> 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.