Subject: RE: Interested in wireless ?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Jun 2020 08:30:06 +0000

Neat!

Many thanks Brian.

Pascal

> -----Original Message-----
> From: Brian E Carpenter <[email-masked]>
> Sent: lundi 1 juin 2020 01:21
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: Interested in wireless ?
> 
> Pascal,
> 
> There is a category of standards track documents foreseen in RFC2026 called
> "applicability statements", described at
> https://tools.ietf.org/html/rfc2026#section-3.2
> 
> I think that is perhaps where your draft could fit. A little bit stronger than
> Informational and little bit different than Best *Current* Practice.
> 
> Regards
>    Brian
> 
> On 01-Jun-20 04:40, Pascal Thubert (pthubert) wrote:
> > Hello Brian
> >
> > We may have to split the doc but for the most part I agree it is an
> informational.
> >
> > For now I suggest to just change the intended status accordingly and aim at
> BCP or something.
> >
> > Let’s discuss in parallel the coexistence and if there’s a need for an std track
> somewhere. There’s at least the use of a 6LBR for address looking up in
> unicast.
> >
> > Take care,
> > Pascal
> >
> >> Le 30 mai 2020 à 22:47, Brian E Carpenter <[email-masked]>
> a écrit :
> >>
> >> Hi,
> >>
> >> I believe that this is an important topic that 6MAN should take up. The draft
> is a good basis.
> >>
> >> At the moment I find the draft a bit confusing in one way. It's aimed at
> standards track, but it mainly doesn't read like a standard. There's a lot of
> discussion but not much specification. If I was a coder, I wouldn't really know
> where to start. For example, the end of the Introduction says:
> >>
> >> "This document discusses the applicability of IPv6 ND over wireless
> >> links, as compared with routing-based alternatives such as prefix-per
> >> node and multi-link subnets (MLSN), and with Wireless ND (WiND), that
> >> is similar to the Wi-Fi association and reduces the need for
> >> Network-Layer multicast."
> >>
> >> If it's a standard, IMHO it shouldn't do that. It should specify what WiND is,
> with normative references as needed. Section 5 is the important part. It's fine
> to have a descriptive section about why WiND is needed, but that is almost
> better as an appendix. The main text should be essentially the instructions for a
> kernel programmer.
> >>
> >> Regards
> >>   Brian Carpenter
> >>
> >>> On 30-May-20 23:46, Pascal Thubert (pthubert) wrote:
> >>> 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-05
> >>> ?
> >>>
> >>> 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 [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 1 Jun 2020 15:16:55 +0000

> Pascal

Oh, good. I'd just like to say that Brian very eloquently expressed some of the thoughts I had when reading through the draft. This is an important topic. I'd like to see it presented in a way that drives deployment, if it really will help to solve the problem.

I suspect that to really get high rates of good, interoperable implementations in deployed Wi-Fi products, it might need to get picked up by Wi-Fi Alliance. An applicability statement that helps them understand the use case would be useful. I wonder, though, if that would be more v6ops than 6man? That is, it seems more about using (and implementing/deploying) existing protocols to improve operation of a network.
Barbara

> > There is a category of standards track documents foreseen in RFC2026
> > called "applicability statements", described at
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> > ml_rfc2026-23section-2D3.2&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> >
> 8sc8SY8Tq4vrfog&m=_i8eV1zjwa6e9U_4dG_Ehj8deR5jGNQadCAX4NyOVRg
> &s=S88z1M
> > klplQDukKNZjL75ub8LZnYm9ZJBYq_cafJfzY&e=
> >
> > I think that is perhaps where your draft could fit. A little bit
> > stronger than Informational and little bit different than Best *Current*
> Practice.
> >
> > Regards
> >    Brian
> >
> > somewhere. There’s at least the use of a 6LBR for address looking up
> > in unicast.
> > >
> > > Take care,
> > > Pascal
> > >
> > standards track, but it mainly doesn't read like a standard. There's a
> > lot of discussion but not much specification. If I was a coder, I
> > wouldn't really know where to start. For example, the end of the
> Introduction says:
> > >>
> > >> links, as compared with routing-based alternatives such as
> > >> prefix-per node and multi-link subnets (MLSN), and with Wireless ND
> > >> (WiND), that is similar to the Wi-Fi association and reduces the
> > >> need for Network-Layer multicast."
> > >>
> > with normative references as needed. Section 5 is the important part.
> > It's fine to have a descriptive section about why WiND is needed, but
> > that is almost better as an appendix. The main text should be
> > essentially the instructions for a kernel programmer.
> > >>
> > >> Regards
> > >>   Brian Carpenter
> > >>
> > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.or
> > >>> g_html_draft-2Dthubert-2D6man-2Dipv6-2Dover-2Dwireless-
> 2D05&d=DwIG
> > >>> aQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=_i8eV1zjwa6
> > >>>
> e9U_4dG_Ehj8deR5jGNQadCAX4NyOVRg&s=zhmY1Y4gPkDO08iqReP1D3y6I
> UQ2eCR
> > >>> cItaE6PV0kzU&e=
> > >>> ?
> > >>>
> > 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 [email-masked]
> > >>> Administrative
> > >>> Requests:
> > >>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_
> > >>> mailman_listinfo_ipv6&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8
> > >>>
> sc8SY8Tq4vrfog&m=_i8eV1zjwa6e9U_4dG_Ehj8deR5jGNQadCAX4NyOVRg&
> s=d4r
> > >>> J3C_jWlTRhy2Hr3SeRSeCEeyC8wNfKBtnuG7VCeU&e=
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=_i8eV1zjwa6e9U_4dG_Ehj8deR5jGNQadCAX4NyOVRg
> &s=d4rJ3C_jWlTRhy2Hr3SeRSeCEeyC8wNfKBtnuG7VCeU&e=

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Jun 2020 15:43:49 +0000

Hello Barbara:

RFC 8505 and the 2 following drafts (Backbone Router and Address Protection) are already referenced by the upcoming IEEE Std. 802.11 revision, the last 2 as draft-ietf-* for now. This is why we care to get the other RFC numbers soon (the 2 drafts are in RFCed queue). I expect that this means an automatic pick by WFA?

We'll note that the IEEE references are informational, like, it is recommended to do ND proxy and informationally, here's how you can do it.
But still it's a step. We need to convince the stacks. For all I know some routers are ready to engage.

Take care,

Pascal

> From: STARK, BARBARA H <[email-masked]>
> Sent: lundi 1 juin 2020 17:17
> To: Pascal Thubert (pthubert) <[email-masked]>; 'Brian E Carpenter'
> <[email-masked]>
> Cc: '6man WG' <[email-masked]>
> Subject: RE: Interested in wireless ?
> 
> > Neat!
> >
> > Many thanks Brian.
> >
> > Pascal
> 
> Oh, good. I'd just like to say that Brian very eloquently expressed some of the
> thoughts I had when reading through the draft. This is an important topic. I'd
> like to see it presented in a way that drives deployment, if it really will help to
> solve the problem.
> 
> I suspect that to really get high rates of good, interoperable implementations
> in deployed Wi-Fi products, it might need to get picked up by Wi-Fi Alliance. An
> applicability statement that helps them understand the use case would be
> useful. I wonder, though, if that would be more v6ops than 6man? That is, it
> seems more about using (and implementing/deploying) existing protocols to
> improve operation of a network.
> Barbara
> 
> > > standards track, but it mainly doesn't read like a standard. There's
> > > a lot of discussion but not much specification. If I was a coder, I
> > > >> "This document discusses the applicability of IPv6 ND over
> > > >> wireless links, as compared with routing-based alternatives such
> > > >> as prefix-per node and multi-link subnets (MLSN), and with
> > > >> Wireless ND (WiND), that is similar to the Wi-Fi association and
> > > >> reduces the need for Network-Layer multicast."
> > > >>
> > > It's fine to have a descriptive section about why WiND is needed,
> > > but that is almost better as an appendix. The main text should be
> > > IPv6 models for wireless. This may appear useful in a world where
> > > the vast majority of devices are connected that way.
> > > >>>
> > > >>> Keep safe,
> > > >>>
> > > >>> Pascal
> > > >>>
> > > >>> --

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 1 Jun 2020 16:12:37 +0000

Hi Pascal,

> Hello Barbara:
> 
> RFC 8505 and the 2 following drafts (Backbone Router and Address
> Protection) are already referenced by the upcoming IEEE Std. 802.11 revision,
> the last 2 as draft-ietf-* for now. This is why we care to get the other RFC
> numbers soon (the 2 drafts are in RFCed queue). I expect that this means an
> automatic pick by WFA?

No, it wouldn't mean that at all. WFA only creates certification and does plugfests on subsets of IEEE 802.11 standards that their members are actively pushing for and wanting to implement. There is lots of stuff in IEEE that WFA completely ignores. And sometimes, if IEEE is dithering and indecisive (i.e., experiencing politics, like during the 802.11n wars) WFA just goes ahead and creates a certification spec without waiting for IEEE to get its act together.
Barbara

> We'll note that the IEEE references are informational, like, it is recommended
> to do ND proxy and informationally, here's how you can do it.
> > Oh, good. I'd just like to say that Brian very eloquently expressed
> > some of the thoughts I had when reading through the draft. This is an
> > important topic. I'd like to see it presented in a way that drives
> > deployment, if it really will help to solve the problem.
> >
> > I suspect that to really get high rates of good, interoperable
> > implementations in deployed Wi-Fi products, it might need to get
> > picked up by Wi-Fi Alliance. An applicability statement that helps
> > them understand the use case would be useful. I wonder, though, if
> > that would be more v6ops than 6man? That is, it seems more about using
> > (and implementing/deploying) existing protocols to improve operation of a
> network.
> > Barbara
> >
> > > > There is a category of standards track documents foreseen in
> > > > RFC2026 called "applicability statements", described at
> > > > g_
> > > > ht
> > > > somewhere. There’s at least the use of a 6LBR for address looking
> > > > up in unicast.
> > > > >
> > > > > Take care,
> > > > > Pascal
> > > > >
> > > > standards track, but it mainly doesn't read like a standard.
> > > > There's a lot of discussion but not much specification. If I was a
> > > > coder, I wouldn't really know where to start. For example, the end
> > > > of the
> > > Introduction says:
> > > > >>
> > > > >> wireless links, as compared with routing-based alternatives
> > > > >> such as prefix-per node and multi-link subnets (MLSN), and with
> > > > >> Wireless ND (WiND), that is similar to the Wi-Fi association
> > > > >> and reduces the need for Network-Layer multicast."
> > > > >>
> > > > >>> --------------------------------------------------------------
> > > > >>> --
> > > > >>> --
> > > > >>> --------------------------------------------------------------
> > > > >>> --
> > > > >>> --
> > > > >>> --
> > > > >>>
> > > > >>
> > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Jun 2020 16:32:50 +0000

Hello again Barbara:

Does that mean that our influence is thorugh cross membership, or do we have a more direct channel from the IETF?

Keep safe,

Pascal

> Sent: lundi 1 juin 2020 18:13
> > Protection) are already referenced by the upcoming IEEE Std. 802.11
> > revision, the last 2 as draft-ietf-* for now. This is why we care to
> > get the other RFC numbers soon (the 2 drafts are in RFCed queue). I
> > expect that this means an automatic pick by WFA?
> 
> No, it wouldn't mean that at all. WFA only creates certification and does
> plugfests on subsets of IEEE 802.11 standards that their members are actively
> pushing for and wanting to implement. There is lots of stuff in IEEE that WFA
> completely ignores. And sometimes, if IEEE is dithering and indecisive (i.e.,
> experiencing politics, like during the 802.11n wars) WFA just goes ahead and
> creates a certification spec without waiting for IEEE to get its act together.
> Barbara
> 
> > We'll note that the IEEE references are informational, like, it is
> > recommended to do ND proxy and informationally, here's how you can do it.
> > > some of the thoughts I had when reading through the draft. This is
> > > an important topic. I'd like to see it presented in a way that
> > > drives deployment, if it really will help to solve the problem.
> > >
> > > that would be more v6ops than 6man? That is, it seems more about
> > > using (and implementing/deploying) existing protocols to improve
> > > operation of a
> > network.
> > > Barbara
> > >
> > > > > somewhere. There’s at least the use of a 6LBR for address
> > > > > looking up in unicast.
> > > > > >
> > > > > > Take care,
> > > > > > Pascal
> > > > > >
> > > > > There's a lot of discussion but not much specification. If I was
> > > > > a coder, I wouldn't really know where to start. For example, the
> > > > > end of the
> > > > Introduction says:
> > > > > >>
> > > > > >> such as prefix-per node and multi-link subnets (MLSN), and
> > > > > >> with Wireless ND (WiND), that is similar to the Wi-Fi
> > > > > >> association and reduces the need for Network-Layer multicast."
> > > > > >>
> > > > > It's fine to have a descriptive section about why WiND is
> > > > > needed, but that is almost better as an appendix. The main text
> > > > > should be essentially the instructions for a kernel programmer.
> > > > > >>
> > > > > >> Regards
> > > > > >>   Brian Carpenter
> > > > > >>
> > > > > >>> Since there’s so much energy on the list these days, could
> > > > > >>> we consider the adoption of
> > > > > IPv6 models for wireless. This may appear useful in a world
> > > > > where the vast majority of devices are connected that way.
> > > > > >>>
> > > > > >>> Keep safe,
> > > > > >>>
> > > > > >>> Pascal
> > > > > >>>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 1 Jun 2020 17:07:09 +0000

