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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 16 April 2019 15:42 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 437761204C3; Tue, 16 Apr 2019 08:42:34 -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 sEuZV4_nMBGw; Tue, 16 Apr 2019 08:42:31 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 A9CD5120A7A; Tue, 16 Apr 2019 07:07:58 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3GE7nIn029925; Tue, 16 Apr 2019 16:07:49 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 514D2205708; Tue, 16 Apr 2019 16:07:49 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3279E202169; Tue, 16 Apr 2019 16:07:49 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3GE7nXn017469; Tue, 16 Apr 2019 16:07:49 +0200
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, nabil benamar <benamar73@gmail.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> <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com> <11645738-6f95-82e5-48f1-ebc3ce54423e@gmail.com> <0ae10089-4b1a-f85c-1a3d-15e712cb7547@gmail.com> <084449fd-2693-0cfb-6589-0cf67cf9ffe6@gmail.com> <D8DA8E15.2F2F73%sgundave@cisco.com> <CFBFE5D0-E623-4508-BD57-5BD0C3CED985@cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <69b9071f-80c7-63c8-bb02-3fb439b2cf5b@gmail.com>
Date: Tue, 16 Apr 2019 16:07:48 +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: <CFBFE5D0-E623-4508-BD57-5BD0C3CED985@cisco.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/5ZSnwtjWT--NoRdF1QGMvGR5Vts>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-39
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: Tue, 16 Apr 2019 15:42:35 -0000


Le 16/04/2019 à 12:06, Pascal Thubert (pthubert) a écrit :
> Hello Sri
> 
> If the document was clearly scoped to P2P link local communication it
> would need correcting, like stop paraphrasing IEEE but it would
> eventually pass.

I do not know what do you mean by P2P.

In my experiments we also used three cars with IP on a single subnet OCB.

The term I may be using is something like

       P
      P2P

if such a multidimensional term can exist.


> Beyond that scope it is a matter of use cases and solutions. I do not
> know what the WG decided for the former. The latter starts with
> applicability of existing work, in particular WiND.
> 
> If the group needs such functions I claim that we can already do hub
> and spoke subnets with either a single node as hub (a BSS at L3) or
> several nodes (that would be RSUs) connected by a high speed transit
> link. This can be done using Wireless ND and can be described in a
> few pages.
> 
> I claim we can already do mesh in relatively stable situations, e.g.,
> relaying over cars in a parking lot to the RSU that provides
> Internet.

It's great to know.

Did it use OCB?

(we define IP-RSU to be an RSU that does OCB.)

Alex

