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

On Thu, Apr 11, 2019 at 5:16 PM William Whyte <wwhyte@onboardsecurity.com>
wrote:

> 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.
>

Yes a single OCB interface per frequency band, we cannot have many
interfaces per node for same frequency band in CSMA.

AB

>
> 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> 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>
>> <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> <n.benamar@est.umi.ac.ma>;
>> Pascal Thubert (pthubert)
>>  <pthubert@cisco..com> <pthubert@cisco.com> Cc: ietf@ietf.org;
>> its@ietf.org; int-dir@ietf.org; draft-ietf-ipwave-ipv6-over-
>> 80211ocb.all@ietf.org; Alexandre Petrescu <alexandre.petrescu@gmail.com>
>> <alexandre.petrescu@gmail.com>; Ole Troan <otroan@employees.org>
>> <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> <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> <otroan@employees.org>>
>>
>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu <
>> alexandre.petrescu@gmail.com
>>
>> <mailto:alexandre.petrescu@gmail.com> <alexandre.petrescu@gmail.com>>
>>
>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com
>>
>> <mailto:pthubert@cisco.com> <pthubert@cisco.com>>; ietf@ietf.org
>> <mailto:ietf@ietf.org> <ietf@ietf.org>;
>>
>> its@ietf.org <mailto:its@ietf.org> <its@ietf.org>; int-dir@ietf.org <
>> mailto:int <int>-
>>
>> dir@ietf.org>; draft-ietf-ipwave-ipv6-over-
>>
>> 80211ocb.all@ietf.org <mailto:80211ocb.all@ietf.org>
>> <80211ocb.all@ietf.org>; Brian E
>>
>> Carpenter <brian.e.carpenter@gmail.com
>> <mailto:brian.e.carpenter@gmail.com> <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> <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> <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> <Int-dir@ietf.org>
>> https://www.ietf.org/mailman/listinfo/int-dir
>>
>>
>>
>> _______________________________________________ Int-dir mailing list
>> Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir
>>
>> _______________________________________________
>> its mailing list
>> 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.
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>