> Does that mean that our influence is thorugh cross membership, or do we
> have a more direct channel from the IETF?

I don't see WFA listed on https://www.ietf.org/about/liaisons/. I would have been surprised to see it there. 
So, I'd say, cross membership it is.
Barbara

> > No, it wouldn't mean that at all. WFA only creates certification and
> > does plugfests on subsets of IEEE 802.11 standards that their members
> > are actively pushing for and wanting to implement. There is lots of
> > stuff in IEEE that WFA completely ignores. And sometimes, if IEEE is
> > dithering and indecisive (i.e., experiencing politics, like during the
> > 802.11n wars) WFA just goes ahead and creates a certification spec without
> waiting for IEEE to get its act together.
> > Barbara
> >
> > > > Oh, good. I'd just like to say that Brian very eloquently
> > > > expressed some of the thoughts I had when reading through the
> > > > draft. This is an important topic. I'd like to see it presented in
> > > > a way that drives deployment, if it really will help to solve the problem.
> > > >
> > > > > > I think that is perhaps where your draft could fit. A little
> > > > > > bit stronger than Informational and little bit different than
> > > > > > Best
> > > > > > *Current*
> > > > > Practice.
> > > > > >
> > > > > > Regards
> > > > > >    Brian
> > > > > >
> > > > > > >> I believe that this is an important topic that 6MAN should take
> up.
> > > > > > >> The draft
> > > > > > is a good basis.
> > > > > > >>
> > > > > > There's a lot of discussion but not much specification. If I
> > > > > > was a coder, I wouldn't really know where to start. For
> > > > > > example, the end of the
> > > > > Introduction says:
> > > > > > >>
> > > > > > needed, but that is almost better as an appendix. The main
> > > > > > text should be essentially the instructions for a kernel programmer.
> > > > > > >>
> > > > > > >> Regards
> > > > > > >>   Brian Carpenter
> > > > > > >>
> 3A__tools.ietf.
> > > > > > >>> or
> > > > > > >>> ----------------------------------------------------------
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>> ----------------------------------------------------------
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>> --
> > > > > > >>>
> > > > > > >>
> > > > >

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Jun 2020 14:10:55 -0500

