From nobody Tue Jan 2 10:26:32 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBAA12D7F1; Tue, 2 Jan 2018 10:26:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Carlos Bernardos" , "Russ Housley" Cc: Terry Manderson , IP Wireless Access in Vehicular Environments Discussion List , Elizabeth.Perry@sae.org, Russ Housley , Carlos Bernardos , Keith.Wilson@sae.org, Suresh Krishnan X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151491759052.22648.11984709015990586689.idtracker@ietfa.amsl.com> Date: Tue, 02 Jan 2018 10:26:30 -0800 Archived-At: Subject: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 18:26:30 -0000 Title: LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces Submission Date: 2018-01-02 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1552/ From: Jim Misener To: Carlos Bernardos ,Russ Housley Cc: Russ Housley ,Terry Manderson ,Carlos Bernardos ,IP Wireless Access in Vehicular Environments Discussion List ,Suresh Krishnan Response Contacts: Elizabeth.Perry@sae.org, Keith.Wilson@sae.org Technical Contacts: Purpose: For information Body: 1. Overall Description: The SAE Cellular V2X Technical Committee (C-V2X TC) was formed in June, 2017 with the following charter: The SAE Cellular V2X Technical Committee reports to the Vehicle Engineering Systems Group of the Motor Vehicle Council. The Committee is responsible for adapting, developing and maintaining SAE Standards, Recommended Practices, and Information Reports that use cellular radio access technologies and specifically, evolving 4G LTE and 5G cellular technologies that require interoperability and performance standards for road vehicles and other road users in order to use the full capabilities of these technologies. The committee also coordinates task force efforts to ensure efficient development and delivery of SAE documents, acts as liaison to the other organizations involved in the with vehicular-oriented cellular standards and deployments, and organizes efforts in gathering requirements for SAE standardization and assigns them to distributed task forces. The C-V2X Technical Committee will work closely with the SAE DSRC Technical Committee and with their documents to assure efficient reuse and adjustment as appropriate, e.g., strive to maintain a single data dictionary. Participants in the SAE C-V2X TC include vehicle OEMs, vehicle suppliers, mobile network operators, mobile network operator equipment suppliers, mobile handset manufacturers, chipset manufacturers, road operators, traffic equipment suppliers, consulting firms, government, and other interested parties. At the current time, three Task Forces constitute the C-V2X TC. The Task Forces and charters are: CV2X Advanced Applications Task Force: Develop definitions of terms, use cases, recommended practices, guidelines, test methods, specifications and performance standards for vehicles connected using C-V2X, focusing on advanced V2X applications (i.e., applications that cannot be supported by DSRC and Rel-14 LTEV2X) that deal with 5G (3GPP NR and LTE evolution) to leverage enhanced mobile broadband, use of millimeter wave and other anticipated radio access technologies, and the next generation core network including enablers such as NFV/SDN, edge computing, and network slicing. The task force will encourage research in these areas, and sponsor and facilitate the development of related standards. The work of this task force will be coordinated with other task forces in C-V2X Technical Committee, as well as other V2X related technical committees and standards organizations such as 3GPP, ATIS, GSM Association, DSRC Technical Committee, On-Road Automated Driving (RAD) Technical Committee, ITU-T and ETSI. CV2X Direct Communication Task Force: Develop definitions of terms, use cases, recommended practices guidelines, test methods, specifications and performance standards for vehicles connected using C-V2X, focusing on safety applications that include cooperative awareness, warning notification, safe lane change, safe intersection and roundabout crossing, etc. Important topics of security, reliability, and quality of service will be part of the charter. The task force will encourage research in these areas, and sponsor and facilitate the development of related standards. The work of this task force will be coordinated with other task forces in CV2X Technical Committee, as well as other V2X related technical committees and standards organizations such as DSRC Technical Committee, On-Road Automated Driving (RAD) Technical Committee, 3GPP, ISO, ITU-T and ETSI. CV2X Road Operators Task Force: Work with the ground transportation operating community to identify its high-level needs and develop standards, recommended practices, and information reports to address those needs. 2. Actions: To (SDOs and industry organizations): ACTION: The SAE C-V2X welcomes mutual consideration and communication as we jointly standardize applicable interoperability and performance specifications to fully leverage 4G LTE and 5G cellular radio access technologies. 3. Date of Next SAE C-V2X Meetings: 3rd Wednesday of every month, 1000 Eastern Time US WebEx 14-15 March, 2018 Southeast Michigan or Newark NJ (TBD) Attachments: SAE 12302017-1- LS Announcing SAE C-V2X v2final.pdf https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-02-sae-cell-v2x-ipwave-ls-on-establishment-of-sae-cellular-v2x-technical-committee-and-associated-task-forces-attachment-1.pdf From nobody Wed Jan 24 02:25:19 2018 Return-Path: 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 B281912D957 for ; Wed, 24 Jan 2018 02:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 SOv0Hje4vDdp for ; Wed, 24 Jan 2018 02:25:16 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E66012D94E for ; Wed, 24 Jan 2018 02:25:16 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id i186so7403565wmi.4 for ; Wed, 24 Jan 2018 02:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=uEE93mOfkDDZtoh6iO9xIC2XcG3XXZ6mOEaoBqIUgSo=; b=pPmnHhrMOMAGJgcOOFfEdOoq9wrexgn3h5A+2TOEJ6GdGshJ+l6wjjmWnZw0zMDQIb QPHFMSY9xtqmvLizSsBZSobyRDVs0Lu/g7hOfJyTljbaTP0wMvdDAJG+2d6mXyqu2saX SxmMpZkwyBy/sXWVhHkeKWqWzZllwjPoxkBSJOElYWp71ZdB3/8mZ4ikoD7ez1WGyX/C YraO9ndFCzOJGZ6oJ3oCjmP/I8HHdiDLl8a8mev+DAAJAJgRohiZEHRM8IYoESU+avMj EMWdg8h1AZWjtY5ny/UqMcjW8NHW2UU7l2aqaGhRYaCU62HXzbVYTX3FhRlQHofXPHnc NDAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=uEE93mOfkDDZtoh6iO9xIC2XcG3XXZ6mOEaoBqIUgSo=; b=LPeIiIlT1FsoTjeFiQqUmQCdl0CtiZOUL/557ULGa0+3tApLFnvtOFE5a3kboegrOo HXgPz/cHXWEdDor6q3Lqj1MqtFv/tFB5KSzFBXQedHTsQapT9Yl13W8BkCkgVX47cUm2 bpXfACspFmkE8mNKtSaKY70+DyuLH1HGzXgNCg/D8gfq3kg3qI/AlOhBDw52oOAScEzz /5uBSTnDxOAhMiqaeOrhyd5oEOgYUASCTdhmDGhBsHwYDQ/TG8rZy7d0QOVYohwJJnPI LLkPyph0QufEo38zCsOHpRYyaxRIY/EI3fXvgfFpfJPafhMacGV+l32hj+tyqcp4MAMw qg/A== X-Gm-Message-State: AKwxytdZL6+wqmLKVFME4myeJ61YsQIIVHqjZl5LNtmBca+iyeLsw12h xcqois+y0h2tb5sD+2KpEKchbE+p X-Google-Smtp-Source: AH8x2251hNsjLco+m/GUbs8H8MTncWlwkES/WNfyZJlXn/fKHbs5RUUFHypOR4g/+JHY74b5jGZ+UA== X-Received: by 10.80.160.167 with SMTP id 36mr24071002edo.188.1516789514337; Wed, 24 Jan 2018 02:25:14 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id s5sm15195139eda.60.2018.01.24.02.25.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jan 2018 02:25:13 -0800 (PST) Message-ID: <1516789512.9922.18.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "its@ietf.org" Cc: Russ Housley Date: Wed, 24 Jan 2018 11:25:12 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 10:25:19 -0000 Hi, Now that our first document is close to be shipped to the IESG for IETF LC, the chairs and AD are starting to plan on potential rechartering (as we anticipated in Singapore). There are a number of things people have discussed in the past, including the time of the BoFs. Now it is time to bring in the ideas and suggest them on the mailing list. Please, keep in mind some important considerations/constraints: - We will schedule time on the f2f session in London for rechartering discussion, _only if_ discussion has taken place on the mailing list. So please, do not wait for the call for presentations during the meeting to propose topics. - Our current charter includes a "Problem Statement" item, which is addressed in the document draft-ietf-ipwave-vehicular-networking. Obviously, potential topics for rechartering should be covered there (it will not make sense to work on topics that the community has not agreed to be important and remain unsolved). - A rechartering process will always take into account the energy level of the WG and the completion level of the current milestones. This means that we need to finish (submit to the IESG) our 2 documents before we actually start working on the new topics. Please, share your thoughts on the mailing list! Thanks, Carlos and Russs From nobody Wed Jan 24 09:07:51 2018 Return-Path: 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 1BA061273E2 for ; Wed, 24 Jan 2018 09:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 lsrDZMgiJkgm for ; Wed, 24 Jan 2018 09:07:47 -0800 (PST) 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 98CFD126FDC for ; Wed, 24 Jan 2018 09:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2053; q=dns/txt; s=iport; t=1516813667; x=1518023267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lsKLycqqT+cYHpnkwVk1KLwAUYR+LHcuCIwah3dItzI=; b=gJ4ln8BXzaP/Edq3lervJEKiee2QsmNWv91ZDJLJ9C/13OGkYPamQGTV E70S6PMZCXlR+t1FTd9CJ8i1Oviyao6qQDATJb++K5NBnk7PDYSDzyJ6a bXRs8fReocLI4l2SQHAlXwkYahTrc6Bvwki8leh0bc5Ri8qe41qe2o1v2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQAfvWha/5hdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB416jmeZQhWCAgoYC4UYAoUBVBgBAQEBAQEBAQJrKIU?= =?us-ascii?q?kAgQBARtRCxACAQgtGScLJQIEAQ0FFIohELR+ilkBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYRSghWBV4Fogy6DLwEBAoEqImKFPQWTBJECApVfghuGH4tqlyoCERk?= =?us-ascii?q?BgTsBHzmBUHAVPYIqhFd4jROBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,408,1511827200"; d="scan'208";a="60530770" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 17:07:25 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0OH7PrC028626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jan 2018 17:07:25 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 24 Jan 2018 11:07:24 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Wed, 24 Jan 2018 11:07:24 -0600 From: "Sri Gundavelli (sgundave)" To: "cjbc@it.uc3m.es" , "its@ietf.org" CC: Russ Housley Thread-Topic: [ipwave] Rechartering Thread-Index: AQHTlP2l+Iy6e5eBcEOwrUAftbRpkaODIDGA Date: Wed, 24 Jan 2018 17:07:24 +0000 Message-ID: References: <1516789512.9922.18.camel@it.uc3m.es> In-Reply-To: <1516789512.9922.18.camel@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.20.190] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2944193D565E704197FF17F36DF5EE08@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 17:07:50 -0000 Hi Carlos, Thanks for initiating the rechartering process. The initial work that the group focussed on around, IPv6 over Requirements / 802.11-OCB is just the enabler, but I tend to think we need to solve number of other problems for Vehicular Connectivity, Road-side infra ..etc. I am very supportive of this work and planning to contribute in the form of writing new proposals. Regards Sri On 1/24/18, 2:25 AM, "its on behalf of Carlos Jes=FAs Bernardos Cano" wrote: >Hi, > >Now that our first document is close to be shipped to the IESG for IETF >LC, the chairs and AD are starting to plan on potential rechartering >(as we anticipated in Singapore). > >There are a number of things people have discussed in the past, >including the time of the BoFs. Now it is time to bring in the >ideas and suggest them on the mailing list. > >Please, keep in mind some important considerations/constraints: > >- We will schedule time on the f2f session in London for rechartering >discussion, _only if_ discussion has taken place on the mailing list. >So please, do not wait for the call for presentations during the >meeting to propose topics. > >- Our current charter includes a "Problem Statement" item, which is >addressed in the document draft-ietf-ipwave-vehicular-networking. >Obviously, potential topics for rechartering should be covered there >(it will not make sense to work on topics that the community has not >agreed to be important and remain unsolved). > >- A rechartering process will always take into account the energy level >of the WG and the completion level of the current milestones. This >means that we need to finish (submit to the IESG) our 2 documents >before we actually start working on the new topics. > >Please, share your thoughts on the mailing list! > >Thanks, > >Carlos and Russs > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its From nobody Wed Jan 24 09:31:34 2018 Return-Path: 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 CAE221270B4 for ; Wed, 24 Jan 2018 09:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 LBynfvBH4exI for ; Wed, 24 Jan 2018 09:31:30 -0800 (PST) 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 049D71270AB for ; Wed, 24 Jan 2018 09:31:29 -0800 (PST) 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 w0OHVRCS130566 for ; Wed, 24 Jan 2018 18:31:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A88142052D1 for ; Wed, 24 Jan 2018 18:31:27 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E7CA205247 for ; Wed, 24 Jan 2018 18:31:27 +0100 (CET) Received: from [132.166.84.162] ([132.166.84.162]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0OHVQXi010630 for ; Wed, 24 Jan 2018 18:31:27 +0100 To: its@ietf.org References: <1516789512.9922.18.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> Date: Wed, 24 Jan 2018 18:31:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1516789512.9922.18.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 17:31:33 -0000 One aspect we discussed recently was the use of ND on OCB links. One particular aspect of ND on OCB links is how to make ND support SLAAC and Mobile IP between a Road-Side Unit and an On-Board Unit. On WiFi links, a Host (role of OBU) receives an RA with a prefix and configures an address, which becomes a Care-of Address and triggers a BU. But on OCB links, the Host may receive RA from distinct RSUs, without knowing which is the 'right' RSU to connect to. (on wifi the Host knows which is the 'right' Access Point because the user sets an ESSID to connect to; in OCB there is on ESSID, or, otherwise put, there is a single ESSID for everybody, called '*'). Another aspect of ND on OCB links relates to the use of OCB between two vehicles (not between the vehicle and the RSU). On such an OCB link there may be no RA dedicated to SLAAC, and the addresses used are link-local addresses. But there could be RA to exchange the prefixes that are configured _inside_ the cars. And, the use of MLDv2 is mandatory on these OCB links between two cars. There can be an ND question between RSU and cars, and between cars, about the DNS server address. Does the RA contain the address of the DNS server, is the DNS server in a car, or in the RSU. Moreover, there have been several recent drafts that have -ipwave- and -nd- in the file names. Maybe these drafts expose other problems on the use of ND on OCB. Alex Le 24/01/2018 à 11:25, Carlos Jesús Bernardos Cano a écrit : > Hi, > > Now that our first document is close to be shipped to the IESG for IETF > LC, the chairs and AD are starting to plan on potential rechartering > (as we anticipated in Singapore). > > There are a number of things people have discussed in the past, > including the time of the BoFs. Now it is time to bring in the > ideas and suggest them on the mailing list. > > Please, keep in mind some important considerations/constraints: > > - We will schedule time on the f2f session in London for rechartering > discussion, _only if_ discussion has taken place on the mailing list. > So please, do not wait for the call for presentations during the > meeting to propose topics. > > - Our current charter includes a "Problem Statement" item, which is > addressed in the document draft-ietf-ipwave-vehicular-networking. > Obviously, potential topics for rechartering should be covered there > (it will not make sense to work on topics that the community has not > agreed to be important and remain unsolved). > > - A rechartering process will always take into account the energy level > of the WG and the completion level of the current milestones. This > means that we need to finish (submit to the IESG) our 2 documents > before we actually start working on the new topics. > > Please, share your thoughts on the mailing list! > > Thanks, > > Carlos and Russs > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Jan 24 09:54:04 2018 Return-Path: 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 DA85B1270A3 for ; Wed, 24 Jan 2018 09:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 mK0lsOceC9KR for ; Wed, 24 Jan 2018 09:54:01 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 3D74A12706D for ; Wed, 24 Jan 2018 09:54:00 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with ESMTP id ePFIe7aUDMk7PePFIevrTo; Wed, 24 Jan 2018 17:54:00 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-06v.sys.comcast.net with SMTP id ePDBep0yud55EePDEecMBV; Wed, 24 Jan 2018 17:51:58 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> Date: Wed, 24 Jan 2018 09:51:48 -0800 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1516789512.9922.18.camel@it.uc3m.es> <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfNBnYtc1myLnYyXjwzHspKfpHpXPGgsoozkTBOTcqeVMQ47MDqVD8Uvb7efdIppLNp9M6XeBefjM3lhCX+5IPQOZMoqjRAFX4i6eDzxnPKiUqFUSnAdt U3AbS04JAz6Xd77CViNLDRnQiTK5qLjADPO9rv7G3cxSkTMdXxPLTYtCQPvniEVAIBQV3pl7bXMnBnuc1i1g64HR9gXJYsQKekY= Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 17:54:03 -0000 > One particular aspect of ND on OCB links is how to make ND support = SLAAC and Mobile IP between a Road-Side Unit and an On-Board Unit. On = WiFi links, a Host (role of OBU) receives an RA with a prefix and = configures an address, which becomes a Care-of Address and triggers a = BU. But on OCB links, the Host may receive RA from distinct RSUs, = without knowing which is the 'right' RSU to connect to. (on wifi the = Host knows which is the 'right' Access Point because the user sets an = ESSID to connect to; in OCB there is on ESSID, or, otherwise put, there = is a single ESSID for everybody, called '*=E2=80=99). This assumes that the Wi-Fi AP and the router are co-located, which is = definitely not required. You can easily have a Wi-FI topology with = multiple routers sending RAs where the routers sit behind the AP or are = clients themselves. I agree that there=E2=80=99s a problem of knowing the right OCB link to = make, but that seems completely independent of ND. > Another aspect of ND on OCB links relates to the use of OCB between = two vehicles (not between the vehicle and the RSU). On such an OCB link = there may be no RA dedicated to SLAAC, and the addresses used are = link-local addresses. But there could be RA to exchange the prefixes > that are configured _inside_ the cars. And, the use of MLDv2 is = mandatory on these OCB links between two cars. One might also consider using a routing protocol, as exchanging prefix = reachability is the purpose of routing protocols. Even RIP would = suffice for this application. Tony From nobody Thu Jan 25 09:11:42 2018 Return-Path: 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 8B268126DED for ; Thu, 25 Jan 2018 09:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 ZfMUhz9xIYMU for ; Thu, 25 Jan 2018 09:11:38 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800A6124D68 for ; Thu, 25 Jan 2018 09:11:38 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id f3so16279090wmc.1 for ; Thu, 25 Jan 2018 09:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=hpv1DFxG88IFCYhyJy5BsrL9nKZVSClsDvH6Cr/Hkd0=; b=QDOLOJ4jsgMTYMVWW+wTZfuVhjeu5UCJa8XmbfvbmhPqCHTJlCmU6hGC+bSliamGsu qi1IFXYM4dnZY//9PXYRR/7wX+vBFJ2A8JA85FJjC0g31cvce226lbejasxbeGWa4I+T Hr1x9pGZynG3eRcXjAOYrg21xVs0+gqYXygEl8z2m1wuaenS0Ys4dBUTcpVbGMDt9Jdh /ptX3gWaprp9/ZsBA8LID1ufpvuaHobeoqSfEOJt3Cxs5CUL37GQqCP9eyUU1OAhNTVl S2Nk8iUJ63U9Vf6N+7GsN1m2mdk7Uqu6pKY671dCCFekAdkbRhkSDy4Rz4ObwrENCZ91 AgVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=hpv1DFxG88IFCYhyJy5BsrL9nKZVSClsDvH6Cr/Hkd0=; b=CM7sZRl3k1jnjbaWGrPE3FbYTVGlFVUYSgM1KYHmKqu4t8K9Q3abZcy22obYtYTX70 92fiC6Q1qIJCpz7O8rnF2S4qsG5ML7VjfhBcYjF+cptSkcXSc+F/uNc6EWSGNA7qTVL3 mC4LJQSIglLI1wEUJSR7ggk/CxcIeiyGUicS7G7PT21bs/aon6Dsud0aegyraZ75gX5Q WLpVBs17j/Nghe7TzNCjBtCDOQfSaRr2J1mYlEJzFpcbbwLeGM8GsjkcVIaUq+k625nQ JxFZWEDFTioZOIrSpJMMDZvyEodxgPsj5ScS9jXObJdpIZYJhNQhWUJ/bzu6fXfb7dWh pfwg== X-Gm-Message-State: AKwxytfR186T2xitHQnQ0lTD/ADDyrqKsTdgU3/TgWsn+i4xXffM9wCp e45tdR9BZuXzsXhQOLqH7cbTc6ZJ X-Google-Smtp-Source: AH8x224SOqTS9ShOSeHn5ZOZvUdD+LmwMbgYhm2VQ5M6H24ImVrfnbLOBPSwT7rzxt5GmqbYZV70dA== X-Received: by 10.28.239.3 with SMTP id n3mr8832689wmh.88.1516900296962; Thu, 25 Jan 2018 09:11:36 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id t51sm8503503wrc.21.2018.01.25.09.11.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jan 2018 09:11:36 -0800 (PST) Message-ID: <1516900295.4317.75.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "Sri Gundavelli (sgundave)" , "its@ietf.org" Cc: Russ Housley Date: Thu, 25 Jan 2018 18:11:35 +0100 In-Reply-To: References: <1516789512.9922.18.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 17:11:41 -0000 Hi Sri, Can you please elaborate a bit more on specific topics you have in mind? It'd be good to have a list of those discussed on the mailing list over the next month, so we can have enough previous discussion by the F2F meeting in London. Thanks a lot! Carlos On Wed, 2018-01-24 at 17:07 +0000, Sri Gundavelli (sgundave) wrote: > Hi Carlos, > > Thanks for initiating the rechartering process. The initial work that > the > group focussed on around, IPv6 over Requirements / 802.11-OCB is just > the > enabler, but I tend to think we need to solve number of other > problems for > Vehicular Connectivity, Road-side infra ..etc. I am very supportive > of > this work and planning to contribute in the form of writing new > proposals. > > Regards > Sri > > > > > > > > > On 1/24/18, 2:25 AM, "its on behalf of Carlos Jesús Bernardos Cano" > wrote: > > > Hi, > > > > Now that our first document is close to be shipped to the IESG for > > IETF > > LC, the chairs and AD are starting to plan on potential > > rechartering > > (as we anticipated in Singapore). > > > > There are a number of things people have discussed in the past, > > including the time of the BoFs. Now it is time to bring in the > > ideas and suggest them on the mailing list. > > > > Please, keep in mind some important considerations/constraints: > > > > - We will schedule time on the f2f session in London for > > rechartering > > discussion, _only if_ discussion has taken place on the mailing > > list. > > So please, do not wait for the call for presentations during the > > meeting to propose topics. > > > > - Our current charter includes a "Problem Statement" item, which is > > addressed in the document draft-ietf-ipwave-vehicular-networking. > > Obviously, potential topics for rechartering should be covered > > there > > (it will not make sense to work on topics that the community has > > not > > agreed to be important and remain unsolved). > > > > - A rechartering process will always take into account the energy > > level > > of the WG and the completion level of the current milestones. This > > means that we need to finish (submit to the IESG) our 2 documents > > before we actually start working on the new topics. > > > > Please, share your thoughts on the mailing list! > > > > Thanks, > > > > Carlos and Russs > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Jan 25 09:11:48 2018 Return-Path: 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 C304A12DA51 for ; Thu, 25 Jan 2018 09:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 BLLzYhqbOTCr for ; Thu, 25 Jan 2018 09:11:43 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EDC126DED for ; Thu, 25 Jan 2018 09:11:43 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r71so16112800wmd.1 for ; Thu, 25 Jan 2018 09:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=oyyxIDdhFh8yptx3WOCspJsWb8t4ZL6NE1/69G0aQhQ=; b=RMJ1RAFWjpXsKQim6gW2881H2Y3xylsgMR0Z1WhNrgnBwzY0WgHvp38cQSDUWp9jFT LV3qIhsKNbvCSJV7IL019t+gwmvCHmB5b//2DCy6w1wJcYvukcf105Pf0rdeS8c/u/UH aTJxCOJ2siwd8iEj/fOc177s+5zvfJmYBVoKv9PP0hZbBGMIiPmlFLn3sfBYTsgpG82X GrU6O3n/oKKXWUlIljwqZAXmsJ3ZvC+isP1tiEXCxOl2k4fiCtr8DOSXwOJHsovYS+qC yUQkVpErj+Oq6AdizO8hiIKbcb6bYf0rwCpo70j2lhdtZDDRgFoxSjf7zUrjXE47e8wF 16UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=oyyxIDdhFh8yptx3WOCspJsWb8t4ZL6NE1/69G0aQhQ=; b=U4Wb+4Cvnol+u3QSZcckn9xKkqQKhpnklwI0gl/TxrV0dnwqwDPwr4hJh0o6nexctp wPTr24WagUnaYByLu12WWSgpeaAG8DUxvrXpmC9vSRQe0uINMlR5Ff32tsCz4IGwtBG5 U0x4cnZGhpIJzeWxAEPJoDllab6adBgYNcd/XkydcgjlUpiq0RqSf13iIHBvRBCsfIJT ELIFcx6ikPEsbW/dypJsPyop02thAgC+lRTFhdFBJSBnU11vn4Afjd8fWjAKmtMlKNYc HJ0bvoEtTQPhoSYuxyM89PRZ6w1z+FvfNuJcZKB3A1tyb5GrfvnPstgfDg1PuXtNaxOu NGTw== X-Gm-Message-State: AKwxytfc6k1o/U/C0NUY90tL2TE3rVtGDptVHQdWJE0AvGZaZIodi7cC f4hP7TO9bE9VkLDyCvjO3gIjFtsR X-Google-Smtp-Source: AH8x227Dh+BWlAeOoZ/jCFRo5QWXbe3k8BXT2Tr4jhKqRMK9618OE4SShXMidDuG4+dz54HeCD0RMQ== X-Received: by 10.28.220.193 with SMTP id t184mr2599703wmg.126.1516900301850; Thu, 25 Jan 2018 09:11:41 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id x135sm1750751wmf.35.2018.01.25.09.11.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jan 2018 09:11:41 -0800 (PST) Message-ID: <1516900300.4317.76.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Tony Li , Alexandre Petrescu Cc: its@ietf.org Date: Thu, 25 Jan 2018 18:11:40 +0100 In-Reply-To: References: <1516789512.9922.18.camel@it.uc3m.es> <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 17:11:46 -0000 Hi Alex, Tony, OK, I see the interest on looking into ND over OCB links, including mobility and routing purposes. This is indeed interesting, but also quite challenging (and potentially broad area). Some of these may also need coordination with 6man. Said that, let's keep discussing potential topics, but trying to narrow the list down, to pieces of work that can be realistically done in 1-2 years (at typical IETF WG). Thanks, Carlos On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote: > > One particular aspect of ND on OCB links is how to make ND support > > SLAAC and Mobile IP between a Road-Side Unit and an On-Board > > Unit. On WiFi links, a Host (role of OBU) receives an RA with a > > prefix and configures an address, which becomes a Care-of Address > > and triggers a BU. But on OCB links, the Host may receive RA from > > distinct RSUs, without knowing which is the 'right' RSU to connect > > to. (on wifi the Host knows which is the 'right' Access Point > > because the user sets an ESSID to connect to; in OCB there is on > > ESSID, or, otherwise put, there is a single ESSID for everybody, > > called '*’). > > > This assumes that the Wi-Fi AP and the router are co-located, which > is definitely not required. You can easily have a Wi-FI topology > with multiple routers sending RAs where the routers sit behind the AP > or are clients themselves. > > I agree that there’s a problem of knowing the right OCB link to make, > but that seems completely independent of ND. > > > > Another aspect of ND on OCB links relates to the use of OCB between > > two vehicles (not between the vehicle and the RSU). On such an OCB > > link there may be no RA dedicated to SLAAC, and the addresses used > > are link-local addresses. But there could be RA to exchange the > > prefixes > > that are configured _inside_ the cars. And, the use of MLDv2 is > > mandatory on these OCB links between two cars. > > > One might also consider using a routing protocol, as exchanging > prefix reachability is the purpose of routing protocols. Even RIP > would suffice for this application. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Jan 25 09:44:07 2018 Return-Path: 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 97D0512DA45 for ; Thu, 25 Jan 2018 09:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 vyBcEaV7gy4b for ; Thu, 25 Jan 2018 09:44:04 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 61339124D68 for ; Thu, 25 Jan 2018 09:44:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w0PHi20c043197; Thu, 25 Jan 2018 18:44:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7344A205965; Thu, 25 Jan 2018 18:44:02 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 63E24201AA5; Thu, 25 Jan 2018 18:44:02 +0100 (CET) Received: from [132.166.84.55] ([132.166.84.55]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0PHi1FM032607; Thu, 25 Jan 2018 18:44:01 +0100 To: Tony Li Cc: cjbc@it.uc3m.es, its@ietf.org References: <1516789512.9922.18.camel@it.uc3m.es> <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> <1516900300.4317.76.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Thu, 25 Jan 2018 18:44:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1516900300.4317.76.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 17:44:06 -0000 > On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote: >>> One particular aspect of ND on OCB links is how to make ND support >>> SLAAC and Mobile IP between a Road-Side Unit and an On-Board >>> Unit. On WiFi links, a Host (role of OBU) receives an RA with a >>> prefix and configures an address, which becomes a Care-of Address >>> and triggers a BU. But on OCB links, the Host may receive RA from >>> distinct RSUs, without knowing which is the 'right' RSU to connect >>> to. (on wifi the Host knows which is the 'right' Access Point >>> because the user sets an ESSID to connect to; in OCB there is on >>> ESSID, or, otherwise put, there is a single ESSID for everybody, >>> called '*’). >> >> >> This assumes that the Wi-Fi AP and the router are co-located, which >> is definitely not required. You can easily have a Wi-FI topology >> with multiple routers sending RAs where the routers sit behind the AP >> or are clients themselves. I agree, but whereas in WiFi the Access Points have an option to 'bridge', in 802.11 OCB trials the Road-Side Units are rarely bridges, and are often routers. But I agree it is possible to make RSUs as Access Points, and the RA to come from single router. >> I agree that there’s a problem of knowing the right OCB link to make, >> but that seems completely independent of ND. Well, it depends how those (new?) 802.11 OCB unrouter Access Points are made. If they are wrongly made to bridge an NA from the Router by substituting its the src MAC address for the Router's, _and_ not include a SLLA option (source link-layer address) of the ND protocol, then we have a problem. The solution would be to recommend to 80211 OCB AP bridge makers to MUST include SLLA if they substitute the src. I have seen this problem in the past with other bridges. And no, this would not indeed solve the problem of OBU deciding which is the right OCB to connect to. But I think that if there is something that could help the OBU to decide which OCB to connect to, then it must be in the ND, because that's the first protocol run. >>> Another aspect of ND on OCB links relates to the use of OCB between >>> two vehicles (not between the vehicle and the RSU). On such an OCB >>> link there may be no RA dedicated to SLAAC, and the addresses used >>> are link-local addresses. But there could be RA to exchange the >>> prefixes >>> that are configured _inside_ the cars. And, the use of MLDv2 is >>> mandatory on these OCB links between two cars. >> >> >> One might also consider using a routing protocol, as exchanging >> prefix reachability is the purpose of routing protocols. Even RIP >> would suffice for this application. I agree. There a few Internet Drafts for ND for prefix exchanges between the cars. But I lost my implementation(s), I forgot where they are. As such I asked a colleague to solve the problem of car to car communications without prefixes in ND and he came up with... Babel. It's open source, stored somewhere well known and apparently it works in practice, on a table. We may need to see whether it, Babel, scales well with a 10- or 100-car convoy of vehicles aligned, or whether it has too heavy in computing needs for small in-car platforms, or whether it can help to _form_ the convoy (cars joining each other, or car pulling other cars for fleet rebalancing). Alex >> >> Tony >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Thu Jan 25 10:02:36 2018 Return-Path: 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 08B0612DA68 for ; Thu, 25 Jan 2018 10:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 b-7oJZvBn57O for ; Thu, 25 Jan 2018 10:02:32 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEF612DB71 for ; Thu, 25 Jan 2018 10:02:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,412,1511823600"; d="scan'208";a="7563336" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 25 Jan 2018 19:02:29 +0100 Received: from [10.60.152.59] (unknown [46.189.28.79]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 04CAE372; Thu, 25 Jan 2018 19:02:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jerome Haerri X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Thu, 25 Jan 2018 19:02:27 +0100 Cc: Tony Li , its@ietf.org, cjbc@it.uc3m.es Content-Transfer-Encoding: quoted-printable Message-Id: References: <1516789512.9922.18.camel@it.uc3m.es> <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> <1516900300.4317.76.camel@it.uc3m.es> To: Alexandre Petrescu Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 18:02:35 -0000 Hi Alex, All, from the various e-mails, there is indeed issues or challenges to use IPv6 a= nd underlying protocol for distributed, large scale and dynamic vehicular ne= yworks.=20 However, I also see, again from e-mails, that there seem to always be a solu= tion for each issue, weather it solves it optimaly or not. And most of the t= ime, it seems to require strategies from different IETF WG.=20 So, as IPWAVE might be seen as an entry point for IPv6 issues in vehicular e= nvironments, it could be interesting and helpful for the community to have a= best practice document summarizing the issues, introducing a potential so= lution and linking to the right IETF workgroup.=20 Of course, we can also propose enhancement, but it could be good to have suc= h best practice document, no? Best Regards, J=C3=A9r=C3=B4me Envoy=C3=A9 de mon iPhone > Le 25 janv. 2018 =C3=A0 18:44, Alexandre Petrescu a =C3=A9crit : >=20 >=20 >> On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote: >>>> One particular aspect of ND on OCB links is how to make ND support >>>> SLAAC and Mobile IP between a Road-Side Unit and an On-Board >>>> Unit. On WiFi links, a Host (role of OBU) receives an RA with a >>>> prefix and configures an address, which becomes a Care-of Address >>>> and triggers a BU. But on OCB links, the Host may receive RA from >>>> distinct RSUs, without knowing which is the 'right' RSU to connect >>>> to. (on wifi the Host knows which is the 'right' Access Point >>>> because the user sets an ESSID to connect to; in OCB there is on >>>> ESSID, or, otherwise put, there is a single ESSID for everybody, >>>> called '*=E2=80=99). >>>=20 >>>=20 >>> This assumes that the Wi-Fi AP and the router are co-located, which >>> is definitely not required. You can easily have a Wi-FI topology >>> with multiple routers sending RAs where the routers sit behind the AP >>> or are clients themselves. >=20 > I agree, but whereas in WiFi the Access Points have an option to 'bridge',= in 802.11 OCB trials the Road-Side Units are rarely bridges, and are often r= outers. But I agree it is possible to make RSUs as Access Points, and the R= A to come from single router. >>> I agree that there=E2=80=99s a problem of knowing the right OCB link to m= ake, >>> but that seems completely independent of ND. >=20 > Well, it depends how those (new?) 802.11 OCB unrouter Access Points are ma= de. If they are wrongly made to bridge an NA from the Router by substitutin= g its the src MAC address for the Router's, _and_ not include a SLLA option (= source link-layer address) of the ND protocol, then we have a problem. >=20 > The solution would be to recommend to 80211 OCB AP bridge makers to MUST i= nclude SLLA if they substitute the src. >=20 > I have seen this problem in the past with other bridges. >=20 > And no, this would not indeed solve the problem of OBU deciding which is t= he right OCB to connect to. >=20 > But I think that if there is something that could help the OBU to decide w= hich OCB to connect to, then it must be in the ND, because that's the first p= rotocol run. >=20 >>>> Another aspect of ND on OCB links relates to the use of OCB between >>>> two vehicles (not between the vehicle and the RSU). On such an OCB >>>> link there may be no RA dedicated to SLAAC, and the addresses used >>>> are link-local addresses. But there could be RA to exchange the >>>> prefixes >>>> that are configured _inside_ the cars. And, the use of MLDv2 is >>>> mandatory on these OCB links between two cars. >>>=20 >>>=20 >>> One might also consider using a routing protocol, as exchanging >>> prefix reachability is the purpose of routing protocols. Even RIP >>> would suffice for this application. >=20 > I agree. >=20 > There a few Internet Drafts for ND for prefix exchanges between the cars. = But I lost my implementation(s), I forgot where they are. >=20 > As such I asked a colleague to solve the problem of car to car communicati= ons without prefixes in ND and he came up with... Babel. It's open source, s= tored somewhere well known and apparently it works in practice, on a table. >=20 > We may need to see whether it, Babel, scales well with a 10- or 100-car co= nvoy of vehicles aligned, or whether it has too heavy in computing needs for= small in-car platforms, or whether it can help to _form_ the convoy (cars j= oining each other, or car pulling other cars for fleet rebalancing). >=20 > Alex >=20 >>>=20 >>> Tony >>>=20 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Jan 29 00:20:26 2018 Return-Path: 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 A3B981316D1 for ; Mon, 29 Jan 2018 00:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 vKMEq-fmVCU7 for ; Mon, 29 Jan 2018 00:20:22 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 855D012D811 for ; Mon, 29 Jan 2018 00:20:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w0T8KJhi013373; Mon, 29 Jan 2018 09:20:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E2B97202E46; Mon, 29 Jan 2018 09:20:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CFCFE202E2E; Mon, 29 Jan 2018 09:20:19 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0T8KJkC022815; Mon, 29 Jan 2018 09:20:19 +0100 To: Jerome Haerri Cc: Tony Li , its@ietf.org, cjbc@it.uc3m.es References: <1516789512.9922.18.camel@it.uc3m.es> <21c363bc-fb2f-ac89-633d-ae0b5406d2a4@gmail.com> <1516900300.4317.76.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <1f73f99b-0864-225f-ea90-991fdc5fca9f@gmail.com> Date: Mon, 29 Jan 2018 09:20:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 08:20:26 -0000 Le 25/01/2018 à 19:02, Jerome Haerri a écrit : > Hi Alex, All, > > from the various e-mails, there is indeed issues or challenges to > use IPv6 and underlying protocol for distributed, large scale and > dynamic vehicular neyworks. > > However, I also see, again from e-mails, that there seem to always > be a solution for each issue, weather it solves it optimaly or not. > And most of the time, it seems to require strategies from different > IETF WG. > > So, as IPWAVE might be seen as an entry point for IPv6 issues in > vehicular environments, it could be interesting and helpful for the > community to have a best practice document summarizing the issues, > introducing a potential solution and linking to the right IETF > workgroup. > > Of course, we can also propose enhancement, but it could be good to > have such best practice document, no? Hi Jérôme, I would need to better understand what do you mean by a 'best practice' document. I think you did not mean BCP like some RFCs are, but just best practice. In that sense, I could think of needs of IP in OCB networks for vehicular communications. Most people dont agree precisely how to make an IP topology in vehicular networks. Whereas an RSU - to - OBU topology is often easily agreed (a Router to a Host), other cases like vehicle - to - vehicle, or traffic light to pedestrian to vehicle are less clear (who is Router? what is the subnet?). The vehicular networks are still dominated by topologies little known in IP networks: every car 'broadcasts' CAM every 500ms and every other car tries to understand it. There is no IP network topology for it, but that's the predominating ways in which vehicular networks do. Things are changing with the arrival of IoT and C-V2X: a car sends a CAM to an IoT platform in the cloud, and the other cars look for it there, instead of direct 'broadcasts'. That's with IP. Along this line of thought, it could be possible to write something about 'best practices' of using IP in vehicular networks, including OCB. If _I_ were to write, but how about others? I am not sure whether this is the kind of idea you have about 'best practice'? Alex > > Best Regards, > > Jérôme > > Envoyé de mon iPhone > >> Le 25 janv. 2018 à 18:44, Alexandre Petrescu >> a écrit : >> >> >>> On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote: >>>>> One particular aspect of ND on OCB links is how to make ND >>>>> support SLAAC and Mobile IP between a Road-Side Unit and an >>>>> On-Board Unit. On WiFi links, a Host (role of OBU) receives >>>>> an RA with a prefix and configures an address, which becomes >>>>> a Care-of Address and triggers a BU. But on OCB links, the >>>>> Host may receive RA from distinct RSUs, without knowing >>>>> which is the 'right' RSU to connect to. (on wifi the Host >>>>> knows which is the 'right' Access Point because the user sets >>>>> an ESSID to connect to; in OCB there is on ESSID, or, >>>>> otherwise put, there is a single ESSID for everybody, called >>>>> '*’). >>>> >>>> >>>> This assumes that the Wi-Fi AP and the router are co-located, >>>> which is definitely not required. You can easily have a Wi-FI >>>> topology with multiple routers sending RAs where the routers >>>> sit behind the AP or are clients themselves. >> >> I agree, but whereas in WiFi the Access Points have an option to >> 'bridge', in 802.11 OCB trials the Road-Side Units are rarely >> bridges, and are often routers. But I agree it is possible to >> make RSUs as Access Points, and the RA to come from single router. >>>> I agree that there’s a problem of knowing the right OCB link >>>> to make, but that seems completely independent of ND. >> >> Well, it depends how those (new?) 802.11 OCB unrouter Access >> Points are made. If they are wrongly made to bridge an NA from the >> Router by substituting its the src MAC address for the Router's, >> _and_ not include a SLLA option (source link-layer address) of the >> ND protocol, then we have a problem. >> >> The solution would be to recommend to 80211 OCB AP bridge makers >> to MUST include SLLA if they substitute the src. >> >> I have seen this problem in the past with other bridges. >> >> And no, this would not indeed solve the problem of OBU deciding >> which is the right OCB to connect to. >> >> But I think that if there is something that could help the OBU to >> decide which OCB to connect to, then it must be in the ND, because >> that's the first protocol run. >> >>>>> Another aspect of ND on OCB links relates to the use of OCB >>>>> between two vehicles (not between the vehicle and the RSU). >>>>> On such an OCB link there may be no RA dedicated to SLAAC, >>>>> and the addresses used are link-local addresses. But there >>>>> could be RA to exchange the prefixes that are configured >>>>> _inside_ the cars. And, the use of MLDv2 is mandatory on >>>>> these OCB links between two cars. >>>> >>>> >>>> One might also consider using a routing protocol, as exchanging >>>> prefix reachability is the purpose of routing protocols. Even >>>> RIP would suffice for this application. >> >> I agree. >> >> There a few Internet Drafts for ND for prefix exchanges between >> the cars. But I lost my implementation(s), I forgot where they >> are. >> >> As such I asked a colleague to solve the problem of car to car >> communications without prefixes in ND and he came up with... >> Babel. It's open source, stored somewhere well known and apparently >> it works in practice, on a table. >> >> We may need to see whether it, Babel, scales well with a 10- or >> 100-car convoy of vehicles aligned, or whether it has too heavy in >> computing needs for small in-car platforms, or whether it can help >> to _form_ the convoy (cars joining each other, or car pulling >> other cars for fleet rebalancing). >> >> Alex >> >>>> >>>> Tony >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Jan 29 01:24:24 2018 Return-Path: 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 6A7C012DA00 for ; Mon, 29 Jan 2018 01:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 NAZcLSVZ9IGY for ; Mon, 29 Jan 2018 01:24:20 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F8012D87E for ; Mon, 29 Jan 2018 01:24:19 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id r71so12768937wmd.1 for ; Mon, 29 Jan 2018 01:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=ZFOs3LlJY1DpR0SO6HzuH90x4LctUS+ymoiE+C37+ds=; b=jzw5A/kRdqYC5LLe2n50huZJEg7Jyx6V+ccRftfQ5+0P2K8nkLldz0vbzyQmYKCb/s X/yVehuINPOUhekIG9UthrjFtHqGkaE3OOQ6mp+IvECOjd2dC7o+wkGCmJYzM6z7iLLh HhAM0Y6cOnY/CL+vo6TZoocGLP+MSmRbR7uN5GxI1xI8CKNBFoQRA3h0Tz+n+g4XW0EH TTTgKBA4jRnhxzQHvoXGZM1BVkGNkhwzPKqae+l24UZRjAXIHHEN2aXmHWZgSqNMBJfc PItqTaoHERwUO7/xqhDx/gbbfNwUdFkNlCmM5QLJsJjo9gcbuwzXPQk4IRloOpOl9LTX /sVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=ZFOs3LlJY1DpR0SO6HzuH90x4LctUS+ymoiE+C37+ds=; b=cru2615KDXK3zr4J//DYjfJLI6gvunlXSRuNBx5DP7bQIj0NQVRnW/46rXrV0wTyNr bZmHl/fDp9THPuyaq2ctCZK/MeTcMIl6Ph4WJkZiS3oWtEnDHJrS/dDEr1vBeed7S4EE Wr7sN0sGFqRsbh10MAxkpoahJ2vqouVnr4gQyZaU9aCnU499SUsNQb1/rcp+3x96qJmd WtA/H7jTCfmZ7qm3QGF4ZbgpmY3kMCmK31AM4LWW1HbsAY2NOELUavIQ0S5nIbj2fVgi bCZueupXA2pXtiIzYPm5UOdL1L+bE25aT8VECx1T0UGYpLZWpkCAiTF+D28UQGTAVs9c 7S6Q== X-Gm-Message-State: AKwxytfvP09QOi9ayrRIwGRq6WLGmSWLlq8aG5/CehtFGGyRZn+gwR8w yixqhFGKCU3EoO+6MX7Rf1UXZw== X-Google-Smtp-Source: AH8x226tGqL+TfrfQMMvCuv2MznvMwMs8vyyI2pkNMLKFCX8oPfhCtUa2z8tYl1KxNvIAyFVUiUK9Q== X-Received: by 10.28.86.132 with SMTP id k126mr15612437wmb.98.1517217858160; Mon, 29 Jan 2018 01:24:18 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id e67sm10126338wmd.7.2018.01.29.01.24.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 29 Jan 2018 01:24:17 -0800 (PST) Message-ID: <1517217856.4315.32.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" Cc: Russ Housley , "suresh@kaloom.com" Date: Mon, 29 Jan 2018 10:24:16 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 09:24:23 -0000 Hi, (Suresh, please check a question that I make below.) I'm the doc shepherd of this draft. I've performed a review and I have the following comments: - The document's intended status is "Standards Track", but the way it is written and most of its content looks more like an Informational/BCP kind of document. There no normative text applicable to what needs to be done to transmit IPv6 packets over IEEE 802.11-OCB. This has been discussed during the F2F meeting in Singapore and needs to be tackled. In many parts of the document, it seems that the main conclusion is that "nothing different from IPv6 over IEEE 802.11 needs to be done for IEEE 802.11-OCB" (at least for the current scope of the doc). If that is the case, maybe the document should be Informational and reflect just some recommendations. If there is something else that needs to be done, then it has to be more clearly stated (using normative text). @Suresh, can you provide some guidance on this point? - The abstract mentions that in order to transmit IPv6 packets on IEEE 802.11-OCB, "there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others". But the MTU part of the draft does not use any normative text, the header format is exactly the same than for IEEE 802.11, as the type value. - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet. The first one is not different from regular 802.11, but for the second one, the document only provides recommendations. - I always thought that "WiFi" does not stand for "Wireless Fidelity". See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html - The use of MAY (to be interpreted as in RFC2119) in the terminology section does not seem appropriate to me. I don't think normative text applies to whether an OBRU may be ab IP router. - In the terminology section, the OBU term is mentioned to be defined outside the IETF. This is fine, but we have to provide a reference. And even with that, it would not harm to include some short definition to provide context. The RSU term is also defined outside the IETF and there is quite a lot of text provided (I think the relevant part is the last sentence, the one starting with "The difference between..."). Both terms should be handled in the same way. - In section 3, it is mentioned that "the operating environment (vehicular networks) brings in new perspectives" --> which are those (that are covered/tackled by the document? - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500 octects. If that is what is meant, this is really a normative thing that should be written using normative text. If it is just a recommendation, then this should be clearly written as such. - All the text of section 4.2.1 is not normative, but more a report of what is done today in existing implementations. Is there any different there that is specific of 802.11-OCB? - All subsections 4.x seem informative, not normative. - The privacy part of section 5 is important, as it impacts the operation of IPv6 over this type of networks, so I think this deserves more attention. - In section 5, "amd" --> "and". - In section, H.1, more details about how the captures were obtained should be provided (HW, SW, etc.). Authors, please respond to my questions/comments and address them in a new version of the document. Thanks, Carlos From nobody Mon Jan 29 02:45:36 2018 Return-Path: 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 3A5A112E858 for ; Mon, 29 Jan 2018 02:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tuWqMQQzKpEq for ; Mon, 29 Jan 2018 02:45:30 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7492D12E054 for ; Mon, 29 Jan 2018 02:45:11 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id t139so9243707lff.0 for ; Mon, 29 Jan 2018 02:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=yo97T69sQ9mVD6Sdcgkvj6BuzFX2ii5udFMmmR+moas=; b=m2SpZAvud5EjUFl2clrby4hgiiqlGYygSqfPcZ9at0/mkL/McgPKKKGNkgbs2Q5C/v lGrO7aqwRC8em4Z43xxvI2OdQM2UVqBQT9Fdd0okvGQLYzoJA8hOSx1PBkh9A4kaeFBq cxHzA4BknSVxkKONwueoxBn689hkY3PzArESxLuBk4e5LHYIMu0sb/7tdYUG4eaH8b2n 96YJmkihX1syAHO0aEe/6wKMyob+oqORnKDJScsX79T8mwyrI+DhHJVClbb1g4rGlJrY 0nnW8rFtcuB63dfpRgpxH0lpcD8/zQR4ulMgGRkPFrNBXkVMe4gH8Zefxqf9N/ufqKFT 7GOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=yo97T69sQ9mVD6Sdcgkvj6BuzFX2ii5udFMmmR+moas=; b=ItgfoX0kn7QBDXf2Out/gxrOW4tQbFZ2By7IaeMioC7wuBmxQc9sct7RcuVZt0gvs0 0CJ16f9F8WIGB9Xj1bSLSc35qchmS/9cG2Lo2wJStmvXd5ZOkL7qnORY5Bws3Yzqy2Zt cooHY2sBeyQxglmfKBgEcky5/UHml7LLU1nWGFm/lDkbwaLZzYS8lrvow9W03SbHbDdk m+V+o9HrLdu2VSH+8dlz4pa1LDKUkbZDKut2v/683B5Gq6JwO/tL2RR+JAoRHG+C20zp oh6qv0MxgV2Co+VRj7u8fZ/CAyQ7HGH0h43xslFQAMfaHvBTnjApCGlRjODONu5A+G+x Pftw== X-Gm-Message-State: AKwxytcLOgWEGggCGZVQANmefBPYWaAjmDNkwJDXW0brcLeTrM64mWGd fwN3VIGKujCAJ7tqVmquTmmi0KNN6X4S7mGzX1c= X-Google-Smtp-Source: AH8x227jF4wxzEwlkDMn71Ae4gMlBgtomowuiYIWxIkchs1sZLDgZ2D3aFiWeGkDbJAVrQcaojs3aSOa2kpzbkcnlzY= X-Received: by 10.46.93.205 with SMTP id v74mr4136926lje.134.1517222709276; Mon, 29 Jan 2018 02:45:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.90.214 with HTTP; Mon, 29 Jan 2018 02:45:08 -0800 (PST) From: Nabil Benamar Date: Mon, 29 Jan 2018 10:45:08 +0000 Message-ID: To: Alexandre Petrescu Cc: Jerome Haerri , Tony Li , cjbc@it.uc3m.es, "its@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d9c5aa1b7dc0563e7f071" Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 10:45:34 -0000 --94eb2c0d9c5aa1b7dc0563e7f071 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, Jerome Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Mon, Jan 29, 2018 at 8:20 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 25/01/2018 =C3=A0 19:02, Jerome Haerri a =C3=A9crit : > >> Hi Alex, All, >> >> from the various e-mails, there is indeed issues or challenges to >> use IPv6 and underlying protocol for distributed, large scale and >> dynamic vehicular neyworks. >> >> However, I also see, again from e-mails, that there seem to always >> be a solution for each issue, weather it solves it optimaly or not. >> And most of the time, it seems to require strategies from different >> IETF WG. >> >> So, as IPWAVE might be seen as an entry point for IPv6 issues in >> vehicular environments, it could be interesting and helpful for the >> community to have a best practice document summarizing the issues, >> introducing a potential solution and linking to the right IETF workgrou= p. >> >> Of course, we can also propose enhancement, but it could be good to have >> such best practice document, no? >> > > Hi J=C3=A9r=C3=B4me, > > I would need to better understand what do you mean by a 'best practice' > document. I think you did not mean BCP like some RFCs are, but just > best practice. > > In that sense, I could think of needs of IP in OCB networks for > vehicular communications. Most people dont agree precisely how to make > an IP topology in vehicular networks. > =E2=80=8BI agree. This critical point should be examined in a futur documen= t. > > Whereas an RSU - to - OBU topology is often easily agreed (a Router to a > Host), other cases like vehicle - to - vehicle, or traffic light to > pedestrian to vehicle are less clear (who is Router? what is the subnet?)= . > =E2=80=8BVery interesting. Is there any IETF document that mention the invo= lves pedestrians is an ITS context? In most cases, pedestrian is considered as an obstacle to avoid rather than a road user!=E2=80=8B > > The vehicular networks are still dominated by topologies little known in > IP networks: every car 'broadcasts' CAM every 500ms and every other car > tries to understand it. There is no IP network topology for it, but > that's the predominating ways in which vehicular networks do. > > Things are changing with the arrival of IoT and C-V2X: a car sends a CAM > to an IoT platform in the cloud, and the other cars look for it there, > instead of direct 'broadcasts'. That's with IP. > =E2=80=8BFog/Edge computing is also =E2=80=8Ba raising star in this context= ! > > Along this line of thought, it could be possible to write something > about 'best practices' of using IP in vehicular networks, including OCB. > If _I_ were to write, but how about others? > =E2=80=8BI can collaborate in the write up of such a document.=E2=80=8B > > I am not sure whether this is the kind of idea you have about 'best > practice'? > > Alex > > > >> Best Regards, >> >> J=C3=A9r=C3=B4me >> >> Envoy=C3=A9 de mon iPhone >> >> Le 25 janv. 2018 =C3=A0 18:44, Alexandre Petrescu < >>> alexandre.petrescu@gmail.com> a =C3=A9crit : >>> >>> >>> On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote: >>>> >>>>> One particular aspect of ND on OCB links is how to make ND support >>>>>> SLAAC and Mobile IP between a Road-Side Unit and an On-Board Unit. = On WiFi >>>>>> links, a Host (role of OBU) receives an RA with a prefix and configu= res an >>>>>> address, which becomes a Care-of Address and triggers a BU. But on = OCB >>>>>> links, the Host may receive RA from distinct RSUs, without knowing >>>>>> which is the 'right' RSU to connect to. (on wifi the Host >>>>>> knows which is the 'right' Access Point because the user sets >>>>>> an ESSID to connect to; in OCB there is on ESSID, or, >>>>>> otherwise put, there is a single ESSID for everybody, called >>>>>> '*=E2=80=99). >>>>>> >>>>> >>>>> >>>>> This assumes that the Wi-Fi AP and the router are co-located, which i= s >>>>> definitely not required. You can easily have a Wi-FI topology with >>>>> multiple routers sending RAs where the routers sit behind the AP or a= re >>>>> clients themselves. >>>>> >>>> >>> I agree, but whereas in WiFi the Access Points have an option to >>> 'bridge', in 802.11 OCB trials the Road-Side Units are rarely bridges, = and >>> are often routers. But I agree it is possible to >>> make RSUs as Access Points, and the RA to come from single router. >>> >>>> I agree that there=E2=80=99s a problem of knowing the right OCB link >>>>> to make, but that seems completely independent of ND. >>>>> >>>> >>> Well, it depends how those (new?) 802.11 OCB unrouter Access >>> Points are made. If they are wrongly made to bridge an NA from the >>> Router by substituting its the src MAC address for the Router's, >>> _and_ not include a SLLA option (source link-layer address) of the >>> ND protocol, then we have a problem. >>> >>> The solution would be to recommend to 80211 OCB AP bridge makers >>> to MUST include SLLA if they substitute the src. >>> >>> I have seen this problem in the past with other bridges. >>> >>> And no, this would not indeed solve the problem of OBU deciding which i= s >>> the right OCB to connect to. >>> >>> But I think that if there is something that could help the OBU to decid= e >>> which OCB to connect to, then it must be in the ND, because that's the >>> first protocol run. >>> >>> Another aspect of ND on OCB links relates to the use of OCB between two >>>>>> vehicles (not between the vehicle and the RSU). On such an OCB link = there >>>>>> may be no RA dedicated to SLAAC, and the addresses used are link-loc= al >>>>>> addresses. But there could be RA to exchange the prefixes that are >>>>>> configured _inside_ the cars. And, the use of MLDv2 is mandatory on= these >>>>>> OCB links between two cars. >>>>>> >>>>> >>>>> >>>>> One might also consider using a routing protocol, as exchanging >>>>> prefix reachability is the purpose of routing protocols. Even >>>>> RIP would suffice for this application. >>>>> >>>> >>> I agree. >>> >>> There a few Internet Drafts for ND for prefix exchanges between >>> the cars. But I lost my implementation(s), I forgot where they >>> are. >>> >>> As such I asked a colleague to solve the problem of car to car >>> communications without prefixes in ND and he came up with... >>> Babel. It's open source, stored somewhere well known and apparently >>> it works in practice, on a table. >>> >>> We may need to see whether it, Babel, scales well with a 10- or 100-car >>> convoy of vehicles aligned, or whether it has too heavy in computing ne= eds >>> for small in-car platforms, or whether it can help to _form_ the convoy >>> (cars joining each other, or car pulling >>> other cars for fleet rebalancing). >>> >>> Alex >>> >>> >>>>> Tony >>>>> >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --94eb2c0d9c5aa1b7dc0563e7f071 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex, Jerome

=


Best regards
Nabil Benamar
--------= -----------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88




=

On Mon, Jan 29, 2018 at 8:20 AM, Alexandre P= etrescu <alexandre.petrescu@gmail.com> wrote:
=


Le 25/01/2018 =C3=A0 19:02, Jerome Haerri a =C3=A9crit :
Hi Alex, All,

from the various e-mails, there is indeed issues or challenges to
use IPv6 and underlying protocol for distributed, large scale and
dynamic vehicular neyworks.

However, I also see, again from e-mails, that there seem to always
be a solution for each issue, weather it solves it optimaly or not.
And most of the time, it seems to require strategies from different
IETF WG.

So, as IPWAVE might be seen as an entry point for IPv6 issues in vehicular = environments, it could be interesting and helpful for the community to have= a=C2=A0 best practice document summarizing the issues, introducing=C2=A0 a= potential solution and linking to the right IETF workgroup.

Of course, we can also propose enhancement, but it could be good to have su= ch best practice document, no?

 Hi J=C3=A9r=C3=B4me,

I would need to better understand what do you mean by a 'best practice&= #39;
document.=C2=A0 I think you did not mean BCP like some RFCs are, but just best practice.

In that sense, I could think of needs of IP in OCB networks for
vehicular communications.=C2=A0 Most people dont agree precisely how to mak= e
an IP topology in vehicular networks.

=E2=80=8BI agree. This critical point should be e= xamined in a futur document.

Whereas an RSU - to - OBU topology is often easily agreed (a Router to a Host), other cases like vehicle - to - vehicle, or traffic light to
pedestrian to vehicle are less clear (who is Router? what is the subnet?).<= br>

=E2=80=8BVer= y interesting. Is there any IETF document that mention the involves pedestr= ians is an ITS context?
In most cases,= pedestrian is considered as an obstacle to avoid rather than a road user!= =E2=80=8B

The vehicular networks are still dominated by topologies little known in IP networks: every car 'broadcasts' CAM every 500ms and every other= car
tries to understand it.=C2=A0 There is no IP network topology for it, but that's the predominating ways in which vehicular networks do.

Things are changing with the arrival of IoT and C-V2X: a car sends a CAM to an IoT platform in the cloud, and the other cars look for it there,
instead of direct 'broadcasts'.=C2=A0 That's with IP.

=E2=80=8BFog/Edge com= puting is also =E2=80=8Ba raising star in this context!

Along this line of thought, it could be possible to write something
about 'best practices' of using IP in vehicular networks, including= OCB.=C2=A0 If _I_ were to write, but how about others?

=E2=80=8BI can collaborate in t= he write up of such a document.=E2=80=8B



Best Regards,

J=C3=A9r=C3=B4me

Envoy=C3=A9 de mon iPhone

Le 25 janv. 2018 =C3=A0 18:44, Alexandre Petrescu <alexandre.petrescu@gmail.com> a =C3=A9crit :


On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote:
One particular aspect of ND on OCB links is how to make ND support SLAAC an= d Mobile IP between a Road-Side Unit and an On-Board Unit.=C2=A0 On WiFi li= nks, a Host (role of OBU) receives an RA with a prefix and configures an ad= dress, which becomes a Care-of Address and triggers a BU.=C2=A0 But on OCB = links, the Host may receive RA from distinct RSUs, without knowing
which is the 'right' RSU to connect to.=C2=A0 (on wifi the Host
knows which is the 'right' Access Point because the user sets
an ESSID to connect to; in OCB there is on ESSID, or,
otherwise put, there is a single ESSID for everybody, called
'*=E2=80=99).


This assumes that the Wi-Fi AP and the router are co-located, which is defi= nitely not required.=C2=A0 You can easily have a Wi-FI topology with multip= le routers sending RAs where the routers sit behind the AP or are clients t= hemselves.

I agree, but whereas in WiFi the Access Points have an option to 'bridg= e', in 802.11 OCB trials the Road-Side Units are rarely bridges, and ar= e often routers.=C2=A0 But I agree it is possible to
make RSUs as Access Points, and the RA to come from single router.
I agree that there=E2=80=99s a problem of knowing the right OCB link
to make, but that seems completely independent of ND.

Well, it depends how those (new?) 802.11 OCB unrouter Access
Points are made.=C2=A0 If they are wrongly made to bridge an NA from the Router by substituting its the src MAC address for the Router's,
_and_ not include a SLLA option (source link-layer address) of the
ND protocol, then we have a problem.

The solution would be to recommend to 80211 OCB AP bridge makers
to MUST include SLLA if they substitute the src.

I have seen this problem in the past with other bridges.

And no, this would not indeed solve the problem of OBU deciding which is th= e right OCB to connect to.

But I think that if there is something that could help the OBU to decide wh= ich OCB to connect to, then it must be in the ND, because that's the fi= rst protocol run.

Another aspect of ND on OCB links relates to the use of OCB between two veh= icles (not between the vehicle and the RSU). On such an OCB link there may = be no RA dedicated to SLAAC, and the addresses used are link-local addresse= s.=C2=A0 But there could be RA to exchange the prefixes that are configured= _inside_ the cars.=C2=A0 And, the use of MLDv2 is mandatory on these OCB l= inks between two cars.


One might also consider using a routing protocol, as exchanging
prefix reachability is the purpose of routing protocols.=C2=A0 Even
RIP would suffice for this application.

I agree.

There a few Internet Drafts for ND for prefix exchanges between
the cars.=C2=A0 But I lost my implementation(s), I forgot where they
are.

As such I asked a colleague to solve the problem of car to car communicatio= ns without prefixes in ND and he came up with...
Babel. It's open source, stored somewhere well known and apparently
it works in practice, on a table.

We may need to see whether it, Babel, scales well with a 10- or 100-car con= voy of vehicles aligned, or whether it has too heavy in computing needs for= small in-car platforms, or whether it can help to _form_ the convoy (cars = joining each other, or car pulling
other cars for fleet rebalancing).

Alex


Tony

_______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its

_______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its



_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

--94eb2c0d9c5aa1b7dc0563e7f071-- From nobody Mon Jan 29 02:45:41 2018 Return-Path: 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 5174A12E054 for ; Mon, 29 Jan 2018 02:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 slua-WUL0Xjr for ; Mon, 29 Jan 2018 02:45:33 -0800 (PST) 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 D295812E8AC for ; Mon, 29 Jan 2018 02:45:11 -0800 (PST) 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 w0TAj9Pj029518 for ; Mon, 29 Jan 2018 11:45:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E29F52024DE for ; Mon, 29 Jan 2018 11:45:09 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D8A7A200DAB for ; Mon, 29 Jan 2018 11:45:09 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0TAj9bZ005454 for ; Mon, 29 Jan 2018 11:45:09 +0100 To: its@ietf.org References: <1516789512.9922.18.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <053ea589-1552-2ae0-1f76-ccb7e09c4adf@gmail.com> Date: Mon, 29 Jan 2018 11:45:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1516789512.9922.18.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 10:45:35 -0000 Hi, "802.11p" is no longer existing. Now there is OCB mode in 802.11. But, there are potential evolutions from the term "802.11p": - 802.11"px" see references. - OCB mode for 802.11ac ath10k to realize 1GBps for inter-car communications. Linux kernel has an almost complete OCB mode in the mainstream. Not sure it works with ath10k. - other evolutions of 802.11 for vehicular communications. We could consider putting IP on each of these. Alex References: [18] NPRM commenting, by CAR 2 CAR Communication Consortium, Appendix 7.1 Evolution towards IEEE 802.11px. Publicly available on the web. [] ITS(17)028012_Whitepaper_NXP-Autotalks.pdf mentions "802.11px" document at ETSI. [] NHTSA_V2V_NPRM_-_Cohda_Wireless_Comments_final.pdf Publicly available on the web. Le 24/01/2018 à 11:25, Carlos Jesús Bernardos Cano a écrit : > Hi, > > Now that our first document is close to be shipped to the IESG for IETF > LC, the chairs and AD are starting to plan on potential rechartering > (as we anticipated in Singapore). > > There are a number of things people have discussed in the past, > including the time of the BoFs. Now it is time to bring in the > ideas and suggest them on the mailing list. > > Please, keep in mind some important considerations/constraints: > > - We will schedule time on the f2f session in London for rechartering > discussion, _only if_ discussion has taken place on the mailing list. > So please, do not wait for the call for presentations during the > meeting to propose topics. > > - Our current charter includes a "Problem Statement" item, which is > addressed in the document draft-ietf-ipwave-vehicular-networking. > Obviously, potential topics for rechartering should be covered there > (it will not make sense to work on topics that the community has not > agreed to be important and remain unsolved). > > - A rechartering process will always take into account the energy level > of the WG and the completion level of the current milestones. This > means that we need to finish (submit to the IESG) our 2 documents > before we actually start working on the new topics. > > Please, share your thoughts on the mailing list! > > Thanks, > > Carlos and Russs > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Jan 29 03:02:34 2018 Return-Path: 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 0D86712E89C for ; Mon, 29 Jan 2018 03:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 H8XcXDc5v0gg for ; Mon, 29 Jan 2018 03:02:24 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 2171412E897 for ; Mon, 29 Jan 2018 03:02:17 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w0TB2G3b029829; Mon, 29 Jan 2018 12:02:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EB09A2012C0; Mon, 29 Jan 2018 12:02:15 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D708B200E72; Mon, 29 Jan 2018 12:02:15 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0TB2FXK019975; Mon, 29 Jan 2018 12:02:15 +0100 To: Nabil Benamar Cc: Jerome Haerri , Tony Li , cjbc@it.uc3m.es, "its@ietf.org" References: From: Alexandre Petrescu Message-ID: Date: Mon, 29 Jan 2018 12:02:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 11:02:32 -0000 Le 29/01/2018 à 11:45, Nabil Benamar a écrit : > Hi Alex, Jerome > > > > Best regards > Nabil Benamar > ------------------- > نبيل بنعمرو > > > > > > > On Mon, Jan 29, 2018 at 8:20 AM, Alexandre Petrescu > > wrote: > > > > Le 25/01/2018 à 19:02, Jerome Haerri a écrit : > > Hi Alex, All, > > from the various e-mails, there is indeed issues or challenges to > use IPv6 and underlying protocol for distributed, large scale and > dynamic vehicular neyworks. > > However, I also see, again from e-mails, that there seem to always > be a solution for each issue, weather it solves it optimaly or not. > And most of the time, it seems to require strategies from different > IETF WG. > > So, as IPWAVE might be seen as an entry point for IPv6 issues in > vehicular environments, it could be interesting and helpful for > the community to have a  best practice document summarizing the > issues, introducing  a potential solution and linking to the > right IETF workgroup. > > Of course, we can also propose enhancement, but it could be good > to have such best practice document, no? > > > Hi Jérôme, > > I would need to better understand what do you mean by a 'best practice' > document.  I think you did not mean BCP like some RFCs are, but just > best practice. > > In that sense, I could think of needs of IP in OCB networks for > vehicular communications.  Most people dont agree precisely how to make > an IP topology in vehicular networks. > > > ​I agree. This critical point should be examined in a futur document. > > > Whereas an RSU - to - OBU topology is often easily agreed (a Router to a > Host), other cases like vehicle - to - vehicle, or traffic light to > pedestrian to vehicle are less clear (who is Router? what is the > subnet?). > > > ​Very interesting. Is there any IETF document that mention the involves > pedestrians is an ITS context? I have not seen an IETF document in this context. I meant the use-case of traffic lights webcam detecting the pedestrian and warning the approaching car. There are many products that do this. Last I saw was from Neavia. > In most cases, pedestrian is considered as an obstacle to avoid rather > than a road user!​ YEs, a car's camera or radar detects obstacles and avoids them, or makes an emergency break. There's only in-car communication to achieve it. But when it's the webcam on the traffic lights pole (not on the car) that detects the pedestrian then that signal has to be transmitted to the car. That uses communication from traffic light to the car. > > > The vehicular networks are still dominated by topologies little known in > IP networks: every car 'broadcasts' CAM every 500ms and every other car > tries to understand it.  There is no IP network topology for it, but > that's the predominating ways in which vehicular networks do. > > Things are changing with the arrival of IoT and C-V2X: a car sends a CAM > to an IoT platform in the cloud, and the other cars look for it there, > instead of direct 'broadcasts'.  That's with IP. > > > ​Fog/Edge computing is also ​a raising star in this context! I agree. > > > Along this line of thought, it could be possible to write something > about 'best practices' of using IP in vehicular networks, including > OCB.  If _I_ were to write, but how about others? > > > ​I can collaborate in the write up of such a document.​ Let us see. Alex > > > I am not sure whether this is the kind of idea you have about 'best > practice'? > > Alex > > > > Best Regards, > > Jérôme > > Envoyé de mon iPhone > > Le 25 janv. 2018 à 18:44, Alexandre Petrescu > > a écrit : > > > On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote: > > One particular aspect of ND on OCB links is how > to make ND support SLAAC and Mobile IP between a > Road-Side Unit and an On-Board Unit.  On WiFi > links, a Host (role of OBU) receives an RA with > a prefix and configures an address, which > becomes a Care-of Address and triggers a BU. > But on OCB links, the Host may receive RA from > distinct RSUs, without knowing > which is the 'right' RSU to connect to.  (on > wifi the Host > knows which is the 'right' Access Point because > the user sets > an ESSID to connect to; in OCB there is on > ESSID, or, > otherwise put, there is a single ESSID for > everybody, called > '*’). > > > > This assumes that the Wi-Fi AP and the router are > co-located, which is definitely not required.  You > can easily have a Wi-FI topology with multiple > routers sending RAs where the routers sit behind the > AP or are clients themselves. > > > I agree, but whereas in WiFi the Access Points have an > option to 'bridge', in 802.11 OCB trials the Road-Side Units > are rarely bridges, and are often routers.  But I agree it > is possible to > make RSUs as Access Points, and the RA to come from single > router. > > I agree that there’s a problem of knowing the right > OCB link > to make, but that seems completely independent of ND. > > > Well, it depends how those (new?) 802.11 OCB unrouter Access > Points are made.  If they are wrongly made to bridge an NA > from the > Router by substituting its the src MAC address for the Router's, > _and_ not include a SLLA option (source link-layer address) > of the > ND protocol, then we have a problem. > > The solution would be to recommend to 80211 OCB AP bridge makers > to MUST include SLLA if they substitute the src. > > I have seen this problem in the past with other bridges. > > And no, this would not indeed solve the problem of OBU > deciding which is the right OCB to connect to. > > But I think that if there is something that could help the > OBU to decide which OCB to connect to, then it must be in > the ND, because that's the first protocol run. > > Another aspect of ND on OCB links relates to the > use of OCB between two vehicles (not between the > vehicle and the RSU). On such an OCB link there > may be no RA dedicated to SLAAC, and the > addresses used are link-local addresses.  But > there could be RA to exchange the prefixes that > are configured _inside_ the cars.  And, the use > of MLDv2 is mandatory on these OCB links between > two cars. > > > > One might also consider using a routing protocol, as > exchanging > prefix reachability is the purpose of routing > protocols.  Even > RIP would suffice for this application. > > > I agree. > > There a few Internet Drafts for ND for prefix exchanges between > the cars.  But I lost my implementation(s), I forgot where they > are. > > As such I asked a colleague to solve the problem of car to > car communications without prefixes in ND and he came up with... > Babel. It's open source, stored somewhere well known and > apparently > it works in practice, on a table. > > We may need to see whether it, Babel, scales well with a 10- > or 100-car convoy of vehicles aligned, or whether it has too > heavy in computing needs for small in-car platforms, or > whether it can help to _form_ the convoy (cars joining each > other, or car pulling > other cars for fleet rebalancing). > > Alex > > > Tony > > _______________________________________________ its > mailing list its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing > list its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > From nobody Mon Jan 29 06:45:17 2018 Return-Path: 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 991AD12EC6A for ; Mon, 29 Jan 2018 06:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 X2US7XfhKTQc for ; Mon, 29 Jan 2018 06:45:12 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6013192F for ; Mon, 29 Jan 2018 06:41:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,431,1511823600"; d="scan'208";a="7577301" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 29 Jan 2018 15:41:31 +0100 Received: from xerus29 (unknown [192.168.200.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 192051A2C; Mon, 29 Jan 2018 15:41:29 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <1516789512.9922.18.camel@it.uc3m.es> <053ea589-1552-2ae0-1f76-ccb7e09c4adf@gmail.com> In-Reply-To: <053ea589-1552-2ae0-1f76-ccb7e09c4adf@gmail.com> Date: Mon, 29 Jan 2018 15:41:24 +0100 Organization: EURECOM Message-ID: <004501d3990f$40b0bcc0$c2123640$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ4lciqt2HPEpAx4XFU2KLeE5EfAQIPBNgNojB5rIA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 14:45:16 -0000 Hi Alex, All Indeed...some on-going work in that direction...maybe simply referred to = as ITS-G5 evolution (or DSRC evolutions)... Another aspect, that actually might be controversial, but be worth at = least discussing at the London meeting is C-V2X...there is no big issue = to adapt IP over 3GPP LTE-V2X rel.14. All is specified...but the = optimization is lacking...we are currently facing the same challenges as = for pure ITS_G5 when it comes to IPv6 address configuration...and as for = ITS-G5, if IETF targets a C-V2X usage over IPv6, without geonet stack = (or IEEE Wave), then security comes back... Maybe C-V2X could be worth discussing...let's see, BR, J=C3=A9r=C3=B4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday 29 January 2018 11:45 To: its@ietf.org Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB = for 802.11ac in ath10k Hi, "802.11p" is no longer existing. Now there is OCB mode in 802.11. But, there are potential evolutions from the term "802.11p": - 802.11"px" see references. - OCB mode for 802.11ac ath10k to realize 1GBps for inter-car communications. Linux kernel has an almost complete OCB mode in the mainstream. Not sure it works with ath10k. - other evolutions of 802.11 for vehicular communications. We could consider putting IP on each of these. Alex References: [18] NPRM commenting, by CAR 2 CAR Communication Consortium, Appendix 7.1 Evolution towards IEEE 802.11px. Publicly available on the web. [] ITS(17)028012_Whitepaper_NXP-Autotalks.pdf mentions "802.11px" document at ETSI. [] NHTSA_V2V_NPRM_-_Cohda_Wireless_Comments_final.pdf Publicly available on the web. Le 24/01/2018 =C3=A0 11:25, Carlos Jes=C3=BAs Bernardos Cano a = =C3=A9crit : > Hi, >=20 > Now that our first document is close to be shipped to the IESG for=20 > IETF LC, the chairs and AD are starting to plan on potential=20 > rechartering (as we anticipated in Singapore). >=20 > There are a number of things people have discussed in the past,=20 > including the time of the BoFs. Now it is time to bring in the ideas=20 > and suggest them on the mailing list. >=20 > Please, keep in mind some important considerations/constraints: >=20 > - We will schedule time on the f2f session in London for rechartering=20 > discussion, _only if_ discussion has taken place on the mailing list. > So please, do not wait for the call for presentations during the=20 > meeting to propose topics. >=20 > - Our current charter includes a "Problem Statement" item, which is=20 > addressed in the document draft-ietf-ipwave-vehicular-networking. > Obviously, potential topics for rechartering should be covered there=20 > (it will not make sense to work on topics that the community has not=20 > agreed to be important and remain unsolved). >=20 > - A rechartering process will always take into account the energy=20 > level of the WG and the completion level of the current milestones.=20 > This means that we need to finish (submit to the IESG) our 2 documents = > before we actually start working on the new topics. >=20 > Please, share your thoughts on the mailing list! >=20 > Thanks, >=20 > Carlos and Russs >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Jan 29 06:52:18 2018 Return-Path: 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 67FAD12EB9B for ; Mon, 29 Jan 2018 06:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EuNaIbKf2cfX for ; Mon, 29 Jan 2018 06:52:12 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B754012025C for ; Mon, 29 Jan 2018 06:52:11 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id l29so5808071qkj.8 for ; Mon, 29 Jan 2018 06:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=xScmAGsMeaKISUbDI1x+RRv+MaRRrZ65YyzkaesI2yQ=; b=oZDnQgSqeobqT10Rh9jjz72LOSRVY97jN9c5aCBMbi2CxWTIVDxCKcbMK5Bb0BstaO MGlh+EtxvVxGEL+iERQQm3zluvLnZt4uhGELR919VGP/iR7zkrtFKGWgdVDaob3C3jmy 59GF34/yfTGtRZ226KDIrMxf8kcU3Ak96zkk1mmqsCJ29GErTvXbTBysrFMrdYKxwRGE TW1wCfihQrYOPu9qjDUIFE9yb/wXCGhIkYoJxUMfksyEguS1V0IRKIpB3XlC1Z2HJpn7 n86yWkPMJ+9zP0oBtA9MaeobUeJek5CmNFlq12nB5pvWPGVhH2GeFuXn+xx5hedMa1hC iQag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=xScmAGsMeaKISUbDI1x+RRv+MaRRrZ65YyzkaesI2yQ=; b=LSchaJBmZXUthBQXnOjO30sOWa2t1z8GFXHAm7OjbND99Uf/y+Fp9bVWJpFMySru+a d/a+og+OULX7T6h0tZCGoqlAvzcbOPedzG3/E8xydXvOrKQAXpmoienGHcbyvG//DjM5 zPGBanRxOCWMehpIAVpAFFj9p0NgdzYvNegjZ/xBe/40+nsPxLSBdj3MHM7LUxbjuSz7 gj3WWoWwg/Y/c8/AMwBBpCttfp9J1qB9k5uoo5U1TvSfzcHUJb5rLnpTg32PAXJ8oA22 88N3CDNWK3Oeo/Sf1aA6xqk+XkL58nUEjyyD57VH9+m9khI0EU1lPRpTI9WB5u4gwlln f1hg== X-Gm-Message-State: AKwxytd5opJn/DWxCcrCEg0YGlEYY7ZpFUxsUeSI/M7p/el9uFpup3ql 0Osov+bFkxYDYD1sc95rvwQp7w== X-Google-Smtp-Source: AH8x227HfSThsJ4tpNZ7ySZwzxT9rPz6AztAqm6Stu189SnM3mW2Px1twS21pomE0yGpWWc7U+Nc7Q== X-Received: by 10.55.54.210 with SMTP id d201mr36234542qka.213.1517237530811; Mon, 29 Jan 2018 06:52:10 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id x10sm7505174qkl.83.2018.01.29.06.52.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 06:52:10 -0800 (PST) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: Cc: References: <1517217856.4315.32.camel@it.uc3m.es> In-Reply-To: <1517217856.4315.32.camel@it.uc3m.es> Date: Mon, 29 Jan 2018 09:52:09 -0500 Message-ID: <006601d39910$bdcf1cf0$396d56d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D398E6.D4FB5EE0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28qE71lzA Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 14:52:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01D398E6.D4FB5EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My comments are within the text [Fygs.......]. Sincerely, Francois Simon -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Carlos Jes=FAs = Bernardos Cano Sent: Monday, January 29, 2018 4:24 AM To: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; its@ietf.org Cc: Russ Housley ; suresh@kaloom.com Subject: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Hi, (Suresh, please check a question that I make below.) I'm the doc shepherd of this draft. I've performed a review and I have = the following comments: - The document's intended status is "Standards Track", but the way it is written and most of its content looks more like an Informational/BCP = kind of document. There no normative text applicable to what needs to be done to transmit IPv6 packets over IEEE 802.11-OCB. This has been discussed = during the F2F meeting in Singapore and needs to be tackled. In many parts of the document, it seems that the main conclusion is that "nothing different from IPv6 over IEEE 802.11 needs to be done for IEEE 802.11-OCB" (at least for the current scope of the doc). If that is the case, maybe the document should be Informational and reflect just some recommendations. If there is something else that needs to be done, then = it has to be more clearly stated (using normative text). @Suresh, can you provide some guidance on this point? - The abstract mentions that in order to transmit IPv6 packets on IEEE 802.11-OCB, "there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the = header format preceding the IPv6 header, the Type value within it, and others". = But the MTU part of the draft does not use any normative text, the header format is exactly the same than for IEEE 802.11, as the type value. - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet. The first one is not different from regular 802.11, but for the second = one, the document only provides recommendations. - I always thought that "WiFi" does not stand for "Wireless Fidelity". See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html [Fygs: It does stand for "Wireless Fidelity"] - The use of MAY (to be interpreted as in RFC2119) in the terminology section does not seem appropriate to me. I don't think normative text applies to whether an OBRU may be ab IP router. - In the terminology section, the OBU term is mentioned to be defined outside the IETF. This is fine, but we have to provide a reference. And = even with that, it would not harm to include some short definition to provide context. The RSU term is also defined outside the IETF and there is = quite a lot of text provided (I think the relevant part is the last sentence, = the one starting with "The difference between..."). Both terms should be = handled in the same way. [Fygs: The definitions was issued by the FCC 20 years ago. I have = already provided that information and references multiple times.] - In section 3, it is mentioned that "the operating environment = (vehicular networks) brings in new perspectives" --> which are those (that are covered/tackled by the document? - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500 octects. If that is what is meant, this is really a normative thing that should be written using normative text. If it is just a recommendation, = then this should be clearly written as such. - All the text of section 4.2.1 is not normative, but more a report of = what is done today in existing implementations. Is there any different there = that is specific of 802.11-OCB? - All subsections 4.x seem informative, not normative. - The privacy part of section 5 is important, as it impacts the = operation of IPv6 over this type of networks, so I think this deserves more = attention. - In section 5, "amd" --> "and". - In section, H.1, more details about how the captures were obtained = should be provided (HW, SW, etc.). Authors, please respond to my questions/comments and address them in a = new version of the document. Thanks, Carlos _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_0067_01D398E6.D4FB5EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

My comments = are within the = text [Fygs.......].

Sincerely,

Francois Simon

-----Original = Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of Carlos Jes=FAs Bernardos Cano
Sent: Monday, January 29, 2018 4:24 AM
To: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; its@ietf.org
Cc: Russ Housley <housley@vigilsec.com>; suresh@kaloom.com
Subject: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Hi,

(Suresh, please = check a question that I make below.)

I'm the doc = shepherd of this draft. I've performed a review and I have the following = comments:

- The = document's intended status is "Standards Track", but the way = it is written and most of its content looks more like an = Informational/BCP kind of document. There no normative text applicable = to what needs to be done to transmit IPv6 packets over IEEE 802.11-OCB. = This has been discussed during the F2F meeting in Singapore and needs to = be tackled.

In many parts = of the document, it seems that the main conclusion is that "nothing = different from IPv6 over IEEE 802.11 needs to be done for IEEE = 802.11-OCB" (at least for the current scope of the doc). If that is = the case, maybe the document should be Informational and reflect just = some recommendations. If there is something else that needs to be done, = then it has to be more clearly stated (using normative = text).

@Suresh, can = you provide some guidance on this point?

- The abstract = mentions that in order to transmit IPv6 packets on IEEE 802.11-OCB, = "there is a need to define a few parameters such as the supported = Maximum Transmission Unit size on the 802.11-OCB link, the header format = preceding the IPv6 header, the Type value within it, and others". = But the MTU part of the draft does not use any normative text,  the = header format is exactly the same than for IEEE 802.11, as the type = value.

- Section 1 = lists two exceptions for 802.11-OCB compared to = Ethernet.

The first one = is not different from regular 802.11, but for the second one, the = document only provides recommendations.

- I always = thought that "WiFi" does not stand for "Wireless = Fidelity".

See https://boingboing.net/2005/11/08/wifi-isnt-short-for.ht= ml

[Fygs: It does stand for "Wireless = Fidelity"]

- The use of = MAY (to be interpreted as in RFC2119) in the terminology section does = not seem appropriate to me. I don't think normative text applies to = whether an OBRU may be ab IP router.

- In the = terminology section, the OBU term is mentioned to be defined outside the = IETF. This is fine, but we have to provide a reference. And even with = that, it would not harm to include some short definition to provide = context. The RSU term is also defined outside the IETF and there is = quite a lot of text provided (I think the relevant part is the last = sentence, the one starting with "The difference between..."). = Both terms should be handled in the same way.

[Fygs: The = definitions was issued = by the FCC 20 years ago.  I have already provided that = information and references multiple = times.]

- In section 3, = it is mentioned that "the operating environment (vehicular = networks) brings in new perspectives" --> which are those (that = are covered/tackled by the document?

- In section = 4.1, does the text mean that the MTU SHOULD/MUST be 1500 octects. If = that is what is meant, this is really a normative thing that should be = written using normative text. If it is just a recommendation, then this = should be clearly written as such.

- All the text = of section 4.2.1 is not normative, but more a report of what is done = today in existing implementations. Is there any different there that is = specific of 802.11-OCB?

- All = subsections 4.x seem informative, not normative.

- The privacy = part of section 5 is important, as it impacts the operation of IPv6 over = this type of networks, so I think this deserves more = attention.

- In section 5, = "amd" --> "and".

- In section, = H.1, more details about how the captures were obtained should be = provided (HW, SW, etc.).

Authors, please = respond to my questions/comments and address them in a new version of = the document.

Thanks,

Carlos

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

------=_NextPart_000_0067_01D398E6.D4FB5EE0-- From nobody Mon Jan 29 07:12:09 2018 Return-Path: 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 5FA17131934 for ; Mon, 29 Jan 2018 07:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 RuVrZFk3FNVc for ; Mon, 29 Jan 2018 07:12:05 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 CD58D131932 for ; Mon, 29 Jan 2018 07:07:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w0TF7lIi040055 for ; Mon, 29 Jan 2018 16:07:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C57EB2062C3 for ; Mon, 29 Jan 2018 16:07:47 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B1EDD200E72 for ; Mon, 29 Jan 2018 16:07:47 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0TF7lpn028397 for ; Mon, 29 Jan 2018 16:07:47 +0100 To: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 29 Jan 2018 16:07:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <006601d39910$bdcf1cf0$396d56d0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 15:12:07 -0000 Le 29/01/2018 à 15:52, François Simon a écrit : > My comments arewithin the text*[Fygs.......]*. [...] > In the terminology section, the OBU term is mentioned to be defined > outside the IETF. This is fine, but we have to provide a reference. > And even with that, it would not harm to include some short > definition to provide context. The RSU term is also defined outside > the IETF and there is quite a lot of text provided (I think the > relevant part is the last sentence, the one starting with "The > difference between..."). Both terms should be handled in the same > way. > > *[Fygs: The**definitions**was issued by the FCC 20 years ago. I have > already provided that information**and references multiple > times.]*** The problem with the FCC definition of OBU is that it has no relationship to IP. Worse, that FCC definition has no indication that it MAY use IP somehow. And here we say that all OBUs must use IP. Do you see what I mean? Do you think FCC will mind if we use the term OBU in this draft to mean something else? I, and a colleague, think that FCC would not mind. Alex From nobody Mon Jan 29 07:45:13 2018 Return-Path: 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 BC57112DA4E for ; Mon, 29 Jan 2018 07:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eZzWHSsKPgd5 for ; Mon, 29 Jan 2018 07:45:09 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A7112EBB9 for ; Mon, 29 Jan 2018 07:45:09 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id o35so13163889qtj.13 for ; Mon, 29 Jan 2018 07:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=v2SRvIQkPhvtKAMa2D8Ndc9sukbRBplhW6IvoDAK9j4=; b=KlzHwClYWpGJ1quv1OtlrjFi0vcT8gidaiD/zFLSQCrJSMXlkq7O7loYL28ynz17Xz t6Qd4xD1aWFEdjePh+Z7MleHTYofSY0Cf8iAngURc6uPsrbi8uBOQ8WmCKfYqi+p6pQ2 RkhAF3rd3aDJcbhobF+YHf6DddZnoMBa4nHSxGCu+vT3rBgIOTJNOyS0t7eFdSQth1g9 uKO4HNKGwxz+3bRGeEybwVwo9Yhk53hWA+9L0dotzhUK28ZCxPuBKzT9rh43TW4zhoG5 wtvnQ+zPUre4BT+7k/+ovc1ZVYCDm1RvTYmty9rbSW1x/8fbluYMIrj/ldk+nmSU7RDW P8DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=v2SRvIQkPhvtKAMa2D8Ndc9sukbRBplhW6IvoDAK9j4=; b=drKqMtInE1XMYgWnY51V3T476/TRweGVpWTWNShH3CYHvNMFJBqd9H4OMTk6IA185+ JLjiwlzdoXpyLsOIWYP0oqFxbiOC5l9gWHFqPhWrfKrBBunIzyc5nIg8IE0IhklIoCem a9RXcVif8IPs+wW6ao1CghkgOkknB6GZcPACFEk48H+20+jFXARXkM61m1dPg4tFJqDN MNdRFmAtq2LLfSKs8fEeGoBKvTmvgx54SXn2KYX1Erjnve1qL+btk9iiPrHalndss/4q ijLcsZD4YgzS/RV2xJ9PI2m0JbgWj7CGJHL6cCyBJl3A2H6NXCnVkOlIe3qhwKHym2oo gyIg== X-Gm-Message-State: AKwxytfHvjRzjfE6MEiTM6DZaaU741nYSQ2hviwZgG3GbxLTFj+Cgeb7 XyCanO/efVR+opyZQ4FqvHI= X-Google-Smtp-Source: AH8x225LZYzz/OCZyvcjFxfbmmtBmvzCzkqiDcK0kr90GP5gze9xuvLqJVjpOD6WybPlAiXT4/cFbA== X-Received: by 10.200.40.165 with SMTP id i34mr38427283qti.176.1517240708793; Mon, 29 Jan 2018 07:45:08 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id x207sm7875488qka.91.2018.01.29.07.45.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 07:45:07 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: References: <1516789512.9922.18.camel@it.uc3m.es> <053ea589-1552-2ae0-1f76-ccb7e09c4adf@gmail.com> In-Reply-To: <053ea589-1552-2ae0-1f76-ccb7e09c4adf@gmail.com> Date: Mon, 29 Jan 2018 10:45:07 -0500 Message-ID: <007d01d39918$23e9dc30$6bbd9490$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJ4lciqt2HPEpAx4XFU2KLeE5EfAQIPBNgNojB+SiA= Archived-At: Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 15:45:12 -0000 Mr. Petrescu, Be very careful here. One cannot make "names" on behalf of IEEE 802, = such as "802.11px". I do not know what is ath10K, however, as per IEEE = 802.11-2016 (latest published standard), there is no synergy between = 802.11 OCB and 802.11ac. If there is such thing in the next release, I = am not aware of.=20 Sincerely, Francois Simon -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday, January 29, 2018 5:45 AM To: its@ietf.org Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB = for 802.11ac in ath10k Hi, "802.11p" is no longer existing. Now there is OCB mode in 802.11. But, there are potential evolutions from the term "802.11p": - 802.11"px" see references. =20 - OCB mode for 802.11ac ath10k to realize 1GBps for inter-car communications. Linux kernel has an almost complete OCB mode in the mainstream. Not sure it works with ath10k. - other evolutions of 802.11 for vehicular communications. We could consider putting IP on each of these. Alex References: [18] NPRM commenting, by CAR 2 CAR Communication Consortium, Appendix 7.1 Evolution towards IEEE 802.11px. Publicly available on the web. [] ITS(17)028012_Whitepaper_NXP-Autotalks.pdf mentions "802.11px" document at ETSI. [] NHTSA_V2V_NPRM_-_Cohda_Wireless_Comments_final.pdf Publicly available on the web. Le 24/01/2018 =C3=A0 11:25, Carlos Jes=C3=BAs Bernardos Cano a = =C3=A9crit : > Hi, >=20 > Now that our first document is close to be shipped to the IESG for=20 > IETF LC, the chairs and AD are starting to plan on potential=20 > rechartering (as we anticipated in Singapore). >=20 > There are a number of things people have discussed in the past,=20 > including the time of the BoFs. Now it is time to bring in the ideas=20 > and suggest them on the mailing list. >=20 > Please, keep in mind some important considerations/constraints: >=20 > - We will schedule time on the f2f session in London for rechartering=20 > discussion, _only if_ discussion has taken place on the mailing list. > So please, do not wait for the call for presentations during the=20 > meeting to propose topics. >=20 > - Our current charter includes a "Problem Statement" item, which is=20 > addressed in the document draft-ietf-ipwave-vehicular-networking. > Obviously, potential topics for rechartering should be covered there=20 > (it will not make sense to work on topics that the community has not=20 > agreed to be important and remain unsolved). >=20 > - A rechartering process will always take into account the energy=20 > level of the WG and the completion level of the current milestones.=20 > This means that we need to finish (submit to the IESG) our 2 documents = > before we actually start working on the new topics. >=20 > Please, share your thoughts on the mailing list! >=20 > Thanks, >=20 > Carlos and Russs >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Jan 29 10:46:52 2018 Return-Path: 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 23A1212EB6A for ; Mon, 29 Jan 2018 10:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 dmyvq49phTtw for ; Mon, 29 Jan 2018 10:46:48 -0800 (PST) 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 606EC124C27 for ; Mon, 29 Jan 2018 10:46:48 -0800 (PST) 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 w0TIkj41036000; Mon, 29 Jan 2018 19:46:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B3A1D20659C; Mon, 29 Jan 2018 19:46:45 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A60EA20647F; Mon, 29 Jan 2018 19:46:45 +0100 (CET) Received: from [132.166.84.45] ([132.166.84.45]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0TIkie0028477; Mon, 29 Jan 2018 19:46:45 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1516789512.9922.18.camel@it.uc3m.es> <053ea589-1552-2ae0-1f76-ccb7e09c4adf@gmail.com> <007d01d39918$23e9dc30$6bbd9490$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 29 Jan 2018 19:46:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <007d01d39918$23e9dc30$6bbd9490$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 18:46:51 -0000 Mr Simon, Thank you for the remark. For ath10k: it is the name of an open source driver from company Atheros (no advertisement). It is very well known in the software developper community. Its earlier versions - ath5k and ath9k - is what was used in very many prototypes of old 802.11p. For 802.11"px": it is a name invented not by me, I just repeated it. I agree it does not correspond to an official 802.11 activity (like e.g. 802.11ax). I do not know whether 802.11 groups consider the use of 802.11ac in OCB mode. I would be curious if they did. For 802.11p: many people in standards, software and hardware community related to ITS continue to say, write and label "802.11p" even though such thing does not exist anymore. I think it will take time for this to disappear. Alex Le 29/01/2018 à 16:45, François Simon a écrit : > Mr. Petrescu, > > Be very careful here. One cannot make "names" on behalf of IEEE 802, such as "802.11px". I do not know what is ath10K, however, as per IEEE 802.11-2016 (latest published standard), there is no synergy between 802.11 OCB and 802.11ac. If there is such thing in the next release, I am not aware of. > > Sincerely, > > Francois Simon > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Monday, January 29, 2018 5:45 AM > To: its@ietf.org > Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k > > Hi, > > "802.11p" is no longer existing. Now there is OCB mode in 802.11. > > But, there are potential evolutions from the term "802.11p": > > - 802.11"px" see references. > - OCB mode for 802.11ac ath10k to realize 1GBps for inter-car > communications. Linux kernel has an almost complete OCB mode > in the mainstream. Not sure it works with ath10k. > - other evolutions of 802.11 for vehicular communications. > > We could consider putting IP on each of these. > > Alex > > References: > [18] NPRM commenting, by CAR 2 CAR Communication Consortium, Appendix > 7.1 Evolution towards IEEE 802.11px. > Publicly available on the web. > [] ITS(17)028012_Whitepaper_NXP-Autotalks.pdf mentions "802.11px" > document at ETSI. > [] NHTSA_V2V_NPRM_-_Cohda_Wireless_Comments_final.pdf > Publicly available on the web. > > Le 24/01/2018 à 11:25, Carlos Jesús Bernardos Cano a écrit : >> Hi, >> >> Now that our first document is close to be shipped to the IESG for >> IETF LC, the chairs and AD are starting to plan on potential >> rechartering (as we anticipated in Singapore). >> >> There are a number of things people have discussed in the past, >> including the time of the BoFs. Now it is time to bring in the ideas >> and suggest them on the mailing list. >> >> Please, keep in mind some important considerations/constraints: >> >> - We will schedule time on the f2f session in London for rechartering >> discussion, _only if_ discussion has taken place on the mailing list. >> So please, do not wait for the call for presentations during the >> meeting to propose topics. >> >> - Our current charter includes a "Problem Statement" item, which is >> addressed in the document draft-ietf-ipwave-vehicular-networking. >> Obviously, potential topics for rechartering should be covered there >> (it will not make sense to work on topics that the community has not >> agreed to be important and remain unsolved). >> >> - A rechartering process will always take into account the energy >> level of the WG and the completion level of the current milestones. >> This means that we need to finish (submit to the IESG) our 2 documents >> before we actually start working on the new topics. >> >> Please, share your thoughts on the mailing list! >> >> Thanks, >> >> Carlos and Russs >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Jan 30 13:33:50 2018 Return-Path: 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 ACCF212FB22 for ; Tue, 30 Jan 2018 13:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 8LRmiEIBdg37 for ; Tue, 30 Jan 2018 13:33:45 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995A512F5DB for ; Tue, 30 Jan 2018 13:33:44 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id 141so3983680wme.3 for ; Tue, 30 Jan 2018 13:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=VldmMVRFVOSDdOEt/lybsbm7lqdk3PRTmXsXAkdLBTI=; b=P6PdWGBTZf4dAIji72NstY3/TSZBLghczgiS7jJmIS0JZ1qz4TuFDoxpBY/66KwwWw 60H3lWg/BE0TfTzfgrNpaNqE6/u1JEvsZK0TxwrjKTGm5a1zDVbZo7KCkSjroUwztJug SBsOnftqazce/DrdmL1y7eCoujwMo5x5Ngnjl+UFj4DC1LhPLbHSv81E6/J98zHrmKvn VIJ/O/cR20OAAPNvS3oFOWfbSQ/bP/lYOkkCTEDorOwsbrRBpm3rpYW95MdRVtID8JoE dcLq0jTUZkw0ZEmltbVsh1OvNi5I5i4qCevWdQJ6YKhLh3B8SRlUMtzz5Lc/yhI3Sh5e 014A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=VldmMVRFVOSDdOEt/lybsbm7lqdk3PRTmXsXAkdLBTI=; b=TCpPItnIGdo4W/8U23SDPL77PWU8JFvyMNQsNcNC1BF7RhPlFLRsaiEzRpFHexnw1Z P3fbFpd9mmRnp+B2JBX6lresQheAxaP1Mwu93/sS28oslMcmZUM2iBy5Vh1HgBEXnNA4 iNGNrGkF3Czx9mxRaELfggVhVW2D4/iUOlCps6tbxxYhx724YZ0DHGUcNk8EO532MYrv gvpRBqBDreyFuZIvH0rNq5TvVKGmnqgUTr4jh9qoawgySfX0KBj9EMaBs1c9PGqzJrm2 945DVsRij0OlyaZWgPAUdr5SgwZMI4Yfgoaf79ipSDh4DbXuedtuudXSV2VWYDecS9Zu EZtg== X-Gm-Message-State: AKwxytd/mVvxbGb4HZEZvv7Ai3F9hAnsEj0bg3gCQ/X2coJWvXI9yaZv DuIVR2sUpDzKQ5TaAAhWuUUa0A== X-Google-Smtp-Source: AH8x226XuWpNQeR7VGRiTTZyPNt5YVQhLP9ZveplI+fV1QHYGPTj5qiP/y5zskj98fUY/Wh5S40H1w== X-Received: by 10.28.238.202 with SMTP id j71mr21450623wmi.34.1517348023057; Tue, 30 Jan 2018 13:33:43 -0800 (PST) Received: from acorde (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id a2sm25231053wrc.53.2018.01.30.13.33.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Jan 2018 13:33:42 -0800 (PST) Message-ID: <1517348021.4079.28.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: =?ISO-8859-1?Q?Fran=E7ois?= Simon Cc: its@ietf.org Date: Tue, 30 Jan 2018 22:33:41 +0100 In-Reply-To: <006601d39910$bdcf1cf0$396d56d0$@gmail.com> References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 21:33:49 -0000 Hi François, Thanks for your comments. Please, see mine inline below. On Mon, 2018-01-29 at 09:52 -0500, François Simon wrote: > My comments are within the text [Fygs.......]. > Sincerely, > Francois Simon > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Carlos Jesús > Bernardos Cano > Sent: Monday, January 29, 2018 4:24 AM > To: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; its@ietf.org > Cc: Russ Housley ; suresh@kaloom.com > Subject: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over- > 80211ocb-12 > Hi, > (Suresh, please check a question that I make below.) > I'm the doc shepherd of this draft. I've performed a review and I > have the following comments: > - The document's intended status is "Standards Track", but the way it > is written and most of its content looks more like an > Informational/BCP kind of document. There no normative text > applicable to what needs to be done to transmit IPv6 packets over > IEEE 802.11-OCB. This has been discussed during the F2F meeting in > Singapore and needs to be tackled. > In many parts of the document, it seems that the main conclusion is > that "nothing different from IPv6 over IEEE 802.11 needs to be done > for IEEE 802.11-OCB" (at least for the current scope of the doc). If > that is the case, maybe the document should be Informational and > reflect just some recommendations. If there is something else that > needs to be done, then it has to be more clearly stated (using > normative text). > @Suresh, can you provide some guidance on this point? > - The abstract mentions that in order to transmit IPv6 packets on > IEEE 802.11-OCB, "there is a need to define a few parameters such as > the supported Maximum Transmission Unit size on the 802.11-OCB link, > the header format preceding the IPv6 header, the Type value within > it, and others". But the MTU part of the draft does not use any > normative text, the header format is exactly the same than for IEEE > 802.11, as the type value. > - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet. > The first one is not different from regular 802.11, but for the > second one, the document only provides recommendations. > - I always thought that "WiFi" does not stand for "Wireless > Fidelity". > See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html > [Fygs: It does stand for "Wireless Fidelity"] [Carlos] I'm not an expert on the matter, but people I asked told me that it does not. Not a major issue anyway... > - The use of MAY (to be interpreted as in RFC2119) in the terminology > section does not seem appropriate to me. I don't think normative text > applies to whether an OBRU may be ab IP router. > - In the terminology section, the OBU term is mentioned to be defined > outside the IETF. This is fine, but we have to provide a reference. > And even with that, it would not harm to include some short > definition to provide context. The RSU term is also defined outside > the IETF and there is quite a lot of text provided (I think the > relevant part is the last sentence, the one starting with "The > difference between..."). Both terms should be handled in the same > way. > [Fygs: The definitions was issued by the FCC 20 years ago. I have > already provided that information and references multiple times.] [Carlos] So then it should be easy to close this comment. Thanks, Carlos > - In section 3, it is mentioned that "the operating environment > (vehicular networks) brings in new perspectives" --> which are those > (that are covered/tackled by the document? > - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500 > octects. If that is what is meant, this is really a normative thing > that should be written using normative text. If it is just a > recommendation, then this should be clearly written as such. > - All the text of section 4.2.1 is not normative, but more a report > of what is done today in existing implementations. Is there any > different there that is specific of 802.11-OCB? > - All subsections 4.x seem informative, not normative. > - The privacy part of section 5 is important, as it impacts the > operation of IPv6 over this type of networks, so I think this > deserves more attention. > - In section 5, "amd" --> "and". > - In section, H.1, more details about how the captures were obtained > should be provided (HW, SW, etc.). > Authors, please respond to my questions/comments and address them in > a new version of the document. > Thanks, > Carlos > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its