Re: Interested in wireless ?

[Alexandre Petrescu <[e-mail]>]

Le 02/06/2020 à 14:04, Pascal Thubert (pthubert) a écrit :
> Hello Alex
> 
> There's a difference between the MAC address used (0x333300-blah)
> that is multicast and the effective processing by the network.

I agree there is that difference.

The question is then whether we should call MAC-layer broadcast the
effective processing by the network?

For my side, I think the effective processing by the network is the fact
that messages are received by everyone and local filters are used.  It
is 'broadcast' in nature, but it is not the IEEE broadcast.

> For all I know, the IEEE multicast protocols are pretty much never
> deployed, and only the first bit that says broadcast is of actual
> interest. IOW the IETF has thrown the problem of handling multicast
> for a large number of groups over the fence to IEEE. The end result
> is a broadcast to all nodes. True on both IEEE std 802.3 and 802.11.

I tend to agree, although I do not know what is the IEEE multicast
protocol at MAC layer.  I think such thing might not exist(?)  I might
be wrong.

But the word 'broadcast' itself has a very well understood meaning for
IP and for MAC, just like multicast has.

WE cant simply say that multicast is transformed in broadcast at
implementation time, because it is not true at least in one sense:
broadcast means 0xffffffff and that 0x is not used for implementations
of ND.

These misunderstandings of the use of the word broadcast are much more
than just us talking ND multicast and 802.11 broadcast implementations.

Even outside IETF, for example, many people in vehicular networks say
that 802.11p ETSI-ITS-G5 is broadcast :-)  It might be broadcast like a
TV session is broadcast, but the details of its MAC layer is as much
0x33 multicast as is 0xff multicast as is 0xabc unicast.

> If you are aware of networks that are operated differently I'm all
> ears.

Well, there is this linux kernel booting up and sending a MLD REPORT to
a multicast group about joining a multicast group for ND.

But it might be a chicken and egg problem: can one send a message to a
multicast group before joining it?  It is a philosophical problem.

Alex

> 
> Keep safe,
> 
> pascal
> 
>> -----Original Message----- From: Alexandre Petrescu
>> <[e-mail]> Sent: mardi 2 juin 2020 13:54 To:
>> Pascal Thubert (pthubert) <[e-mail]>; [e-mail] 
>> Subject: Re: Interested in wireless ?
>> 
>> Hello Pascal,
>> 
>> Le 02/06/2020 à 09:55, Pascal Thubert (pthubert) a écrit :
>>> Hello Alex
>>> 
>>>> -----Original Message----- From: ipv6 <[e-mail]>
>>>> On Behalf Of Alexandre Petrescu Sent: lundi 1 juin 2020 21:19 
>>>> To: [e-mail] Subject: Re: Interested in wireless ?
>>>> 
>>>> draft says:
>>>>> To protect their bandwidth, some networks throttle ND-related
>>>>> broadcasts, which reduces the capability for the ND protocol
>>>>> to operate as expected.
>>>> 
>>>> I suspect you mean ND-related multicasts, and not ND-related
>>>> broadcasts.
>>> 
>>> I meant ND-related MAC-layer broadcasts.
>> 
>> I think there are no MAC-layer broadcasts used by ND.
>> 
>> A MAC-layer broadcast is one that sends to ff:ff:ff:ff:ff.  That
>> does not exist for ND.
>> 
>> Or maybe one means a PHY-layer broadcast?
>> 
>> Broadcast: casting broadly a message, like a fisherman casting a
>> net, like in a TV broadcast.
>> 
>> Alex
>> 
>> L3 multicast turned in L2 broadcast.
>>> But I see that the paragraph needs clarification, will do it for
>>> the next
>> publication.
>>> 
>>> 
>>>> 
>>>> Also, I guess that need to protect (maintain availability)
>>>> bandwidth is different when more and more bandwidth is offered
>>>> by a PHY/MAC in a
>> terahertz range.
>>>> Maybe these networks will stop throttling(?)
>>> 
>>> I do not have a crystal ball for that. Look at Ethernet, now in
>>> the 100s of Gigs
>> in the DC.
>>> With the overlays and distributed cloud, the desire to eliminate
>>> broadcasts is
>> more intense than ever.
>>> 
>>> Keep safe,
>>> 
>>> Pascal
>>> 
>>>> Alex
>>>> 
>>>> Le 01/06/2020 à 21:12, Alexandre Petrescu a écrit :
>>>>> draft says:
>>>>>> The routers send RAs with a SLLAO at a regular period.
>>>>>> The period can be indicated in the RA-Interval Option
>>>>>> [RFC6275].  If available, the message can be transported in
>>>>>> a compressed form in a beacon, e.g., in OCB Basic Safety
>>>>>> Messages (BSM) that are nominally sent every 100ms.
>>>>> 
>>>>> I suggest to give CAM as an example as well, not just BSM.
>>>>> 
>>>>> It might be that on some continent CAM is more important than
>>>>> BSM.
>>>>> 
>>>>> It might be, that in an ideal world where all use Internet,
>>>>> there is just one CAMBSM message, and maybe we get to that if
>>>>> we put it on IP.
>>>>> 
>>>>> But until then, citing just BSM is not good enough.
>>>>> 
>>>>> Alex
>>>>> 
>>>>> 
>>>>> Le 30/05/2020 à 13:46, Pascal Thubert (pthubert) a écrit :
>>>>>> Dear all
>>>>>> 
>>>>>> Since there’s so much energy on the list these days, could
>>>>>> we consider the adoption of 
>>>>>> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-0
>>>>>>
>>>>>> 
5
>>>>>> ?
>>>>>> 
>>>>>> I got only positive feedback, there’s no politics, there no
>>>>>> label, it’s all about IPv6 models for wireless. This may
>>>>>> appear useful in a world where the vast majority of devices
>>>>>> are connected that way.
>>>>>> 
>>>>>> Keep safe,
>>>>>> 
>>>>>> Pascal
>>>>>> 
>>>>>> -------------------------------------------------------------------
>>>>>>
>>>>>> 
- IETF IPv6 working group mailing list [e-mail] Administrative
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>>>>>> -------------------------------------------------------------------
>>>>>>
>>>>>> 
-
>>>>>> 
>>>>> 
>>>>> --------------------------------------------------------------------
>>>>>
>>>>> 
IETF IPv6 working group mailing list [e-mail] Administrative
>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>>>>> --------------------------------------------------------------------
>>>>
>>>>
>>>>> 
--------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list [e-mail] 
>>>> Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>>> --------------------------------------------------------------------