On Mon, Jun 1, 2020 at 10:17 AM STARK, BARBARA H <[email-masked]> wrote:

> > Neat!
> >
> > Many thanks Brian.
> >
> > Pascal
>
> Oh, good. I'd just like to say that Brian very eloquently expressed some
> of the thoughts I had when reading through the draft. This is an important
> topic. I'd like to see it presented in a way that drives deployment, if it
> really will help to solve the problem.
>
> implementations in deployed Wi-Fi products, it might need to get picked up
> by Wi-Fi Alliance. An applicability statement that helps them understand
> the use case would be useful. I wonder, though, if that would be more v6ops
> than 6man? That is, it seems more about using (and implementing/deploying)
> existing protocols to improve operation of a network.
>

I think this is a good point. Thanks for pointing it out Barbara.

Regards,
Behcet

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 1 Jun 2020 21:12:30 +0200

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 1 Jun 2020 21:18:33 +0200

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.

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(?)

Alex

Le 01/06/2020 à 21:12, Alexandre Petrescu a écrit :
>> 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
>>

---

From: Michael McBride <[email-masked]>
Date: Mon, 1 Jun 2020 21:57:57 +0000

Alex,

> I suspect you mean ND-related multicasts, and not ND-related broadcasts.

Yes and we get into that a bit in: https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/

