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

[Alexandre Petrescu <[e-mail]>]

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 <[e-mail]>
>>> On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 09:54 To:
>>> NABIL BENAMAR <[e-mail]>; Pascal Thubert (pthubert)
>>>  <[e-mail]> Cc: [e-mail]; [e-mail]; 
>>> [e-mail]; draft-ietf-ipwave-ipv6-over- 
>>> [e-mail]; Alexandre Petrescu 
>>> <[e-mail]>; Ole Troan <[e-mail]> 
>>> 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)
>>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>>> <mailto:[e-mail]>>
>>>>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu 
>>>>> <[e-mail]
>>> <mailto:[e-mail]>>
>>>>> Cc: Pascal Thubert (pthubert) <[e-mail]
>>> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>;
>>>>> [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:int-
>>> [e-mail]>; draft-ietf-ipwave-ipv6-over-
>>>>> [e-mail] <mailto:[e-mail]>; Brian E
>>> Carpenter <[e-mail] 
>>> <mailto:[e-mail]>>
>>>>> 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
>>>>> <[e-mail]
>>> <mailto:[e-mail]>> 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 [e-mail] <mailto:[e-mail]> 
>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>>
>>>>>> _______________________________________________ Int-dir mailing 
>>>>>> list [e-mail] <mailto:[e-mail]> 
>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>
>>>
>>> _______________________________________________ Int-dir mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/int-dir