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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 15 April 2019 08:04 UTC

Return-Path: <pthubert@cisco.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 E320E1200EA; Mon, 15 Apr 2019 01:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=G8Bo8VjK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FplEvqyB
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 2bsauKFF7UB6; Mon, 15 Apr 2019 01:04:50 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF20112009C; Mon, 15 Apr 2019 01:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11032; q=dns/txt; s=iport; t=1555315489; x=1556525089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cOMzFaJGSYo9StOl4WDlWu9lHqk40VhlxCgZIjPfmZE=; b=G8Bo8VjKG3zzu4Fbd/MWu4OY5SzSOGKK79YJiqfb24gkanyjRrNhZ2/F aL9Cd6XLxft7ZCm+Nu1BDjQvM6IauuCmXla/yFw/hGyNbYejXCI2tZym+ mFTMyAmOqJy0SheZPmtLdAo+AMXXJ9buZqTGbXWxQIKdyYzCSkOAHNk8m I=;
IronPort-PHdr: 9a23:JsVD8BMsCkQBMLfYa3wl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQAADaObRc/5hdJa1mGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBPSknA4E1CCAECyiEDoNHA4RSikKCV4k5jWGBLoEkA1QOAQEthEACF4VsIzQJDgEDAQEKAQIBAm0cDIVKAQEBAQMjEQwBATcBCwQCAQgRAQMBAQECAiMDAgICHxEUAQIGCAIEDgUIE4RxAxwBAp86AooUcYEvgnkBAQWEeQ0Lgg0JgQsnAYRghmkXgUA/gRFGgkw+ghqBdg4KHhWCczGCJox9LIwbjDs2CQKCBY5Og2OUc5NYjCkCBAIEBQIOAQEFgU84gVZwFYMnggoMF4EBAQeCQ4pTcgGBKIx4glEBAQ
X-IronPort-AV: E=Sophos;i="5.60,352,1549929600"; d="scan'208";a="258328605"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Apr 2019 08:04:48 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x3F84mQG010574 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Apr 2019 08:04:48 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Apr 2019 03:04:47 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Apr 2019 04:04:47 -0400
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 15 Apr 2019 04:04:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cOMzFaJGSYo9StOl4WDlWu9lHqk40VhlxCgZIjPfmZE=; b=FplEvqyBdpsWOd9QMSRrRfeUMY59AjpzWNwmtGUIhvDHowIJdbBcmD3AY6GtsOdhiAEAK+9MfYNzuCsuUBKjpkzk4SHvMNAs/+x47FJUPlBzYZ7zwRDSx8f0m0I+KzS7OlAkvrVraXXlh6Oj1wp3+Uu/YJUtYMT3YA/vKgzWQe8=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4029.namprd11.prod.outlook.com (10.255.181.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Mon, 15 Apr 2019 08:04:45 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::8cde:9e01:ad20:d10e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::8cde:9e01:ad20:d10e%6]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 08:04:45 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, 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>
Thread-Topic: draft-ietf-ipwave-ipv6-over-80211ocb-38
Thread-Index: AQHU8uB47wSvmnV4qUCARpvTvUXPxaY8yiX5gAALrwCAAAT40A==
Date: Mon, 15 Apr 2019 08:04:21 +0000
Deferred-Delivery: Mon, 15 Apr 2019 08:03:48 +0000
Message-ID: <MN2PR11MB35658CB3A6C8F6B8BCA90505D82B0@MN2PR11MB3565.namprd11.prod.outlook.com>
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> <5326B3E6-4C75-4ACA-9280-1BD3D214FD09@cisco.com> <227d335c-3ec5-aa21-69e1-9cd33a2dea78@gmail.com>
In-Reply-To: <227d335c-3ec5-aa21-69e1-9cd33a2dea78@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c6c8996a-2b63-4dd2-eed4-08d6c17905e1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4029;
x-ms-traffictypediagnostic: MN2PR11MB4029:
x-microsoft-antispam-prvs: <MN2PR11MB4029A2BD0AA7FEF532AC0720D82B0@MN2PR11MB4029.namprd11.prod.outlook.com>
x-forefront-prvs: 000800954F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(136003)(39860400002)(199004)(189003)(13464003)(106356001)(7696005)(93886005)(54906003)(6666004)(66574012)(99286004)(316002)(2906002)(97736004)(52536014)(71200400001)(5660300002)(105586002)(33656002)(68736007)(8676002)(71190400001)(46003)(6246003)(6916009)(102836004)(14454004)(7736002)(229853002)(6116002)(81166006)(81156014)(256004)(14444005)(55016002)(476003)(11346002)(25786009)(305945005)(8936002)(6436002)(53936002)(74316002)(486006)(86362001)(76176011)(446003)(9686003)(186003)(4326008)(6506007)(53546011)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4029; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ikHdnABcLv/8j6FL15UAo/vBMIDN38rABZRv65WCrQqhpCddgOrMkMQKk+5n0HosM5QkKqF3fbIVKeGnapKo0H9wlWjGaYHIP3fdJS7v2Li41sqVSycJh6FfjAxs9jnRy/2706HDDqxriLQ/bWndI0r3CEpuVYsH3SW/GJzK29pKN9ss5hWQH4voAN5XuiIS737T03s8ikFxKMvBJUhl0WHTA6mb5OxTnenUHgogjN4KhYoYIoUQfMRGShKxpmUu15AoA1dnbJNQw+G+MalPJn6HOpjkr+cs+3jD1wGHrDPLtEZsU4L2kRNJQ2dDHnnakcRBL3lbCCx0RwBJaEqqz4LOl1rmooCD5VzFruF9VZM5Qzw7B/CrQqICyVNTL4t9+wv+oCk8XkMCXQwmXntQgpZtzk6kToeyRI8A7q5VzIc=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c6c8996a-2b63-4dd2-eed4-08d6c17905e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 08:04:45.1468 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4029
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/XZuWDWiJXHgfk6mHCs7VwqBVYf0>
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: Mon, 15 Apr 2019 08:04:53 -0000