mike

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(?)

Alex

Le 01/06/2020 à 21:12, Alexandre Petrescu a écrit :
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
>> ls.ietf.org%2Fhtml%2Fdraft-thubert-6man-ipv6-over-wireless-05&amp;dat
>> a=02%7C01%7Cmichael.mcbride%40futurewei.com%7C39445a5ce5ed4944791908d
>> 806609ea6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63726635934157
>> 7288&amp;sdata=nYfHyZvRsH3731BFjBSE2bUOxHfzJ6wqC0YRke0TahU%3D&amp;res
>> erved=0
>> ?
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cmichael.mcbr
>> ide%40futurewei.com%7C39445a5ce5ed4944791908d806609ea6%7C0fee8ff2a3b2
>> 40189c753a1d5591fedc%7C1%7C0%7C637266359341577288&amp;sdata=HMyn9qzB4
>> HJz81gOsUNByJKhr6JMi70F9XuYC7hGREA%3D&amp;reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cmichael.mcbrid
> e%40futurewei.com%7C39445a5ce5ed4944791908d806609ea6%7C0fee8ff2a3b2401
> 89c753a1d5591fedc%7C1%7C0%7C637266359341577288&amp;sdata=HMyn9qzB4HJz8
> 1gOsUNByJKhr6JMi70F9XuYC7hGREA%3D&amp;reserved=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C39445a5ce5ed4944791908d806609ea6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266359341577288&amp;sdata=HMyn9qzB4HJz81gOsUNByJKhr6JMi70F9XuYC7hGREA%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jun 2020 07:55:37 +0000

