Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-38

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sun, 14 April 2019 16:38 UTC

Return-Path: <alexandre.petrescu@gmail.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 0ADBB120119; Sun, 14 Apr 2019 09:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 1cckUCmFuemD; Sun, 14 Apr 2019 09:38:07 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD641200DF; Sun, 14 Apr 2019 09:38:06 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3EGc1hn041979; Sun, 14 Apr 2019 18:38:01 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CFCE220323E; Sun, 14 Apr 2019 18:38:01 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B298E2028AF; Sun, 14 Apr 2019 18:38:01 +0200 (CEST)
Received: from [10.8.68.49] ([10.8.68.49]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3EGc040030530; Sun, 14 Apr 2019 18:38:01 +0200
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Cc: nabil benamar <benamar73@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com>
Date: Sun, 14 Apr 2019 18:38:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/zDeY6iQ5srlHh9XX-7cc85YvLNo>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-38
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: Sun, 14 Apr 2019 16:38:09 -0000

Brian,

Le 14/04/2019 à 04:20, Brian E Carpenter a écrit :
>>> All we need is a simple statement in the spec which puts some scope
>>> limits, w.r.t the missing ND pieces and issues.
> 
> Yes, that is clearly essential, as well as an associated health
> warning that implementers must not rush ahead because of the risk
> of non-interoperability.

There is already paragraph, and an Appendix, about potential ND issues. 
I think that text qualifies as an associated health warning.

I do not know what do you mean about the risk of interoperability.  This 
ND that works is interoperable between several OCB cards, IP Road Side 
Units, and linuces. (I can cite brands that I al familiar with and that 
interoperate.

This is the current paragraph and Appendix that qualify as a warning 
that you suggest:

>    The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
>    over 802.11-OCB links.  Transmitting ND packets may prove to have
>    some performance issues.  These issues may be exacerbated in OCB
>    mode.  Solutions for these problems SHOULD consider the OCB mode of
>    operation.  The best of current knowledge indicates the kinds of
>    issues that may arise with ND in OCB mode; they are described in
>    Appendix J.


Alex

> 
> Regards
>     Brian
> 
> On 14-Apr-19 13:58, NABIL BENAMAR wrote:
>> +1 Sri
>>
>> On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <sgundave@cisco.com <mailto:sgundave@cisco.com>> wrote:
>>
>>      I understand your point Brian, but IMO there are enough reasons not to
>>      delay this work.
>>
>>      There are many use-cases/applications where there is a stable topology of
>>      RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band allows the
>>      channel use for non-priority/non-traffic safety related applications. For
>>      example, a vehicle in a gas station can receive a coupon from the
>>      802.11-OCB radio (AP/RSU) in the gas station. There, its a stable topology
>>      that classic ND is designed for. In this operating mode, its perfectly
>>      reasonable to use classic ND and it works. The authors have shown enough
>>      lab data on the same.
>>
>>      Ideally, I agree with you that it makes lot more sense to publish both the
>>      specs at the same time. But, for what ever reasons the WG went on this
>>      path. Authors have spent incredible amount of efforts in getting the draft
>>      this far and we cannot ignore that. You can see the efforts from the
>>      version number; when did we last see a draft version -037?
>>
>>      We also need to distill the recent ND discussions and filter out the
>>      threads that are clearly motivated to insert a ND protocol that is
>>      designed for a totally different operating environment. An argument that a
>>      protocol designed for low-power environments is the solution for vehicular
>>      environments requires some serious vetting. Looking at the
>>      characteristics, always-sleeping, occasional internet connectivity,
>>      low-power, no memory, no processing power, no mobility ..etc, meeting
>>      vehicular requirements is some thing most people in the WG do not get it.
>>
>>      Bottom line, IMO, we should move this forward and publish the document.
>>      All we need is a simple statement in the spec which puts some scope
>>      limits, w.r.t the missing ND pieces and issues. There are other proposals
>>      in the WG that will address the gaps and bring closure to the work.
>>
>>      Sri
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>      On 4/12/19, 1:28 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
>>      wrote:
>>
>>      >On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
>>      >>If you go back and check 2017 archives, I did raise many of these
>>      >>issues.  But, we clearly decided to limit the scope excluding address
>>      >>configuration, DAD, ND aspect, link models. When there is such a scope
>>      >>statement, it should clearly move these comments to the draft that
>>      >>defines how ND works for 802.11-OCB links.
>>      >
>>      >This is of course possible. In general the IETF hasn't done that, but has
>>      >followed the lead set by RFC 2464 with the complete specification of
>>      >IPv6-over-foo in one document.
>>      >
>>      >However, I don't believe that publishing an RFC about the frame format
>>      >without *simultaneously* publishing an RFC about ND etc would be a good
>>      >idea. That would leave developers absolutely unable to write useful
>>      >code, and might easily lead to incompatible implementations. Since
>>      >we'd presumably like Fords to be able to communicate with Peugeots,
>>      >that seems like a bad idea.
>>      >
>>      >Regards
>>      >   Brian
>>
> 
>