Hello Alexandre.

I hoped I was clear before. 

Take 4 cars, A, B, C, D separated by 100 meters each, such that all can hear C, though A has a bad quality, and A and D are too far apart. C advertises a prefix in RA(PIO), all can hear it. 

- Try pinging A from D using the address based on that prefix, won't ping. 
- Try configuring A's address on D it will be accepted, which means that DAD will not work either. 

This is nothing new, common to all the short/middle range radios we have looked at. You may try the same placing C at the corner of a street, A and D in orthogonal streets.
This has nothing to do with low power and everything to do with radio propagation.
The exception is Wi-Fi, and that's because the BSS emulates the broadcast domain, as I think I explained already.
RFC 8505 recreates the Wi-Fi design but at L3... and the use cases above were made to work on other radios with similar properties. More in the 6TiSCH architecture I guess...

Sorry you consumed all the time I could dedicate, and more.

All the best,

Pascal

> -----Original Message-----
> From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Sent: lundi 15 avril 2019 15:35
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; NABIL BENAMAR
> <n.benamar@est.umi.ac.ma>; Sri Gundavelli (sgundave)
> <sgundave@cisco.com>; nabil benamar <benamar73@gmail.com>;
> ietf@ietf.org; its@ietf.org; int-dir@ietf.org; draft-ietf-ipwave-ipv6-over-
> 80211ocb.all@ietf.org
> Subject: Re: draft-ietf-ipwave-ipv6-over-80211ocb-38
> 
> Pascal - do you know of a OCB use and some scenario where ND does not
> work?
> 
> (I mean some trials that you may have done with OCB; if you never played with
> OCB and wiht IP on it, I think it makes no sense to describe speculations of it).
> 
> Alex
> 
> Le 15/04/2019 à 08:53, Pascal Thubert (pthubert) a écrit :
> > This text is wrong, Alexandre.
> >
> > There is a distinction between performance issue and does not work. You
> can not MUST a protocol that by design will only work in a subset of the
> possible situations.
> >
> > What you can do is document in which situations it can be made to work
> (P2P and full overlap of the broadcast domains) and explain the drawbacks (eg
> if broadcast is sent at higher power or slower phy then it impacts unicast
> communications).
> >
> > Then you want to open the door to using more suitable techniques in future
> documents, which the MUST seems to discourage.
> >
> >
> > Regards,
> >
> > Pascal
> >
> >> Le 14 avr. 2019 à 18:38, Alexandre Petrescu
> <alexandre.petrescu@gmail.com> a écrit :
> >>
> >> 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
> >>>>