Hello Alex

> From: ipv6 <[email-masked]> On Behalf Of Alexandre Petrescu
> Sent: lundi 1 juin 2020 21:19
> To: [email-masked]

I meant ND-related MAC-layer broadcasts. 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jun 2020 07:58:36 +0000

It is referenced, Michael, at the very beginning. 

Many thanks for that very useful work, I hope people read it and understand we are dealing with a real issue.
Now is more than time to solve it, and that is what this spec is about, at least for ND.

Take care,

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Michael McBride
> Sent: lundi 1 juin 2020 23:58
> To: Alexandre Petrescu <[email-masked]>; [email-masked]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cmichael.mcbr
> ide%40futurewei.com%7C39445a5ce5ed4944791908d806609ea6%7C0fee8ff2
> a3b240189c753a1d5591fedc%7C1%7C0%7C637266359341577288&amp;sdat
> a=HMyn9qzB4HJz81gOsUNByJKhr6JMi70F9XuYC7hGREA%3D&amp;reserved=0

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 2 Jun 2020 13:53:45 +0200

Hello Pascal,

Le 02/06/2020 à 09:55, Pascal Thubert (pthubert) a écrit :
> 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jun 2020 12:04:20 +0000

Hello Alex

There's a difference between the MAC address used (0x333300-blah) that is multicast and the effective processing by the network. 
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.

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

