Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-39
Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 16 April 2019 15:42 UTC
Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437761204C3; Tue, 16 Apr 2019 08:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEuZV4_nMBGw; Tue, 16 Apr 2019 08:42:31 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CD5120A7A; Tue, 16 Apr 2019 07:07:58 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3GE7nIn029925; Tue, 16 Apr 2019 16:07:49 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 514D2205708; Tue, 16 Apr 2019 16:07:49 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3279E202169; Tue, 16 Apr 2019 16:07:49 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3GE7nXn017469; Tue, 16 Apr 2019 16:07:49 +0200
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, nabil benamar <benamar73@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com> <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com> <11645738-6f95-82e5-48f1-ebc3ce54423e@gmail.com> <0ae10089-4b1a-f85c-1a3d-15e712cb7547@gmail.com> <084449fd-2693-0cfb-6589-0cf67cf9ffe6@gmail.com> <D8DA8E15.2F2F73%sgundave@cisco.com> <CFBFE5D0-E623-4508-BD57-5BD0C3CED985@cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <69b9071f-80c7-63c8-bb02-3fb439b2cf5b@gmail.com>
Date: Tue, 16 Apr 2019 16:07:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CFBFE5D0-E623-4508-BD57-5BD0C3CED985@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/5ZSnwtjWT--NoRdF1QGMvGR5Vts>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-39
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2019 15:42:35 -0000
Le 16/04/2019 à 12:06, Pascal Thubert (pthubert) a écrit : > Hello Sri > > If the document was clearly scoped to P2P link local communication it > would need correcting, like stop paraphrasing IEEE but it would > eventually pass. I do not know what do you mean by P2P. In my experiments we also used three cars with IP on a single subnet OCB. The term I may be using is something like P P2P if such a multidimensional term can exist. > Beyond that scope it is a matter of use cases and solutions. I do not > know what the WG decided for the former. The latter starts with > applicability of existing work, in particular WiND. > > If the group needs such functions I claim that we can already do hub > and spoke subnets with either a single node as hub (a BSS at L3) or > several nodes (that would be RSUs) connected by a high speed transit > link. This can be done using Wireless ND and can be described in a > few pages. > > I claim we can already do mesh in relatively stable situations, e.g., > relaying over cars in a parking lot to the RSU that provides > Internet. It's great to know. Did it use OCB? (we define IP-RSU to be an RSU that does OCB.) Alex > > I claim we can couple that with NEMO in the car and maintain global > reachability while on the road. > > What’s harder is to figure what’s reachable at which time. DNA and > when to form new addresses. Discover services. How to use the fixed > infrastructure to relay between cars while driving. These are some of > the real and interesting problems left to be solved by the WG whereas > reinventing the wheels could be a waste of time. > > All the best, > > Pascal > > Le 16 avr. 2019 à 05:11, Sri Gundavelli (sgundave) > <sgundave@cisco.com> a écrit : > >>> I am no expert, but I do know some physics, and it seems pretty >>> clear to me that if there are multiple lanes of traffic, a large >>> truck can easily shield signals between two cars and the >>> shielding will be intermittent, regardless of how much wireless >>> power is allowed, depending on traffic movement. So it's a highly >>> dynamic mesh network. >> >> >> Part of the problem is that we have not clearly put some limits on >> the use-cases. These unbounded limits is opening up these >> discussions on ad-hoc full mesh network formations and the >> resulting challenging ND scenarios. But, again I always assumed >> this discussion is for the ND document and there should be no >> bearing on this document. >> >> V2X communications involves V2V, V2I and V2P communication modes. >> From the point of view of vehicular safety, its about exchange of >> BSM (Basic Safety Messages) between vehicles as per SAEJ735 >> standard. These safety communications is always one-hop >> communication and for very good reason IEEE WAVE standards did not >> bother to require IPv6 transport for carrying these messages. The >> WSMP message which carries these safety elements are defined to be >> carried over layer-2 payloads. Personally, I never thought we will >> replace this L2 safety communication mode with layer-3 mode >> (IPv6-over-80211-OCB). But the use of IPv6 is more for allowing >> applications in the vehicle to communicate with the infrastructure. >> For example, a vehicle using DSRC radio to access some traffic >> application in the cloud. >> >> In one sense, this is like a mobile node using 802.11-OCB like any >> other radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its >> communications. In this context, its always about vehicle to >> infrastructure communications. Now, there are other interesting >> peer to peer use-cases, where one vehicle is streaming some video >> to another vehicle without using any infrastructure. While these >> later examples are very cool, personally, I did not expect this WG >> to solve those use-cases day-1. For us to support those use-cases, >> we need to figure out many more things including approaches for >> exchanges prefixes between two vehicles that come in proximity. In >> my mind, these are very forward looking and the only relevant >> application is platooning. I am not interested in solving this V2V >> problem, but was more interested to enable V2I communications, >> where the focus is about link model, prefix hosting approaches, >> mobility support (building a large L2 domain over RSU’s, or routed >> approaches with mobile IP type protocols) ..etc. In one >> realization, there may be a P2P link assumption between the vehicle >> and the RSU, eliminating most of these ND issues. But, those >> discussions are for the other document and that clearly should >> remove these ND concerns from this document. >> >> Sri >> >> >> >> >> >> >> On 4/15/19, 2:04 PM, "Brian E Carpenter" >> <brian.e.carpenter@gmail.com> wrote: >> >>> Excuse top posting. >>> >>> As I've said, I am no expert, but I do know some physics, and it >>> seems pretty clear to me that if there are multiple lanes of >>> traffic, a large truck can easily shield signals between two cars >>> and the shielding will be intermittent, regardless of how much >>> wireless power is allowed, depending on traffic movement. So it's >>> a highly dynamic mesh network. That's a very interesting problem >>> that has been much studied, and it's fundamentally different from >>> the ND design scenario. >>> >>> So I find it hard to believe that nobody can write the TBD text. >>> >>> Regards Brian >>> >>>> On 15-Apr-19 23:26, Alexandre Petrescu wrote: Hi Brian, >>>> >>>>> Le 14/04/2019 à 22:49, Brian E Carpenter a écrit : Hi >>>>> Alexandre, >>>>> >>>>>> On 15-Apr-19 04:38, Alexandre Petrescu wrote: Brian, >>>>>> >>>>>> Le 14/04/2019 à 04:20, Brian E Carpenter a écrit : >>>>>>>>> All we need is a simple statement in the spec which >>>>>>>>> puts some scope limits, w.r.t the missing ND pieces >>>>>>>>> and issues. >>>>>>> >>>>>>> Yes, that is clearly essential, as well as an associated >>>>>>> health warning that implementers must not rush ahead >>>>>>> because of the risk of non-interoperability. >>>>>> >>>>>> There is already paragraph, and an Appendix, about >>>>>> potential ND issues. I think that text qualifies as an >>>>>> associated health warning. >>>>>> >>>>>> I do not know what do you mean about the risk of >>>>>> interoperability. This ND that works is interoperable >>>>>> between several OCB cards, IP Road Side Units, and linuces. >>>>>> (I can cite brands that I al familiar with and that >>>>>> interoperate. >>>>>> >>>>>> This is the current paragraph and Appendix that qualify as >>>>>> a warning that you suggest: >>>>>> >>>>>>> The baseline Neighbor Discovery protocol (ND) [RFC4861] >>>>>>> MUST be used over 802.11-OCB links. Transmitting ND >>>>>>> packets may prove to have some performance issues. These >>>>>>> issues may be exacerbated in OCB mode. Solutions for >>>>>>> these problems SHOULD consider the OCB mode of operation. >>>>>>> The best of current knowledge indicates the kinds of >>>>>>> issues that may arise with ND in OCB mode; they are >>>>>>> described in Appendix J. >>>>> >>>>> That's exactly the text that I find problematic. I can't >>>>> write a new version because I lack your expert knowledge, but >>>>> IMHO it should be more specific: >>>>> >>>>> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST >>>>> be used over 802.11-OCB links. However, as on any wireless >>>>> link, transmission of multicast ND packets may fail in OCB. >>>>> In particular, scenarios where TBD TBD TBD are likely to be >>>>> unreliable and SHOULD NOT be deployed until an alternative >>>>> standardised solution is available. The best of current >>>>> knowledge indicates the kinds of issues that may arise with >>>>> ND in OCB mode; they are described in Appendix J. >>>> >>>> I can agree with that formulation and put it in the text. >>>> >>>> But I need an indicat that TBD is defined soon. The time >>>> commitments of Pascal seem to be saying he is no longer >>>> interested in writing that TBD. >>>> >>>> I wait a little for this to clarify. >>>> >>>>> Also I don't like this phrasing in Appendix J: >>>>> >>>>> Early experiences indicate that it should be possible to >>>>> exchange IPv6 packets over OCB while relying on IPv6 ND alone >>>>> for DAD and AR (Address Resolution). >>>>> >>>>> Could you rather say the opposite: >>>>> >>>>> Early experience indicates that it is possible to exchange >>>>> IPv6 packets over OCB while relying on IPv6 ND alone for DAD >>>>> and AR (Address Resolution) in good conditions. However, this >>>>> does not apply if TBD TBD TBD... >>>> >>>> This is an appendix. I could put TBD there now. >>>> >>>> Alex >>>> >>>>> >>>>> Regards Brian >>>>> >>>>> >>>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Regards Brian >>>>>>> >>>>>>>> On 14-Apr-19 13:58, NABIL BENAMAR wrote: +1 Sri >>>>>>>> >>>>>>>> On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) >>>>>>>> <sgundave@cisco.com <mailto:sgundave@cisco.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I understand your point Brian, but IMO there are >>>>>>>> enough reasons not to delay this work. >>>>>>>> >>>>>>>> There are many use-cases/applications where there is a >>>>>>>> stable topology of RSU¹s and OBU¹s. The regulations >>>>>>>> around 5.9 Ghz (DSRC) band allows the channel use for >>>>>>>> non-priority/non-traffic safety related applications. >>>>>>>> For example, a vehicle in a gas station can receive a >>>>>>>> coupon from the 802.11-OCB radio (AP/RSU) in the gas >>>>>>>> station. There, its a stable topology that classic ND >>>>>>>> is designed for. In this operating mode, its perfectly >>>>>>>> reasonable to use classic ND and it works. The authors >>>>>>>> have shown enough lab data on the same. >>>>>>>> >>>>>>>> Ideally, I agree with you that it makes lot more sense >>>>>>>> to publish both the specs at the same time. But, for >>>>>>>> what ever reasons the WG went on this path. Authors >>>>>>>> have spent incredible amount of efforts in getting the >>>>>>>> draft this far and we cannot ignore that. You can see >>>>>>>> the efforts from the version number; when did we last >>>>>>>> see a draft version -037? >>>>>>>> >>>>>>>> We also need to distill the recent ND discussions and >>>>>>>> filter out the threads that are clearly motivated to >>>>>>>> insert a ND protocol that is designed for a totally >>>>>>>> different operating environment. An argument that a >>>>>>>> protocol designed for low-power environments is the >>>>>>>> solution for vehicular environments requires some >>>>>>>> serious vetting. Looking at the characteristics, >>>>>>>> always-sleeping, occasional internet connectivity, >>>>>>>> low-power, no memory, no processing power, no mobility >>>>>>>> ..etc, meeting vehicular requirements is some thing >>>>>>>> most people in the WG do not get it. >>>>>>>> >>>>>>>> Bottom line, IMO, we should move this forward and >>>>>>>> publish the document. All we need is a simple statement >>>>>>>> in the spec which puts some scope limits, w.r.t the >>>>>>>> missing ND pieces and issues. There are other >>>>>>>> proposals in the WG that will address the gaps and >>>>>>>> bring closure to the work. >>>>>>>> >>>>>>>> Sri >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4/12/19, 1:28 PM, "Brian E Carpenter" >>>>>>>> <brian.e.carpenter@gmail.com >>>>>>>> <mailto:brian.e.carpenter@gmail.com>> wrote: >>>>>>>> >>>>>>>>>> On 13-Apr-19 02:59, Sri Gundavelli (sgundave) >>>>>>>>>> wrote: If you go back and check 2017 archives, I >>>>>>>>>> did raise many of >>>>>>>> these >>>>>>>>>> issues. But, we clearly decided to limit the >>>>>>>>>> scope >>>>>>>> excluding address >>>>>>>>>> configuration, DAD, ND aspect, link models. When >>>>>>>>>> there is >>>>>>>> such a scope >>>>>>>>>> statement, it should clearly move these comments to >>>>>>>>>> the >>>>>>>> draft that >>>>>>>>>> defines how ND works for 802.11-OCB links. >>>>>>>>> >>>>>>>>> This is of course possible. In general the IETF >>>>>>>>> hasn't done >>>>>>>> that, but has >>>>>>>>> followed the lead set by RFC 2464 with the complete >>>>>>>> specification of >>>>>>>>> IPv6-over-foo in one document. >>>>>>>>> >>>>>>>>> However, I don't believe that publishing an RFC about >>>>>>>>> the >>>>>>>> frame format >>>>>>>>> without *simultaneously* publishing an RFC about ND >>>>>>>>> etc >>>>>>>> would be a good >>>>>>>>> idea. That would leave developers absolutely unable >>>>>>>>> to write >>>>>>>> useful >>>>>>>>> code, and might easily lead to incompatible >>>>>>>>> implementations. >>>>>>>> Since >>>>>>>>> we'd presumably like Fords to be able to communicate >>>>>>>>> with >>>>>>>> Peugeots, >>>>>>>>> that seems like a bad idea. >>>>>>>>> >>>>>>>>> Regards Brian >>>>>>>> >>>>>>> >>>>>>> >>>>>> . >>>>>> >>>>> >>>>> >>>> >>> >>
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Nabil Benamar
- [ipwave] Intdir early review of draft-ietf-ipwave… Pascal Thubert
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre PETRESCU
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review ofdraft-ietf-ipw… fygsimon
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… NABIL BENAMAR
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Joel M. Halpern
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Carsten Bormann
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Rob Wilton (rwilton)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Russ Housley
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Intdir early review of draft-ietf-ip… Carsten Bormann
- Re: [ipwave] Intdir early review of draft-ietf-ip… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Intdir early review of draft-ietf-ip… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Suresh Krishnan
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] [Int-dir] Intdir early review of dra… 神明達哉
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… 神明達哉
- Re: [ipwave] Intdir early review of draft-ietf-ip… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Ole Troan
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Ole Troan
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Ole Troan
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Ole Troan
- Re: [ipwave] [Int-dir] Intdir early review of dra… Pascal Thubert (pthubert)
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… NABIL BENAMAR
- Re: [ipwave] [Int-dir] Intdir early review of dra… Ole Troan
- Re: [ipwave] [Int-dir] Intdir early review of dra… 神明達哉
- Re: [ipwave] [Int-dir] Intdir early review of dra… 神明達哉
- Re: [ipwave] Intdir early review of draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] [Int-dir] Intdir early review of dra… Brian E Carpenter
- Re: [ipwave] [Int-dir] Intdir early review of dra… Pascal Thubert (pthubert)
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre PETRESCU
- Re: [ipwave] [Int-dir] Intdir early review of dra… Ole Troan
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- [ipwave] IPv6-over-foo and Addressing Architectur… Suresh Krishnan
- Re: [ipwave] IPv6-over-foo and Addressing Archite… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… William Whyte
- Re: [ipwave] [Int-dir] Intdir early review of dra… 神明達哉
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] about V2I to traffic lights controll… Alexandre Petrescu
- Re: [ipwave] [Int-dir] Intdir early review of dra… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- Re: [ipwave] [Int-dir] Intdir early review of dra… Pascal Thubert (pthubert)
- Re: [ipwave] [Int-dir] Intdir early review of dra… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] Intdir early review of draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] [Int-dir] Intdir early review of dra… Abdussalam Baryun
- Re: [ipwave] Intdir early review of draft-ietf-ip… NABIL BENAMAR
- Re: [ipwave] Intdir early review of draft-ietf-ip… Russ Housley
- Re: [ipwave] Intdir early review of draft-ietf-ip… Nabil Benamar
- Re: [ipwave] Intdir early review of draft-ietf-ip… Sri Gundavelli (sgundave)
- Re: [ipwave] Intdir early review of draft-ietf-ip… NABIL BENAMAR
- Re: [ipwave] Intdir early review of draft-ietf-ip… Sri Gundavelli (sgundave)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] Intdir early review of draft-ietf-ip… Pascal Thubert (pthubert)
- [ipwave] link-local text (Re: [Int-dir] Intdir ea… 神明達哉
- Re: [ipwave] [Int-dir] Intdir early review of dra… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] Intdir early review of draft-ietf-ip… Sri Gundavelli (sgundave)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Abdussalam Baryun
- Re: [ipwave] Intdir early review of draft-ietf-ip… NABIL BENAMAR
- Re: [ipwave] Intdir early review of draft-ietf-ip… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Nabil Benamar
- Re: [ipwave] Intdir early review of draft-ietf-ip… Joel M. Halpern
- Re: [ipwave] Intdir early review of draft-ietf-ip… Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Alexandre Petrescu
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Alexandre Petrescu
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Brian E Carpenter
- Re: [ipwave] Intdir early review of draft-ietf-ip… Brian E Carpenter
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Brian E Carpenter
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Pascal Thubert (pthubert)
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] side note RFC 4291 2nd par sec. 2.1 … Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Pascal Thubert (pthubert)
- Re: [ipwave] Intdir early review of draft-ietf-ip… Jong-Hyouk Lee
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] pencil and paper vs cars Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] Expertise on ND problems on OCB Alexandre Petrescu
- Re: [ipwave] Expertise on ND problems on OCB Charlie Perkins
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… 神明達哉
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… 神明達哉
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Pascal Thubert (pthubert)
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Brian E Carpenter
- Re: [ipwave] [Int-dir] link-local text (Re: Intdi… 神明達哉
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Brian E Carpenter
- [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb and… Brian E Carpenter
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Sri Gundavelli (sgundave)
- Re: [ipwave] Expertise on ND problems on OCB Sri Gundavelli (sgundave)
- Re: [ipwave] which BSM? Alexandre Petrescu
- Re: [ipwave] link-local text (Re: [Int-dir] Intdi… Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] which BSM? William Whyte
- Re: [ipwave] which BSM? Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Pascal Thubert (pthubert)
- Re: [ipwave] which BSM? William Whyte
- Re: [ipwave] Expertise on ND problems on OCB Alexandre Petrescu
- Re: [ipwave] which BSM? Alexandre Petrescu
- Re: [ipwave] which BSM? William Whyte
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… Alexandre Petrescu
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] link-local text (Re: Intdi… Alexandre Petrescu
- Re: [ipwave] ND-over-OCB hidden terminals: truck … Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- [ipwave] Hidden terminal problem Charlie Perkins
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… 神明達哉
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… Alexandre Petrescu
- Re: [ipwave] Hidden terminal problem Alexandre Petrescu
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… 神明達哉
- Re: [ipwave] [Int-dir] link-local text (Re: Intdi… 神明達哉
- Re: [ipwave] 118 神明達哉
- Re: [ipwave] 118 Brian E Carpenter
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] use-cases in Problem Statement Alexandre Petrescu
- Re: [ipwave] use-cases in Problem Statement NABIL BENAMAR
- Re: [ipwave] 118 Joel M. Halpern
- Re: [ipwave] use-cases in Problem Statement Jérôme Härri
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] 118 Eric Gray
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… 神明達哉
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] 118 Stephen Farrell
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… Alexandre Petrescu
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… 神明達哉
- Re: [ipwave] 118 Joel M. Halpern
- Re: [ipwave] [Int-dir] 118 神明達哉
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Brian E Carpenter
- Re: [ipwave] Hidden terminal problem Abdussalam Baryun
- Re: [ipwave] use-cases in Problem Statement Abdussalam Baryun
- Re: [ipwave] Expertise on ND problems on OCB Abdussalam Baryun
- Re: [ipwave] Hidden terminal problem Alexandre Petrescu
- Re: [ipwave] [Int-dir] side note RFC 4291 2nd par… Alexandre Petrescu
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] 118 Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Alexandre Petrescu
- Re: [ipwave] [Int-dir] 118 神明達哉
- Re: [ipwave] [Int-dir] 118 Alexandre Petrescu
- Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb… Brian E Carpenter
- Re: [ipwave] [Int-dir] 118 神明達哉
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] 118 神明達哉
- Re: [ipwave] [Int-dir] 118 Suresh Krishnan
- Re: [ipwave] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] 118 Alexandre Petrescu
- Re: [ipwave] Hidden terminal problem Abdussalam Baryun
- Re: [ipwave] Hidden terminal problem Alexandre Petrescu
- Re: [ipwave] [Int-dir] 118 神明達哉
- Re: [ipwave] [Int-dir] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] 118 Russ Housley
- Re: [ipwave] [Int-dir] 118 Alexandre Petrescu
- Re: [ipwave] [Int-dir] 118 Russ Housley
- Re: [ipwave] [Int-dir] 118 Alexandre Petrescu
- Re: [ipwave] Expertise on ND problems on OCB Carsten Bormann
- Re: [ipwave] [Int-dir] Expertise on ND problems o… Pascal Thubert (pthubert)
- Re: [ipwave] Expertise on ND problems on OCB Sri Gundavelli (sgundave)
- Re: [ipwave] Expertise on ND problems on OCB Charlie Perkins
- Re: [ipwave] Expertise on ND problems on OCB Sri Gundavelli (sgundave)
- Re: [ipwave] AH with NIST quantum resistant new a… Alexandre Petrescu