> 
> I claim we can couple that with NEMO in the car and maintain global
> reachability while on the road.
> 
> What’s harder is to figure what’s reachable at which time. DNA and
> when to form new addresses. Discover services. How to use the fixed
> infrastructure to relay between cars while driving. These are some of
> the real and interesting problems left to be solved by the WG whereas
> reinventing the wheels could be a waste of time.
> 
> All the best,
> 
> Pascal
> 
> Le 16 avr. 2019 à 05:11, Sri Gundavelli (sgundave)
> <sgundave@cisco.com> a écrit :
> 
>>> I am no expert, but I do know some physics, and it seems pretty
>>> clear to me that if there are multiple lanes of traffic, a large
>>> truck can easily shield signals between two cars and the
>>> shielding will be intermittent, regardless of how much wireless
>>> power is allowed, depending on traffic movement. So it's a highly
>>> dynamic mesh network.
>> 
>> 
>> Part of the problem is that we have not clearly put some limits on
>> the use-cases. These unbounded limits is opening up these
>> discussions on ad-hoc full mesh network formations and the
>> resulting challenging ND scenarios. But, again I always assumed
>> this discussion is for the ND document and there should be no
>> bearing on this document.
>> 
>> V2X communications involves V2V, V2I and V2P communication modes.
>> From the point of view of vehicular safety, its about exchange of
>> BSM (Basic Safety Messages) between vehicles as per SAEJ735
>> standard. These safety communications is always one-hop
>> communication and for very good reason IEEE WAVE standards did not
>> bother to require IPv6 transport for carrying these messages. The
>> WSMP message which carries these safety elements are defined to be
>> carried over layer-2 payloads. Personally, I never thought we will
>> replace this L2 safety communication mode with layer-3 mode 
>> (IPv6-over-80211-OCB). But the use of IPv6 is more for allowing 
>> applications in the vehicle to communicate with the infrastructure.
>> For example, a vehicle using DSRC radio to access some traffic
>> application in the cloud.
>> 
>> In one sense, this is like a mobile node using 802.11-OCB like any
>> other radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its
>> communications. In this context, its always about vehicle to
>> infrastructure communications. Now, there are other interesting
>> peer to peer use-cases, where one vehicle is streaming some video
>> to another vehicle without using any infrastructure. While these
>> later examples are very cool, personally, I did not expect this WG
>> to solve those use-cases day-1. For us to support those use-cases,
>> we need to figure out many more things including approaches for
>> exchanges prefixes between two vehicles that come in proximity. In
>> my mind, these are very forward looking and the only relevant
>> application is platooning. I am not interested in solving this V2V
>> problem, but was more interested to enable V2I communications,
>> where the focus is about link model, prefix hosting approaches,
>> mobility support (building a large L2 domain over RSU’s, or routed
>> approaches with mobile IP type protocols) ..etc. In one
>> realization, there may be a P2P link assumption between the vehicle
>> and the RSU, eliminating most of these ND issues. But, those
>> discussions are for the other document and that clearly should
>> remove these ND concerns from this document.
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> On 4/15/19, 2:04 PM, "Brian E Carpenter"
>> <brian.e.carpenter@gmail.com> wrote:
>> 
>>> Excuse top posting.
>>> 
>>> As I've said, I am no expert, but I do know some physics, and it
>>> seems pretty clear to me that if there are multiple lanes of
>>> traffic, a large truck can easily shield signals between two cars
>>> and the shielding will be intermittent, regardless of how much
>>> wireless power is allowed, depending on traffic movement. So it's
>>> a highly dynamic mesh network. That's a very interesting problem
>>> that has been much studied, and it's fundamentally different from
>>> the ND design scenario.
>>> 
>>> So I find it hard to believe that nobody can write the TBD text.
>>> 
>>> Regards Brian
>>> 
>>>> On 15-Apr-19 23:26, Alexandre Petrescu wrote: Hi Brian,
>>>> 
>>>>> Le 14/04/2019 à 22:49, Brian E Carpenter a écrit : Hi
>>>>> Alexandre,
>>>>> 
>>>>>> On 15-Apr-19 04:38, Alexandre Petrescu wrote: 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.
>>>>> 
>>>>> That's exactly the text that I find problematic. I can't
>>>>> write a new version because I lack your expert knowledge, but
>>>>> IMHO it should be more specific:
>>>>> 
>>>>> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST
>>>>> be used over 802.11-OCB links.  However, as on any wireless
>>>>> link, transmission of multicast ND packets may fail in OCB.
>>>>> In particular, scenarios where TBD TBD TBD are likely to be
>>>>> unreliable and SHOULD NOT be deployed until an alternative
>>>>> standardised solution is available. The best of current
>>>>> knowledge indicates the kinds of issues that may arise with
>>>>> ND in OCB mode; they are described in Appendix J.
>>>> 
>>>> I can agree with that formulation and put it in the text.
>>>> 
>>>> But I need an indicat that TBD is defined soon.  The time
>>>> commitments of Pascal seem to be saying he is no longer
>>>> interested in writing that TBD.
>>>> 
>>>> I wait a little for this to clarify.
>>>> 
>>>>> Also I don't like this phrasing in Appendix J:
>>>>> 
>>>>> Early experiences indicate that it should be possible to
>>>>> exchange IPv6 packets over OCB while relying on IPv6 ND alone
>>>>> for DAD and AR (Address Resolution).
>>>>> 
>>>>> Could you rather say the opposite:
>>>>> 
>>>>> Early experience indicates that it is possible to exchange 
>>>>> IPv6 packets over OCB while relying on IPv6 ND alone for DAD
>>>>> and AR (Address Resolution) in good conditions. However, this
>>>>> does not apply if TBD TBD TBD...
>>>> 
>>>> This is an appendix.  I could put TBD there now.
>>>> 
>>>> Alex
>>>> 
>>>>> 
>>>>> Regards Brian
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> .
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>