Keep safe,

pascal

> From: Alexandre Petrescu <[email-masked]>
> Sent: mardi 2 juin 2020 13:54
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> A MAC-layer broadcast is one that sends to ff:ff:ff:ff:ff.  That does not exist for
> ND.
> 
> Broadcast: casting broadly a message, like a fisherman casting a net, like in a
> TV broadcast.
> 
> Alex
> 
> >> 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.
> >>>> 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 [email-masked] Administrative

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 2 Jun 2020 14:18:40 +0200

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

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
>> <[email-masked]> Sent: mardi 2 juin 2020 13:54 To:
>> Pascal Thubert (pthubert) <[email-masked]>; [email-masked] 
>>>> -----Original Message----- From: ipv6 <[email-masked]>
>>>> On Behalf Of Alexandre Petrescu Sent: lundi 1 juin 2020 21:19 
>>>> To: [email-masked] 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.
>>>> 
>> A MAC-layer broadcast is one that sends to ff:ff:ff:ff:ff.  That
>> does not exist for ND.
>> 
>> Broadcast: casting broadly a message, like a fisherman casting a
>> net, like in a TV broadcast.
>> 
>> Alex
>> 
>>> 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.
>>> 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
>>>> 
>>>>>> 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.
>>>>> 
>>>>> 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.
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
-
>>>> IETF IPv6 working group mailing list [email-masked] 
>>>> Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 2 Jun 2020 19:11:08 +0000

-----Original Message-----

> is 'broadcast' in nature, but it is not the IEEE broadcast.

Agreed. The important distinction being, MAC broadcasts (all 1s MAC DA) have to be filtered at layer 3, whereas MAC multicasts are filtered by the Ethernet NIC, for instance, at layer 2. I don’t think it's fair to say that MAC multicasts are truly broadcast.

>> is a broadcast to all nodes. True on both IEEE std 802.3 and 802.11.

I was wracking my brain trying to remember what the MAC layer multicast join protocol was called. Anyway, it does appear that it's "never actually used." However, what is used is the IGMP snooping hack, which prevents MAC layer multicasts from being flooded to all switch ports, by default. Layer 2 switches behave like layer 3 busybodies, listening to see which ports have IP multicast group membership. So in fact, that makes layer 2 switches avoid having to flood multicasts to all ports.

Bert

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jun 2020 20:04:15 +0000

Agreed on both points, Bert.

 I’ll add text on MLD snooping in the remediations. I have not seen it used in APs, but on paper that could be, are you aware of it being used?

As of the processing, yes, the multicast is a bit less processing but the Wireless nodes still have to keep their receiver active through the chain of broadcasts; this is where the battery is spent and wasted. A bit more or less processor time is usually negligible compared to the radio in terms of energy.

Many thanks!

Pascal

> Le 2 juin 2020 à 21:12, Manfredi (US), Albert E <[email-masked]> a écrit :
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Jun 2020 20:16:10 +0000

On the side I’m not used to seeing MLD snooping applied to SNMA, but maybe that‘s my IOS background. I’m more used to it applied to global scope multicast and ND being effectively flooded. If someone has more information on that that would enrich the new text.

Take care,

Pascal

> Le 2 juin 2020 à 22:06, Pascal Thubert (pthubert) <[email-masked]> a écrit :
>