Re: [Int-dir] [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 -subnet structure, multicast

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 11 April 2019 17:10 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B951205D9; Thu, 11 Apr 2019 10:10:02 -0700 (PDT)
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 70qsSSUD58SE; Thu, 11 Apr 2019 10:09:58 -0700 (PDT)
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 B68DD1203B7; Thu, 11 Apr 2019 10:09:57 -0700 (PDT)
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 x3BH9oHj010582; Thu, 11 Apr 2019 19:09:50 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E2F1E204D30; Thu, 11 Apr 2019 19:09:50 +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 C46E1200FB2; Thu, 11 Apr 2019 19:09:50 +0200 (CEST)
Received: from [10.8.68.19] ([10.8.68.19]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3BH9nfc026200; Thu, 11 Apr 2019 19:09:49 +0200
To: William Whyte <wwhyte@onboardsecurity.com>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>, Ole Troan <otroan@employees.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <386b9f4c-f9b5-900c-817a-95df68226ed9@gmail.com> <cc9564f5-b049-fa99-31a4-98a9c9c1261a@gmail.com> <856F277E-8F26-48BC-9C57-70DC61AA4E06@employees.org> <c91328aa-72e4-c0be-ec86-5bfd57f79009@gmail.com> <1BF2A47E-3672-462B-A4EC-77C59D9F0CEA@employees.org> <2ba71d54-8f2f-1681-3b2a-1eda04a0abf9@gmail.com> <B618E1B8-1E01-4966-97B2-AAF5FC6FE38A@employees.org> <bf83d3c2-a161-310f-98f4-158a097314a6@gmail.com> <D1A09E57-11E2-4FBC-8263-D8349FBFB454@employees.org> <MN2PR11MB3565A36F02B010B12E709ABED82E0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAD8vqFeKtxZE76tgk38g8RivutAFbus9=8o2+qA8JHzSdW8wRw@mail.gmail.com> <76b9885d-11f0-b975-3e0e-a5f145af1aae@gmail.com> <MN2PR11MB35656B99E3F3CE76A379CD99D82F0@MN2PR11MB3565.namprd11.prod.outlook.com> <7f75d630-1aad-6f3c-2469-6dc875be7a70@gmail.com> <f8fce18a-98ea-18e2-b27d-0b01b5f492cd@gmail.com> <CAND9ES1vXnXwf8ERDyHxAVUmWmGgLAenCRdY-=ocfN3LHnN+9A@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <ae247c60-53c3-d73c-34a6-c3a9dd61d59d@gmail.com>
Date: Thu, 11 Apr 2019 19:09:49 +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: <CAND9ES1vXnXwf8ERDyHxAVUmWmGgLAenCRdY-=ocfN3LHnN+9A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/3ibXkEoQkQocMepvSq-NYlJhE_c>
Subject: Re: [Int-dir] [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 -subnet structure, multicast
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 17:10:02 -0000

William,

I agree with your comments.

The assumptions about physical topology, and cars overtake each other
and their bumper-to-bumper situation changes; if cars can overtake
each other the cloud will tell them their new situation, so change
the channels.  And, in a platoon (V2V) cars should not overtake each other.

With respect to whether or not the specification should work when there
is only one OCB on top of the car: it should.  Only one OCB interface on
top of a car, and IPv6 Road-Side Unit connected on 4G/IPv6 to the
Internet: it worked for me with two cars and one RSU outdoors, in a real
road South East of France in year 2015.  It accesses the Internet with
Mobile IPv6 and IPv6-over-OCB, and some NATv6 (because 4G only gives
RSU a /64, and we need more).  For more cars to V2I: one should try this 
V2I scenario before claiming it does not work.

Moreover, V2I is more than just a car accessing the Internet through an
RSU.

It is also about a car talking directly to a traffic lights controller,
without accessing the Internet.  I have a trial ongoing about this (you
can see the preliminaries of it if you try to browse a real traffic
lights controller but situated - for now - in-lab at 193.48.19.10).  The 
practical issues we have at this time is the support of IPv4 (RSU only 
supports IPv4 and that will not change in the next few years) and 
certificates (you will understand the certificate problem if you try to 
browse it).  The practical issues are not about transitivity A-B-C or 
MANET/6lo; these solutions (transitivity A-B-C MANET/6lo) will not help 
such IP-over-OCB V2I deployment in any way.  Maybe you know about other
IP-over-OCB V2I deployments that have other problems whose solutions
need MANET/6lo and transitivity A-B-C.

There is also V2X: mainly Vehicle-to-Vulnerable-Road-User.  I tested it
with CAMs on real road.  The issues there are about low visibility of
the top antenna to other persons (it misses the potential poussette
pushed by lady on passage pietons - it's too low), and the lack of OCB
drivers on Android.  The quick solution to that is the car brains to
send the CAM on IP (not on GeoNetworking) but on in-car Ethernet and
then further on 4G to the cloud, and the person's smartphone to search
for it on the cloud.  Again here noone that I worked with suggested the
MANET/6lo transitivity A-B-C solutions.  Rather, they suggest the use of
smartglasses and smartwatch because it is the future.  The smartglasses
are WiFi, so we could use IP on them (even though not IPv6).  The
smartwatch has Bluetooth LE.  But nobody suggested to use IP on
Bluetooth.  Just dongle the watch to smartphone and use the IP of the 
smartphone.  IP on bluetooth does not solve any problem that we were 
facing there.

BAsed on my own experience on the above, this is about re-assuring:

About the reassuring question:  I can not reassure that IP will still
work on a PHY MAC of a single OCB interface on top of car that is not
used how it is designed to be used.

I can reassure you that IP works fine on single OCB interface on top of
car whose MAC and PHY are set correctly, even when only one antenna on
top of car; but best is to put 2 antennas in MIMO mode on top of the
car, to have more reassurance of good PHY setup of that single
interface.  (this MIMO recommendation again has nothing to do with
MANET/6lo nor transitivity A-B-C nor DAD nor ND).

Alex

Le 11/04/2019 à 17:15, William Whyte a écrit :
> Hi Alex -- there *can* be multiple OCB interfaces in one car, but
> should the standard be written assuming that there are multiple OCB
> interfaces? I would have thought that the goal would be to write a
> standard that works even if there's a single OCB interface.
> 
> If we're relying on multiple OCB interfaces to make this work, how
> many of those interfaces per car are we relying on? We can't
> presumably be assuming a distinct interface for each remote car that
> the local car is communicating with. If we aren't assuming a distinct
> interface for each remote car, then doesn't the problem that Pascal
> identifies come up?
> 
> (You also mention that the antenna at the front of car B communicates
>  with the one at back of car A -- but what if A overtakes B? And to
> be clear, I'm not asking for a direct answer to that question, I'm
> saying that if there are assumptions about the physical topology that
> we're relying on, we need to make those assumptions very clear and
> make them clear up front)
> 
> I'd be very concerned if we were writing a standard that didn't work
> if there was only one OCB interface in the car. Can you reassure me
> on that?
> 
> Cheers,
> 
> William
> 
> 
> 
> 
> On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> wrote:
> 
> Pascal,
> 
> Do you agree there can be multiple IP OCB interfaces in one car?
> 
> Alex
> 
> Le 11/04/2019 à 11:23, Alexandre Petrescu a écrit :
>> Pascal,
>> 
>> Please allow me to change the subject of this, to reflect the 
>> content. It helps tracking the discussion.
>> 
>> Le 11/04/2019 à 04:36, Pascal Thubert (pthubert) a écrit :
>>> Hello Brian
>>> 
>>> I meant broadcast at layer 2 not layer 3. L3 uses multicast but 
>>> it requires a service at the lower layer to implement it. This
>>> is rarely if ever a real L2 multicast service.
>> 
>> I can agree.
>> 
>>> IOW the IETF has thrown the problem over the fence to the IEEE
>>> but it is not really solved to this day.
>> 
>> I think indeed there is redirection of responsability to IEEE.
>> Maybe IEEE does not like to do it, because of some reasons.
>> 
>> With respect to link-layer multicast: there is indeed no IEEE 
>> messaging for creation or removal of link-layer multicast groups
>> (like in IP there is MLDv2).  But there is concept of link-layer
>> multicast groups at IEEE. This is used extensively by mapping IP
>> groups into link-layer groups, and it helps IP.
>> 
>> Should IEEE develop a mechanism using messages (not just local 
>> filters) for creating these link-layer groups?
>> 
>>> In practice, the service that is performed on IEEE std 802.3 is
>>> a broadcast over a broadcast domain, and the subnet has to be 
>>> contained within that domain.
>> 
>> Well yes and no.
>> 
>> Yes it is a broadcast  on 802.3 if we talk IPv4, but it is still 
>> link-layer multicast on 802.3 if we talk IPv6: the link-layer 
>> addresses ofIPv6 on Ethernet are link-layer multicast addresses.
>> 
>>> The broadcast operation is emulated on IEEE std 802.11 by the
>>> BSS operation whereby the AP reflects the message to be
>>> broadcasted, so the broadcast domain is that of the AP as opposed
>>> to that of the source STA.
>> 
>> I agree.
>> 
>>> By the proposed definition, if car A sees car B they are in the
>>> same subnet. If car B sees car C they are in the same subnet. 
>>> Transitively Car A is in the same subnet as car C.
>> 
>> PAscal, again, this depends on how you set up the OCB interfaces on
>> cars A, B and C.
>> 
>> There are two options: - use a single OCB interface with antenna
>> sitting on top of each automobile.  Make them all in the same
>> channel frequency (e.g. CCH - Control Channel).  That indeed has
>> that A-B-C transitivity aspect. Worse, it has scalability issues:
>> one cant grow a convoy beyond a few tens of meters and be sure the
>> frontmost talks directly to the rearmost.  One never knows whether
>> somebody in the middle repeats, or not.  Or one needs to  rely on
>> MANET protocols that may forward on a single interface.  It has
>> some PHY issues as well, that I can describe.  The powerpoint is
>> readily filled with my last PHY experiments of propagation. - use
>> multiple OCB antennas situated at some strategic places in a car. 
>> This is in the same way as when placing the other ultra sound, 
>> radar and lidar sensors in the automobile.
>> 
>> An OCB interface in the front bumper of one car forms a subnet
>> with another OCB interface in the rear bumper of another car, on a 
>> particular channel (SCHx - service channel number x).  The front 
>> and rear subnets of a car are in distinct channels.  There is no
>> A-B-C transitivity.  There is IP forwarding between front and rear 
>> interfaces of a car.
>> 
>> This can be described.  But I dont think it should be described in 
>> the IP-over-OCB document.  It is a PHY MAC setting for OCB.
>> 
>>> But car C may not be in the radio broadcast domain of car A, and 
>>> there is no BSS by definition of OCB to emulate a broadcast
>>> domain between them via an AP. End result is that a DAD or a
>>> lookup by car A will not reach car C.
>> 
>> That may be true, but it is true mostly in a setting where each car
>> uses a single OCB interface whose antenna is placed on the roof of
>> the car (placed at same place as the the GPS, LTE, FM or DVB-T
>> antennas are placed).
>> 
>> In settings where each car has multiple OCB interfaces and
>> multiple antennas placed at strategic places (strategic: places
>> that are relevant to PHY propagation conditions), rather than
>> simply on the roof, the issue you describe in the above paragraph.
>> 
>> Now, if you read up to here, I would like to ask you (without 
>> claiming to be all-knowing), whether you think a car could have
>> several OCB interfaces?
>> 
>>> By traditional MANET and 6lo definition, the radio broadcast 
>>> domain of a node is his link.
>> 
>> It is good, and I agree with it.
>> 
>> For my part, I do not use the traditional MANET and 6lo
>> definitions because I believe they are not sufficient for vehicular
>> environments.
>> 
>>> In you lab you can arrange that the broadcast domains of 3 cars 
>>> fully overlap.
>> 
>> I agree, people do that.  It is in small lab, with size in the 
>> range of a few meters; there is much reflexion from the walls.  It
>> is not outdoors.
>> 
>>> In that case, the link appears to match the common sense of a 
>>> link in wires and the classical IPv6 operations will work pretty
>>> much the same as in a BSS over that Link. It is for example easy
>>> to place a subnet that matches that Link. It is also easy to
>>> confuse a Link with a Subnet, which is what the definition does.
>>> As soon as the broadcast domains start diverging, things get
>>> hairy, see all the work by Erik about split subnet etc...
>> 
>> I fully agree with this paragraph.
>> 
>> I think if one puts several interfaces and antennas in a car, and 
>> carefully design the use of the propagation models (e.g. avoid 
>> 'omni', consider 'directional', etc) then one can avoid many
>> problems forbidding IP from running on wireless.
>> 
>>> The IETF has studied this situations for 10+ years at MANET, 
>>> 6TiSCH and 6lo. We have an architecture that cover single link 
>>> and multilink subnets.
>> 
>> Yes, there is.
>> 
>>> In the former case, the link is defined by one node that owns
>>> the prefix. In the latter case, routing is required inside the
>>> subnet and we created RPL to cover the situation.
>> 
>> YEs, but these are departures from what might be called traditional
>> IP forwarding.  That forwarding happens between two distinct
>> interfaces.
>> 
>> In practice it means little software for MANET-6lo-multilink is 
>> publicly available, and the engineer skill about them is hard to
>> find. This translates to equipment being very expensive.
>> 
>> I want to tell you that communication equipment for cars is already
>> very high compared to an off-the-shelf WiFi router.  That high
>> price tag is due also to specification of things that are too
>> intelligent and that require high skills from few people.  This is
>> the case of V2X stacks doing ETSI CAM with GeoNetworking and
>> similar.  You end up with a 3000Eur IP-OBU when its underlying
>> hardware with linux and traditional IP forwarding costs around
>> 700Eur.
>> 
>> To that 3000Eur one may need to add costs of complexity of MANET 
>> protocols and 6lo multilink subnet moels you arrive at a cost per 
>> communication box that is the equivalent of a small car.
>> 
>> This high cost is less and less acceptable.
>> 
>> Compare that to the 1Eur LTE-WiFi dongle retrofitted recently in 
>> some cars.
>> 
>>> We created RFC 8505 for an host to connect to the network in 
>>> either situation, without the requirement that the L2 broadcast 
>>> domain of the host (its Link) overlaps with that of other nodes 
>>> in the subnet (because they don't). We have made RFC 8505 
>>> abstract to the routing protocol if any, IOW without the 
>>> requirement that the host knows there is a MLSN, understands RPL 
>>> or whatever other routing is used
>> 
>> MLSN?
>> 
>>> to put together the MLSN. To get there we had to abandon the 
>>> dependency that a L2 broadcast from the host reaches all nodes
>>> in the subnet, IOW that the subnet is contained within the Link
>>> of all of
>> 
>> IOW?
>> 
>>> its members, IOW that the Links of all the nodes in the subnet 
>>> fully overlap. This meant we had to abandon the idea of using 
>>> multicast in ND for DAD and AR.
>>> 
>>> Maybe someone can explain that better than I did. I so please be 
>>> my guest. I really tried but I'm not convinced I did not waste
>>> my time with the authors of the draft.
>> 
>> You did not waste your time, no more than I did.
>> 
>> Alex
>> 
>>> 
>>> All the best,
>>> 
>>> Pascal
>>> 
>>>> -----Original Message----- From: Int-dir 
>>>> <int-dir-bounces@ietf.org> <mailto:int-dir-bounces@ietf.org> On
>>>> Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 09:54
>>>> To: NABIL BENAMAR <n.benamar@est.umi.ac.ma> 
>>>> <mailto:n.benamar@est.umi.ac.ma>; Pascal Thubert (pthubert) 
>>>> <pthubert@cisco.com> <mailto:pthubert@cisco.com> Cc: 
>>>> ietf@ietf.org <mailto:ietf@ietf.org>; its@ietf.org 
>>>> <mailto:its@ietf.org>; int-dir@ietf.org 
>>>> <mailto:int-dir@ietf.org>; draft-ietf-ipwave-ipv6-over- 
>>>> 80211ocb.all@ietf.org <mailto:80211ocb.all@ietf.org>;
>>>> Alexandre Petrescu <alexandre.petrescu@gmail.com> 
>>>> <mailto:alexandre.petrescu@gmail.com>; Ole Troan 
>>>> <otroan@employees.org> <mailto:otroan@employees.org> Subject: 
>>>> Re: [Int-dir] Intdir early review of 
>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' - 
>>>> fe80::/10 vs fe80::/64
>>>> 
>>>> Hi Nabil,
>>>> 
>>>> On 11-Apr-19 03:40, NABIL BENAMAR wrote:
>>>>> Do we still talk about broadcast in IPv6 ?
>>>> 
>>>> No, we talk about multicast. Pascal was using shorthand. But
>>>> if multicast fails with high probability, several aspects of
>>>> IPv6 will fail too, unless the LAN provides an NBMA
>>>> (non-broadcast multiple access) emulation of multicast, or
>>>> suitable alternatives to SLAAC, ND, NUD, and RA.
>>>> 
>>>> An earlier draft of this spec mentioned this problem:
>>>> 
>>>>>>> The operation of the Neighbor Discovery protocol (ND)
>>>>>>> over 802.11-OCB links is different than over 802.11
>>>>>>> links.  In OCB, the link layer does not ensure that all
>>>>>>> associated members receive all messages, because there is
>>>>>>> no association operation.  Neighbor Discovery (ND) is
>>>>>>> used over 802.11-OCB.
>>>> 
>>>> but it was inconsistent and was removed. If Ole is correct
>>>> below about real-life conditions, the *problem* was not removed
>>>> and the draft is not going to work in the real world.
>>>> 
>>>> Brian
>>>> 
>>>>> 
>>>>> On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
>>>> <pthubert@cisco.com <mailto:pthubert@cisco.com> 
>>>> <mailto:pthubert@cisco.com> <mailto:pthubert@cisco.com>>
>>>> wrote:
>>>>> 
>>>>> Hello Ole:
>>>>> 
>>>>> Better remove, it is wrong anyway.
>>>>> 
>>>>> Because it is transitive, the description extends the
>>>>> so-called subnet step
>>>> by step to a potentially large number of cars such that there
>>>> is no broadcast domain that covers them all. If there is no
>>>> broadcast domain and no multicast emulation like a BSS does,
>>>> how can we run ND? Yes, it works with 3 cars in a lab.
>>>>> 
>>>>> The description looks like it is confused with the MANET /
>>>>> 6LoWPAN
>>>> concept of link, whereby my link joins the collection of nodes
>>>> that my radio can reach.
>>>>> 
>>>>> All the best,
>>>>> 
>>>>> Pascal
>>>>> 
>>>>>> -----Original Message----- From: Ole Troan 
>>>>>> <otroan@employees.org <mailto:otroan@employees.org>
>>>> <mailto:otroan@employees.org> <mailto:otroan@employees.org>>
>>>>>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu 
>>>>>> <alexandre.petrescu@gmail.com 
>>>>>> <mailto:alexandre.petrescu@gmail.com>
>>>> <mailto:alexandre.petrescu@gmail.com> 
>>>> <mailto:alexandre.petrescu@gmail.com>>
>>>>>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com 
>>>>>> <mailto:pthubert@cisco.com>
>>>> <mailto:pthubert@cisco.com> <mailto:pthubert@cisco.com>>; 
>>>> ietf@ietf.org <mailto:ietf@ietf.org> <mailto:ietf@ietf.org> 
>>>> <mailto:ietf@ietf.org>;
>>>>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org> 
>>>>>> <mailto:its@ietf.org>; int-dir@ietf.org 
>>>>>> <mailto:int-dir@ietf.org> <mailto:int-
>>>> dir@ietf.org <mailto:dir@ietf.org>>;
>>>> draft-ietf-ipwave-ipv6-over-
>>>>>> 80211ocb.all@ietf.org <mailto:80211ocb.all@ietf.org> 
>>>>>> <mailto:80211ocb.all@ietf.org>
>>>>>> <mailto:80211ocb.all@ietf.org>; Brian E
>>>> Carpenter <brian.e.carpenter@gmail.com 
>>>> <mailto:brian.e.carpenter@gmail.com> 
>>>> <mailto:brian.e.carpenter@gmail.com> 
>>>> <mailto:brian.e.carpenter@gmail.com>>
>>>>>> Subject: Re: [Int-dir] Intdir early review of 
>>>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming
>>>>>> IPv6' - fe80::/10 vs fe80::/64
>>>>>> 
>>>>>>> You said: if OCB is still 48bit, and if there is
>>>>>>> bridging OCB-Ethernet, then
>>>> no
>>>>>> reason to be different than rfc2464.
>>>>>>> 
>>>>>>> I said: OCB is still 48bit, but there is no bridging 
>>>>>>> OCB-Ethernet.
>>>>>>> 
>>>>>>> The conclusion is: there is reason to be different from
>>>>>>> RFC 2464.
>>>>>> 
>>>>>> Why?
>>>>>> 
>>>>>>> Now, you give a different conclusion.
>>>>>>> 
>>>>>>> Excuse me, I would like to clarify this please?
>>>>>> 
>>>>>> Clarify what? That a link-layer that looks an awfully lot
>>>>>> like Ethernet should not follow
>>>> the
>>>>>> 64-bit boundary and the definition of the link-local
>>>>>> address mapping of rfc2464? Section 4.5.1 is already clear
>>>>>> on that.
>>>>>> 
>>>>>> I think the only thing we are asking you is to change the 
>>>>>> following
>>>> paragraph:
>>>>>> 
>>>>>> OLD: A subnet is formed by the external 802.11-OCB
>>>>>> interfaces of vehicles that are in close range (not by
>>>>>> their in-vehicle interfaces).  This subnet MUST use at
>>>>>> least the link-local prefix fe80::/10 and the interfaces
>>>>>> MUST be assigned IPv6 addresses of type link-local.
>>>>>> 
>>>>>> NEW: A subnet is formed by the external 802.11-OCB
>>>>>> interfaces of vehicles that are in close range (not by
>>>>>> their in-vehicle interfaces). A node MUST form a link-local
>>>>>> address on this link.
>>>>>> 
>>>>>> Not quite sure what value that paragraph adds in the first 
>>>>>> place. You
>>>> could
>>>>>> probable remove it.
>>>>>> 
>>>>>> Cheers, Ole
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Alex
>>>>>>> 
>>>>>>> Le 10/04/2019 à 12:28, Ole Troan a écrit :
>>>>>>>> Alexandre, Right, so it doesn’t sound like you have
>>>>>>>> any reason to be different
>>>> from
>>>>>> RFC2464.
>>>>>>>> Just reference or copy that text (section 5, rfc2464).
>>>>>>>> Ole
>>>>>>>>> On 10 Apr 2019, at 11:22, Alexandre Petrescu
>>>>>> <alexandre.petrescu@gmail.com 
>>>>>> <mailto:alexandre.petrescu@gmail.com>
>>>> <mailto:alexandre.petrescu@gmail.com> 
>>>> <mailto:alexandre.petrescu@gmail.com>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Le 10/04/2019 à 11:04, Ole Troan a écrit :
>>>>>>>>>>>>>> "At least" does not mean "the value should
>>>>>>>>>>>>>> be at least 10" in
>>>> that
>>>>>> phrase.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Do you think we should say otherwise?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> To me there is nothing in the actual text to
>>>>>>>>>>>>> tell me that "at
>>>> least"
>>>>>>>>>>>>> qualifies the "/10". I think you could
>>>>>>>>>>>>> rephrase as "This subnet's prefix MUST lie
>>>>>>>>>>>>> within the link-local prefix fe80::/10 ..."
>>>>>>>>>>>>> 
>>>>>>>>>>>>> However, see Jinmei's messages about
>>>>>>>>>>>>> conformance with RFC
>>>> 4291.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think there might be unexpected side
>>>>>>>>>>>>> effects from using an address like fe80:1::1.
>>>>>>>>>>>>> What if some code uses matching with
>>>>>>>>>>>>> fe80::/64 to test if an address is
>>>>>>>>>>>>> link-local? I agree that would be faulty
>>>>>>>>>>>>> code, but you would be the first to discover
>>>>>>>>>>>>> it.
>>>>>>>>>>>> Indeed. If you absoultely must cut and paste
>>>>>>>>>>>> text from 2464:
>>>>>>>>>>> 
>>>>>>>>>>> YEs, that is how we started.  We cut and paste
>>>>>>>>>>> from 2464.
>>>>>>>>>>> 
>>>>>>>>>>>> 5.  Link-Local Addresses The IPv6 link-local
>>>>>>>>>>>> address [AARCH] for an Ethernet interface is
>>>>>>>>>>>> formed by appending the Interface Identifier,
>>>>>>>>>>>> as defined above,
>>>> to
>>>>>>>>>>>> the prefix FE80::/64. 10 bits            54
>>>>>>>>>>>> bits 64 bits 
>>>>>>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>>>>>>>
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> 
|1111111010|         (zeros)       |    Interface
>>>>>>>>> Identifier    |
>>>>>>>>>>>> 
>>>>>>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>>>>>>>
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 
I presume there is support for bridging 802.11p and
>>>>>>>>>>>> other 802.3
>>>> links?
>>>>>>>>> 
>>>>>>>>> In the IP-OBUs that I know there is IP forwarding
>>>>>>>>> between 802.11-
>>>> OCB
>>>>>> (earlier 802.11p) and 802.3, not bridging.
>>>>>>>>> 
>>>>>>>>> In some IP-OBU (Internet Protocol On-Board Unit) some
>>>>>>>>> non-OCB
>>>>>> interfaces are indeed bridged.  E.g. the Ethernet interface
>>>>>> is bridged to
>>>> the
>>>>>> WiFi interface; that helps with DHCP, tcpdump and others to
>>>>>> see one a
>>>> single -
>>>>>> bridged - interface.
>>>>>>>>> 
>>>>>>>>> Bridging may be, but it is not a MUST.  There is no 
>>>>>>>>> necessarily any
>>>> bridging
>>>>>> between the 802.11-OCB interface and other interface,
>>>>>> neither bridging between the multiple 802.11-OCB interfaces
>>>>>> that might be present in
>>>> the
>>>>>> same computer.
>>>>>>>>> 
>>>>>>>>> Do you assume bridging of 802.11-OCB interface to
>>>>>>>>> Ethernet
>>>> interface is
>>>>>> always there?
>>>>>>>>> 
>>>>>>>>> Note: I also heard many comments suggesting that EAL
>>>>>>>>> is akin to
>>>>>> 'bridging'.  I do not know whether you refer to that 
>>>>>> perspective.  If yes,
>>>> we can
>>>>>> discuss it separately.
>>>>>>>>> 
>>>>>>>>> Alex
>>>>>>>>> 
>>>>>>>>> [...]
>>>>>>>>> 
>>>>>>>>>>>> And that the MAC address length of this link
>>>>>>>>>>>> type is also 48 bits?
>>>>>>>>>>> 
>>>>>>>>>>> YEs, the length of MAC address on 802.11 mode OCB
>>>>>>>>>>> is also 48.
>>>>>>>>>>> 
>>>>>>>>>>>> If the two assumptions above hold, then I see
>>>>>>>>>>>> zero justification
>>>> for
>>>>>> pushing the 64 bit boundary in this draft.
>>>>>>>>>>> 
>>>>>>>>>>> Let me try  to understand the first assumption.
>>>>>>>>>> Ole
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Int-dir mailing list Int-dir@ietf.org
>>>>>>>>> <mailto:Int-dir@ietf.org> <mailto:Int-dir@ietf.org>
>>>>>>>>> <mailto:Int-dir@ietf.org> 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>>> 
>>>>>>> _______________________________________________ Int-dir 
>>>>>>> mailing list Int-dir@ietf.org <mailto:Int-dir@ietf.org> 
>>>>>>> <mailto:Int-dir@ietf.org> <mailto:Int-dir@ietf.org> 
>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>> 
>>>> 
>>>> _______________________________________________ Int-dir
>>>> mailing list Int-dir@ietf.org <mailto:Int-dir@ietf.org> 
>>>> https://www.ietf.org/mailman/listinfo/int-dir
> _______________________________________________ its mailing list 
> its@ietf.org <mailto:its@ietf.org> 
> https://www.ietf.org/mailman/listinfo/its
> 
> 
> 
> --
> 
> ---
> 
> I may have sent this email out of office hours. I never expect a 
> response outside yours.