Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear all. I support the adoption of this draft. It is helpful to deploy the 6lo in the real world. Best regards. Yong-Geun. 2021년 10월 18일 (월) 오후 11:20, Carles Gomez Montenegro 님이 작성: > Dear all, > > This is a gentle reminder that the call for adoption below is currently > open (note: the call will end this Thursday, EOB). > > Please state on the mailing list whether you are in favor of adopting the > document. > > Thanks, > > Shwetha and Carles > > > > Dear 6Lo WG, > > > > Considering the need and the urgency for the functionality defined in > > draft-thubert-6lo-multicast-registration-02, along with the interest from > > the Wi-SUN Alliance, this message starts a 10-day call for WG adoption > for > > draft-thubert-6lo-multicast-registration-02. > > > > (Link below: > > > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) > > > > The call will end on the 21st of October, EOB. > > > > Please state whether you are in favor of adopting this document. > > > > Also, any comments you may have, and/or expressions of interest to review > > the document, will be very much appreciated. > > > > Thanks, > > > > Shwetha and Carles > > > > > > ___ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo > > > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
I agree with Michael's comments, and also support the draft adoption.
AB
On Wed, Oct 20, 2021 at 12:36 AM Michael Richardson
wrote:
>
> I have read draft-thubert-6lo-multicast-registration.
>
> I think that it should be adopted.
>
> As I read it, I began to wonder if 6lo is the right place!
> 6man? roll?
>
> Clearly it will need a cross-WGLC into ROLL. That's not hard.
> I think that we'll need to talk about the new MOP a fair bit in ROLL
> anyway.
> I don't quite understand the new MOP yet, but I will read deeper during
> the WG deliberations on the document in the next months.
>
> My second thought/question was about non-LLN operations.
> RFC8505 can obviously be deployed into non-LLNs, but there is not yet
> industry (or 6man/v6ops) consensus that we should do this.
>
> I *think*, but I could be wrong, that if I deploy RFC8505 in switched
> ethernet space that I no longer need MLD to work correctly in order to
> make IPv6 work.
> {I have recently had to extend a busy R office LAN across to another
> building, using a fairly wide variety of L2 switches, with QinQ trunk from
> a
> different enterprise. I think it's broken MLD, and I think this is why
> IPv6
> is flaky... }
>
> If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not need as
> much L2-multicast to work.
> But, if someone had some other multicast dependant system, (such as mDNS
> over
> IPv6), then RFC8505 alone would not help. As I understand it, this
> document
> *would* help.
>
> I'm unclear if having done a multicast registration, that the 6LBR is now
> expected to turn multicasts into unicasts. In RPL, this is done in a
> Storing
> Mode, where I think the 6LBR knows where the registrations came from, and
> therefore can L2 unicast these multicast packets to the appropriate 6LRs
> that
> are next in the mesh.
> It seems like if I had an RFC8505+6lo-multicast capable L3 switch (6BBR)
> in an
> ethernet setting, that it would keep track of multicast registrations, and
> then L2 unicast traffic to the devices that needed it.
>
> This would be a major win for SOHO users with bridged WiFi.
> This is why I wonder if we are thinking too small by adopting at 6lo, and
> not
> 6man. Or maybe we need to do the LLN work here, and then write an
> operational/deployment considerations document for v6ops.
>
> The deployment hurdles for this might be significant, as I don't think
> there
> is a fax effect, but rather each node adds this code in an altrustic manner
> in order to reduce their airtime. For laptops and phones, there might be a
> battery savings, but I'm not sure if there is a win until most nodes have
> deployed it.
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Hello Michael
Please see below; I skipped where we reached consensus
> > The 6LN registers the multicast address, the 6LR sends a unicast DAO
> > straight to the Root, the Root tunnels the multicast packet to the
> 6LR,
> > the 6LR decapsulates and finds a multicast packet. The 6LR
> distributes
> > the multicast packet to all 6LNs that registered to the address.
> Maybe
> > the draft should use "subscribe" instead of "register" when it's
> > multicast or anycast?
>
> That might make it clearer.
OK I'll scan and fix in the next release.
> Can we do this with ethernet though? i.e. the tunnel is a unicast L2?
Well, the 6LR is one hop away, so that becomes the 6LBR passing the multicast
IP packet as a unicast L2 frame to all the 6LRs one by one. No SRH no IP in IP.
Then the 6LRs copy one by one to all subscribers. And
> Can we finally admit that ethernet is NBMA?
Yes, ethernet is often NBMA, think of eVPN, pseudowire ot Wi-Fi ESS. The make
believe emulation that is getting heavier by the day, but no one complains, I
guess that's the frog in boiling water syndrome. We just do more and more
hideous patch over patch to maintain the illusion that we're still in the
situation that justified the design of IPv4 ARP. Look at the BESS WG-Docs
currently in IETF last call, e.g., draft-ietf-bess-evpn-igmp-mld-proxy.
> I think that one thing that really hurt NBMA networks (like 25Mbs ATM to
> the desktop that I think IBM was pushing), back in the 1990s was the need
> to have that multicast-emulator as a network component.
My point about the BESS work, see
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/ which is in
that same bucket of emulator and now emulator optimizer! At the same time, the
APs copy the broadcast a N unicast which is more reliable and often faster.
> Meanwhile ethernet was p2p and adhoc/plug and play. Just hook up the coax.
Probably still true at home and Starbucks.
> >> My second thought/question was about non-LLN operations. RFC8505
> can
> >> obviously be deployed into non-LLNs, but there is not yet industry
> (or
> >> 6man/v6ops) consensus that we should do this.
>
> > Clearly, yes. I never managed to raise awareness. If we could get a
> > linux client we'd make a great step.
>
> If the (Linux) client could operate as a 6LR/6BBR, and if they could elect
> a leader... or defer to a switching device that had the 6BBR included.
> Maybe that's no better than MLD snooping.
I was thinking the linux client does the 6LN dance, and the routers or L3
switches or APs would do the 6LR games. Then a server or a designated router
would do the 6LBR.
>
> >> I *think*, but I could be wrong, that if I deploy RFC8505 in
> switched
> >> ethernet space that I no longer need MLD to work correctly in order
> to
> >> make IPv6 work. {I have recently had to extend a busy R office
> LAN
> >> across to another building, using a fairly wide variety of L2
> >> switches, with QinQ trunk from a different enterprise. I think it's
> >> broken MLD, and I think this is why IPv6 is flaky... }
>
> > True. In fact, MLD is already not needed for link scope since it's
> all
> > turned to broadcast, one of the nice little lies that hide and the
> IETF
>
> IPv6 link scope is all broadcast for ND? I don't really understand why
> that is.
Because nobody turns on L2 multicast support though IEEE made 2 passes at
getting it done. And that would just push the scalability issue of maintaining
host routes / registration state one layer down. Think of it this way: a
Solicited node multicast address (that's the SNMA) has the last same 3 bytes as
the IP address. Collisions are rare in a normal network (yeah modulo birthday
paradox). This means as we get close to as many groups as addresses. If the
infra loses that state, ND fails. So that's as much state that we need to
maintain in switches as the registration requires in the routers. There's just
possibly more switches. It's because of that state that the router can live
with only caching, which doubles the overall cost. So why not maintain just one
state per address directly in the routers and be done?
Note: MLD snooping creates equivalent state as L2 multicast support, just done
in a more snoopy way, understand lossy with layer violation, thus less
reliable; so MLD snooping is rarely available and even more rarely turned on
for link scope multicast.
Bottom line: no multicast for Link scope, including ND. First bit in the air
set to 1. Broadcast. Clearly vendors like us had to do something to serve large
venues. And we do, but that's proprietary. Which in my book is a complete
failure from the standardization perspective, specially 6MAN.
> That probably explains why I can patch parts of my broken network together
> by creating explicit routes over IPv6-LL.
He he. Turn MLD off, filter it, whatever, and it all still works. Very sad
joke.
>
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Pascal Thubert (pthubert) wrote:
>> Clearly it will need a cross-WGLC into ROLL. That's not hard.
> Clearly, yes. I did not want to go through the hassle of splitting in 2
> drafts because it makes the interaction and the completeness harder to
> grasp. I'll be presenting the draft at both 6lo and ROLL at the next
> IETF.
I thought about the split as well, but then looked at it, and realized that
we'd have maybe 4 documents, each of which did not stand on it's own well.
>> I think that we'll need to talk about the new MOP a fair bit in ROLL
>> anyway. I don't quite understand the new MOP yet, but I will read
>> deeper during the WG deliberations on the document in the next months.
> Basically that's ingress replication at the Root. Easier to think of it
> as RFC 9010 for multicast.
Yeah, I think that this analogy works for me.
> The 6LN registers the multicast address, the 6LR sends a unicast DAO
> straight to the Root, the Root tunnels the multicast packet to the 6LR,
> the 6LR decapsulates and finds a multicast packet. The 6LR distributes
> the multicast packet to all 6LNs that registered to the address. Maybe
> the draft should use "subscribe" instead of "register" when it's
> multicast or anycast?
That might make it clearer.
Can we do this with ethernet though? i.e. the tunnel is a unicast L2?
Can we finally admit that ethernet is NBMA?
I think that one thing that really hurt NBMA networks (like 25Mbs ATM to the
desktop that I think IBM was pushing), back in the 1990s was the need to have
that multicast-emulator as a network component.
Meanwhile ethernet was p2p and adhoc/plug and play. Just hook up the coax.
> So the multicast tree is really 2 hops, one from
> the Root to N*6LRs over their usual source routed tunnel, one from each
> 6LR to the P*6LNs that subscribed, resulting in N*P copies.
Understood.
>> My second thought/question was about non-LLN operations. RFC8505 can
>> obviously be deployed into non-LLNs, but there is not yet industry (or
>> 6man/v6ops) consensus that we should do this.
> Clearly, yes. I never managed to raise awareness. If we could get a
> linux client we'd make a great step.
If the (Linux) client could operate as a 6LR/6BBR, and if they could elect a
leader... or defer to a switching device that had the 6BBR included.
Maybe that's no better than MLD snooping.
>> I *think*, but I could be wrong, that if I deploy RFC8505 in switched
>> ethernet space that I no longer need MLD to work correctly in order to
>> make IPv6 work. {I have recently had to extend a busy R office LAN
>> across to another building, using a fairly wide variety of L2
>> switches, with QinQ trunk from a different enterprise. I think it's
>> broken MLD, and I think this is why IPv6 is flaky... }
> True. In fact, MLD is already not needed for link scope since it's all
> turned to broadcast, one of the nice little lies that hide and the IETF
IPv6 link scope is all broadcast for ND? I don't really understand why that is.
That probably explains why I can patch parts of my broken network together by
creating explicit routes over IPv6-LL.
> / IEEE interface. The pendant is the 'proxy ARP' on the .11 side that
> claims that the AP replies NAs on behalf of the STA to avoid broadcast,
> but has no specification to support it.
Maybe this is the wedge which would allow one to get traction.
>> If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not
>> need as much L2-multicast to work.
> None, effectively. This draft is a push model (like RFC 8505) vs. MLD,
> DAD, and Lookup, that are pull. Pull requires broadcast. Push requires
> a trustable and complete state in the routers.
Enterprises would prefer to own and control that state.
I suspect that many carriers would prefer that as well.
This feels like DHCPv6 vs RA debate to me.
>> I'm unclear if having done a multicast registration, that the 6LBR is
>> now expected to turn multicasts into unicasts.
> Yes, that's exactly the expectation, at least, per policy. For ND SNMA
> in particular, when the expectation is 0 (DAD) or 1 (Lookup) listener -
> arguably there can be SNMA collision but with 3 bytes random values
> that's birthday paradox - rare for you) -, turning to unicast is
> definitely the right thing to do on any type of network.
Please, can you expand "SNMA"?
> Alt:
> one vendor could decide to implement a real L2 multicast for
> all_routers, and the 6LBR would send the multicasts for which there's
> at least a registration to that group. Then the 6LRs would distribute
> unicast to their subscribers.
I'm trying to understand this part.
I think that maybe it's a transition strategy?
>> This would be a major win for SOHO users with bridged WiFi. This is
>> why I wonder if we are thinking too small by
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Hi all, The document "draft-thubert-6lo-multicast-registration-02" addresses actual needs for lower power device operation in multicast use cases, especially the updates to RFC8505 described in section 6 will enable efficient multicast/anycast address registration for these types of devices. Hence, I do support the WG adoption of the draft. Best regards, Klaus From: fanwg On Behalf Of Huimin She (hushe) Sent: Mittwoch, 20. Oktober 2021 03:54 To: Pascal Thubert (pthubert) ; fa...@wi-sun.org; 6lo@ietf.org; ROLL WG (r...@ietf.org) Subject: Re: [wi-sun fanwg] [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02 Dear all, I support the adoption of the document by the 6lo WG. It provides a feasible way for multicast. Best regards, Huimin From: fanwg mailto:fanwg-boun...@wi-sun.org>> on behalf of Pascal Thubert (pthubert) mailto:pthub...@cisco.com>> Date: Tuesday, October 19, 2021 at 15:12 To: fa...@wi-sun.org<mailto:fa...@wi-sun.org> mailto:fa...@wi-sun.org>>, 6lo@ietf.org<mailto:6lo@ietf.org> <6lo@ietf.org<mailto:6lo@ietf.org>>, ROLL WG (r...@ietf.org<mailto:r...@ietf.org>) mailto:r...@ietf.org>> Subject: [wi-sun fanwg] FW: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02 Dear all: As an author I support the adoption of the document by the 6lo WG. To 6lo, it saves the need for MLD on the constrained devices, and the related multicast no less expensive than the one related to ND procedures. To ROLL brings multicast to the non-storing mode using ingress replication at the Root. That was a long awaited feature since non storing is arch dominant in IOT networks. The WGLC will end soon. Please chime in. Keep safe; Pascal -Original Message- From: 6lo <6lo-boun...@ietf.org<mailto:6lo-boun...@ietf.org>> On Behalf Of Carles Gomez Montenegro Sent: lundi 18 octobre 2021 16:20 To: 6lo@ietf.org<mailto:6lo@ietf.org> Cc: Paul Duffy (paduffy) mailto:padu...@cisco.com>> Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02 Dear all, This is a gentle reminder that the call for adoption below is currently open (note: the call will end this Thursday, EOB). Please state on the mailing list whether you are in favor of adopting the document. Thanks, Shwetha and Carles > Dear 6Lo WG, > > Considering the need and the urgency for the functionality defined in > draft-thubert-6lo-multicast-registration-02, along with the interest > from the Wi-SUN Alliance, this message starts a 10-day call for WG > adoption for draft-thubert-6lo-multicast-registration-02. > > (Link below: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registrat<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-thubert-6lo-multicast-registrat=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655484980%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=rWwvFGz2BNKX1m8d6jl2M3wQPluqMi2SE72r5LFg%2B9E%3D=0> > ion) > > The call will end on the 21st of October, EOB. > > Please state whether you are in favor of adopting this document. > > Also, any comments you may have, and/or expressions of interest to > review the document, will be very much appreciated. > > Thanks, > > Shwetha and Carles > > > ___ > 6lo mailing list > 6lo@ietf.org<mailto:6lo@ietf.org> > https://www.ietf.org/mailman/listinfo/6lo<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655494925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=PIxxyxrOcj2fubR8KJDPZ1Ed%2FKgYv5KijmVPTFLJ5A0%3D=0> > ___ 6lo mailing list 6lo@ietf.org<mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo=04%7C01%7Cklaus.hueske%40renesas.com%7C943f04d7e534476d6b0408d9936c8972%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C1%7C637702916655494925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=PIxxyxrOcj2fubR8KJDPZ1Ed%2FKgYv5KijmVPTFLJ5A0%3D=0> ___ Copyright (C) 2021 Wi-SUN Alliance. The contents of this email are confidential and may not be disclosed to non-members without prior written consent of an authorised representative of Wi-SUN Alliance. To unsubscribe or for other subscription options, please visit: https://l
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Hello Michael:
Many thanks for your support! Bottom line is I agree throughout; let's see the
details below:
> I have read draft-thubert-6lo-multicast-registration.
>
> I think that it should be adopted.
>
> As I read it, I began to wonder if 6lo is the right place!
> 6man? roll?
>
> Clearly it will need a cross-WGLC into ROLL. That's not hard.
Clearly, yes. I did not want to go through the hassle of splitting in 2 drafts
because it makes the interaction and the completeness harder to grasp.
I'll be presenting the draft at both 6lo and ROLL at the next IETF.
> I think that we'll need to talk about the new MOP a fair bit in ROLL
> anyway.
> I don't quite understand the new MOP yet, but I will read deeper during
> the WG deliberations on the document in the next months.
Basically that's ingress replication at the Root. Easier to think of it as RFC
9010 for multicast.
The 6LN registers the multicast address, the 6LR sends a unicast DAO straight
to the Root, the Root tunnels the multicast packet to the 6LR, the 6LR
decapsulates and finds a multicast packet. The 6LR distributes the multicast
packet to all 6LNs that registered to the address. Maybe the draft should use
"subscribe" instead of "register" when it's multicast or anycast?
So the multicast tree is really 2 hops, one from the Root to N*6LRs over their
usual source routed tunnel, one from each 6LR to the P*6LNs that subscribed,
resulting in N*P copies.
>
> My second thought/question was about non-LLN operations.
> RFC8505 can obviously be deployed into non-LLNs, but there is not yet
> industry (or 6man/v6ops) consensus that we should do this.
Clearly, yes. I never managed to raise awareness. If we could get a linux
client we'd make a great step.
> I *think*, but I could be wrong, that if I deploy RFC8505 in switched
> ethernet space that I no longer need MLD to work correctly in order to
> make IPv6 work.
> {I have recently had to extend a busy R office LAN across to another
> building, using a fairly wide variety of L2 switches, with QinQ trunk
> from a different enterprise. I think it's broken MLD, and I think this
> is why IPv6 is flaky... }
True. In fact, MLD is already not needed for link scope since it's all turned
to broadcast, one of the nice little lies that hide and the IETF / IEEE
interface.
The pendant is the 'proxy ARP' on the .11 side that claims that the AP replies
NAs on behalf of the STA to avoid broadcast, but has no specification to
support it.
We collectively prefer believing the lies that work on surface than facing the
technical facts.
So we keep doing useless MLD for SNMA and yet broadcast over radios - or use
proprietary stuff that's bound to interfere with future standards. Interesting
isn't it?
>
> If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not
> need as much L2-multicast to work.
None, effectively. This draft is a push model (like RFC 8505) vs. MLD, DAD, and
Lookup, that are pull. Pull requires broadcast. Push requires a trustable and
complete state in the routers.
=> push is adapted to NIC of the 80's where memory was scarce and broadcast
cheap and reliable
=> pull was adapted to low power that's not necessarily awake to listen to
broadcasts, overlays and radios that hate broadcast, and any route over
operation.
> But, if someone had some other multicast dependant system, (such as
> mDNS over IPv6), then RFC8505 alone would not help. As I understand
> it, this document *would* help.
mDNS uses Link Local which is a proxy for the MAC and the scope of a L2
broadcast domain.
In a use case like a large campus, you might want to separate the scope of a L3
Link (to be peer relationship like host to router), the L2 broadcast domain (so
mDNS reaches the nearest printer), and the subnet (which spans the region where
you do not want to renumber). Once you've done decoupled from IP subnets and
links from L2 broadcast domain and made the L2 broadcast domain suitable for
your physical world needs, it's OK to L2 broadcast the mDNS L3 multicast.
>
> I'm unclear if having done a multicast registration, that the 6LBR is
> now expected to turn multicasts into unicasts.
Yes, that's exactly the expectation, at least, per policy. For ND SNMA in
particular, when the expectation is 0 (DAD) or 1 (Lookup) listener - arguably
there can be SNMA collision but with 3 bytes random values that's birthday
paradox - rare for you) -, turning to unicast is definitely the right thing to
do on any type of network.
In route-over, ingress replication respects the idea of non-storing whereby
there's no state in the intermediate routers, and is compatible with legacy
routers that just forward the encapsulated packet (same as for RUL).
In mesh-under and Ethernet, the 6LR and 6LBR can be collapsed, and the 2 steps
become one. The result is a complete state at the LBR with the list of all
listeners, just like MLD would have built. From there, it's up to the 6LBR. It
that
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear all, I support the adoption of the document by the 6lo WG. It provides a feasible way for multicast. Best regards, Huimin From: fanwg on behalf of Pascal Thubert (pthubert) Date: Tuesday, October 19, 2021 at 15:12 To: fa...@wi-sun.org , 6lo@ietf.org <6lo@ietf.org>, ROLL WG (r...@ietf.org) Subject: [wi-sun fanwg] FW: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02 Dear all: As an author I support the adoption of the document by the 6lo WG. To 6lo, it saves the need for MLD on the constrained devices, and the related multicast no less expensive than the one related to ND procedures. To ROLL brings multicast to the non-storing mode using ingress replication at the Root. That was a long awaited feature since non storing is arch dominant in IOT networks. The WGLC will end soon. Please chime in. Keep safe; Pascal -Original Message- From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro Sent: lundi 18 octobre 2021 16:20 To: 6lo@ietf.org Cc: Paul Duffy (paduffy) Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02 Dear all, This is a gentle reminder that the call for adoption below is currently open (note: the call will end this Thursday, EOB). Please state on the mailing list whether you are in favor of adopting the document. Thanks, Shwetha and Carles > Dear 6Lo WG, > > Considering the need and the urgency for the functionality defined in > draft-thubert-6lo-multicast-registration-02, along with the interest > from the Wi-SUN Alliance, this message starts a 10-day call for WG > adoption for draft-thubert-6lo-multicast-registration-02. > > (Link below: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registrat > ion) > > The call will end on the 21st of October, EOB. > > Please state whether you are in favor of adopting this document. > > Also, any comments you may have, and/or expressions of interest to > review the document, will be very much appreciated. > > Thanks, > > Shwetha and Carles > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo ___ Copyright (C) 2021 Wi-SUN Alliance. The contents of this email are confidential and may not be disclosed to non-members without prior written consent of an authorised representative of Wi-SUN Alliance. To unsubscribe or for other subscription options, please visit: https://lists.wi-sun.org/options/fanwg ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
I have read draft-thubert-6lo-multicast-registration.
I think that it should be adopted.
As I read it, I began to wonder if 6lo is the right place!
6man? roll?
Clearly it will need a cross-WGLC into ROLL. That's not hard.
I think that we'll need to talk about the new MOP a fair bit in ROLL anyway.
I don't quite understand the new MOP yet, but I will read deeper during
the WG deliberations on the document in the next months.
My second thought/question was about non-LLN operations.
RFC8505 can obviously be deployed into non-LLNs, but there is not yet
industry (or 6man/v6ops) consensus that we should do this.
I *think*, but I could be wrong, that if I deploy RFC8505 in switched
ethernet space that I no longer need MLD to work correctly in order to
make IPv6 work.
{I have recently had to extend a busy R office LAN across to another
building, using a fairly wide variety of L2 switches, with QinQ trunk from a
different enterprise. I think it's broken MLD, and I think this is why IPv6
is flaky... }
If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not need as
much L2-multicast to work.
But, if someone had some other multicast dependant system, (such as mDNS over
IPv6), then RFC8505 alone would not help. As I understand it, this document
*would* help.
I'm unclear if having done a multicast registration, that the 6LBR is now
expected to turn multicasts into unicasts. In RPL, this is done in a Storing
Mode, where I think the 6LBR knows where the registrations came from, and
therefore can L2 unicast these multicast packets to the appropriate 6LRs that
are next in the mesh.
It seems like if I had an RFC8505+6lo-multicast capable L3 switch (6BBR) in an
ethernet setting, that it would keep track of multicast registrations, and
then L2 unicast traffic to the devices that needed it.
This would be a major win for SOHO users with bridged WiFi.
This is why I wonder if we are thinking too small by adopting at 6lo, and not
6man. Or maybe we need to do the LLN work here, and then write an
operational/deployment considerations document for v6ops.
The deployment hurdles for this might be significant, as I don't think there
is a fax effect, but rather each node adds this code in an altrustic manner
in order to reduce their airtime. For laptops and phones, there might be a
battery savings, but I'm not sure if there is a win until most nodes have
deployed it.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear Chairs I support 6lo WG adoption of this draft. The draft brings important multicast functionality for low power nodes in 6lo networks. Cheers -Original Message- From: Carles Gomez Montenegro Sent: Monday, October 18, 2021 10:20 AM To: 6lo@ietf.org Cc: Paul Duffy (paduffy) Subject: Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02 Dear all, This is a gentle reminder that the call for adoption below is currently open (note: the call will end this Thursday, EOB). Please state on the mailing list whether you are in favor of adopting the document. Thanks, Shwetha and Carles > Dear 6Lo WG, > > Considering the need and the urgency for the functionality defined in > draft-thubert-6lo-multicast-registration-02, along with the interest > from the Wi-SUN Alliance, this message starts a 10-day call for WG > adoption for draft-thubert-6lo-multicast-registration-02. > > (Link below: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registrat > ion) > > The call will end on the 21st of October, EOB. > > Please state whether you are in favor of adopting this document. > > Also, any comments you may have, and/or expressions of interest to > review the document, will be very much appreciated. > > Thanks, > > Shwetha and Carles > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
I support the adoption of draft-thubert-6lo-multicast-registration-02, since it covers much needed definitions on how simple hosts behave in a RPL network, with regards to multicast propagation. Dario Tedeschi Exegin Technologies limited d...@exegin.com <mailto:d...@exegin.com> > On Oct 18, 2021, at 7:20 AM, Carles Gomez Montenegro > wrote: > > Dear all, > > This is a gentle reminder that the call for adoption below is currently > open (note: the call will end this Thursday, EOB). > > Please state on the mailing list whether you are in favor of adopting the > document. > > Thanks, > > Shwetha and Carles > > >> Dear 6Lo WG, >> >> Considering the need and the urgency for the functionality defined in >> draft-thubert-6lo-multicast-registration-02, along with the interest from >> the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for >> draft-thubert-6lo-multicast-registration-02. >> >> (Link below: >> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) >> >> The call will end on the 21st of October, EOB. >> >> Please state whether you are in favor of adopting this document. >> >> Also, any comments you may have, and/or expressions of interest to review >> the document, will be very much appreciated. >> >> Thanks, >> >> Shwetha and Carles >> >> >> ___ >> 6lo mailing list >> 6lo@ietf.org >> https://www.ietf.org/mailman/listinfo/6lo >> > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Oups correct adoption call not WGLC Regards, Pascal Le 19 oct. 2021 à 15:41, Rahul Jadhav a écrit : I support adoption of this draft. In general use of anycast addressing and non storing mode for multicast will be a good extension resulting in more resource optimised options for multicast. On Mon, Oct 11, 2021 at 2:58 PM Carles Gomez Montenegro mailto:carle...@entel.upc.edu>> wrote: Dear 6Lo WG, Considering the need and the urgency for the functionality defined in draft-thubert-6lo-multicast-registration-02, along with the interest from the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for draft-thubert-6lo-multicast-registration-02. (Link below: https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) The call will end on the 21st of October, EOB. Please state whether you are in favor of adopting this document. Also, any comments you may have, and/or expressions of interest to review the document, will be very much appreciated. Thanks, Shwetha and Carles ___ 6lo mailing list 6lo@ietf.org<mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
I support adoption of this draft. In general use of anycast addressing and non storing mode for multicast will be a good extension resulting in more resource optimised options for multicast. On Mon, Oct 11, 2021 at 2:58 PM Carles Gomez Montenegro < carle...@entel.upc.edu> wrote: > Dear 6Lo WG, > > Considering the need and the urgency for the functionality defined in > draft-thubert-6lo-multicast-registration-02, along with the interest from > the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for > draft-thubert-6lo-multicast-registration-02. > > (Link below: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) > > The call will end on the 21st of October, EOB. > > Please state whether you are in favor of adopting this document. > > Also, any comments you may have, and/or expressions of interest to review > the document, will be very much appreciated. > > Thanks, > > Shwetha and Carles > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear all, This is a gentle reminder that the call for adoption below is currently open (note: the call will end this Thursday, EOB). Please state on the mailing list whether you are in favor of adopting the document. Thanks, Shwetha and Carles > Dear 6Lo WG, > > Considering the need and the urgency for the functionality defined in > draft-thubert-6lo-multicast-registration-02, along with the interest from > the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for > draft-thubert-6lo-multicast-registration-02. > > (Link below: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) > > The call will end on the 21st of October, EOB. > > Please state whether you are in favor of adopting this document. > > Also, any comments you may have, and/or expressions of interest to review > the document, will be very much appreciated. > > Thanks, > > Shwetha and Carles > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear 6Lo WG, Considering the need and the urgency for the functionality defined in draft-thubert-6lo-multicast-registration-02, along with the interest from the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for draft-thubert-6lo-multicast-registration-02. (Link below: https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) The call will end on the 21st of October, EOB. Please state whether you are in favor of adopting this document. Also, any comments you may have, and/or expressions of interest to review the document, will be very much appreciated. Thanks, Shwetha and Carles ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
