[pim] Re: Last Call: <draft-ietf-pim-gaap-18.txt> (Group Address Allocation Protocol (GAAP)) to Experimenta l RFC
Nico Cvitak <[email protected]> Tue, 21 Jul 2026 15:06:30 -0400
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <[email protected]> |
--===============3218482135033799302== Content-type: multipart/alternative; boundary="Apple-Mail=_770B53FF-8464-4AFA-864F-9E443D23ED7C" --Apple-Mail=_770B53FF-8464-4AFA-864F-9E443D23ED7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, apologies for the late reply. I think that the sentence you suggested sounds great, as it=E2=80=99d = avoid potential address allocation collisions in domains where GAAP may = be used as a zero configuration group address allocation protocol. Thanks, Nico > On Jul 17, 2026, at 10:14=E2=80=AFPM, Mike McBride = <[email protected]> wrote: >=20 > Hi Nico, >=20 > On that last question regarding encryption, how about we add this one = sentence as you suggested: "Encryption SHOULD only be enabled within a = coordinated administrative domain where all GAAP nodes share the same = encryption configuration and key."? Thank you for the review. >=20 > mike >=20 > On Fri, Jul 17, 2026 at 9:53=E2=80=AFPM Dino Farinacci = <[email protected] <mailto:[email protected]>> wrote: >> Some quick replies. >>=20 >> > On Jul 17, 2026, at 9:20=E2=80=AFAM, Nico Cvitak <[email protected] = <mailto:[email protected]>> wrote: >> >=20 >> > Hi, >> >=20 >> > I think this draft is a great step forward for multicast address = allocation, but I have some comments regarding section 8. >>=20 >> Thanks. >>=20 >> > How are collisions meant to be resolved across GAAP nodes with = different encryption configurations, or lack >>=20 >> These would be different domains that don't connect to each other. = You can run separate instances, especially when there are multicast = group boundaries so the well-known groups stay disjoint. >>=20 >> > thereof? It sounds like they'd just be allowed to collide given the = text in section 8, which doesn=E2=80=99t seem ideal? >>=20 >> If there are no group boundaries, then the packets go to all members = of the well-known group but are dropped by the ones without common = encryption keys. >>=20 >> > I'd imagine that applications wanting to use GAAP as a zero = configuration multicast address allocation protocol as highlighted in = [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] would just not use = encryption for "zero configuration=E2=80=9D? >>=20 >> Right, a tradeoff between plug-and-play and secure communication. >>=20 >> > Perhaps section 8 should be amended to only suggest encryption when = deployed in a coordinated administrative domain where all GAAP nodes = share the same encryption configuration? >>=20 >> I thought we had something like that. I'll leave this for Mike and = Stig to comment about. >>=20 >> Dino >>=20 >> >=20 >> > Thanks, >> > Nico >> >=20 >> >> On Jul 13, 2026, at 11:54=E2=80=AFAM, The IESG = <[email protected] <mailto:[email protected]>> wrote: >> >>=20 >> >>=20 >> >> The IESG has received a request from the Protocols for IP = Multicast WG (pim) >> >> to consider the following document: - 'Group Address Allocation = Protocol >> >> (GAAP)' >> >> <draft-ietf-pim-gaap-18.txt> as Experimental RFC >> >>=20 >> >> The IESG plans to make a decision in the next few weeks, and = solicits final >> >> comments on this action. Please send substantive comments to the >> >> [email protected] <mailto:[email protected]> mailing lists by = 2026-08-03. Exceptionally, comments may >> >> be sent to [email protected] <mailto:[email protected]> instead. In either = case, please retain the beginning >> >> of the Subject line to allow automated sorting. >> >>=20 >> >> Abstract >> >>=20 >> >>=20 >> >> This document describes a design for a lightweight decentralized >> >> multicast group address allocation protocol (named GAAP and >> >> pronounced "gap" as in "mind the gap"). The base allocation = protocol >> >> requires no centralized service and minimal configuration, = although >> >> deployments using encryption or administrative scoping may = require >> >> configuration. The protocol runs among group participants which = need >> >> a unique group address to send and receive multicast packets. >> >> Tailored for IPv4 and IPv6 networks, this design offers a = simple, >> >> lightweight option rather than extending an existing protocol. >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >> The file can be obtained via >> >> https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/ >> >>=20 >> >>=20 >> >>=20 >> >> No IPR declarations have been submitted directly on this I-D. >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >> _______________________________________________ >> >> pim mailing list -- [email protected] <mailto:[email protected]> >> >> To unsubscribe send an email to [email protected] = <mailto:[email protected]> >> >=20 >>=20 > _______________________________________________ > pim mailing list -- [email protected] > To unsubscribe send an email to [email protected] --Apple-Mail=_770B53FF-8464-4AFA-864F-9E443D23ED7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">Hi Mike, apologies for the late = reply.<div><br></div><div>I think that the sentence you suggested sounds = great, as it=E2=80=99d avoid potential address allocation collisions in = domains where GAAP may be used as a zero configuration group address = allocation protocol.<div><br></div><div>Thanks,</div><div>Nico<br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Jul 17, 2026, at 10:14=E2=80=AFPM, Mike McBride = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div dir=3D"ltr"><div>Hi = Nico,</div><div><br></div><div>On that last question regarding = encryption, how about we add this one sentence as you suggested: = "Encryption SHOULD only be enabled within a coordinated administrative = domain where all GAAP nodes share the same encryption configuration and = key."? Thank you for the = review.</div><div><br></div><div>mike</div><br><div class=3D"gmail_quote = gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul = 17, 2026 at 9:53=E2=80=AFPM Dino Farinacci <<a = href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">Some quick replies.<br> <br> > On Jul 17, 2026, at 9:20=E2=80=AFAM, Nico Cvitak <<a = href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > Hi,<br> > <br> > I think this draft is a great step forward for multicast address = allocation, but I have some comments regarding section 8.<br> <br> Thanks.<br> <br> > How are collisions meant to be resolved across GAAP nodes with = different encryption configurations, or lack<br> <br> These would be different domains that don't connect to each other. You = can run separate instances, especially when there are multicast group = boundaries so the well-known groups stay disjoint.<br> <br> > thereof? It sounds like they'd just be allowed to collide given the = text in section 8, which doesn=E2=80=99t seem ideal?<br> <br> If there are no group boundaries, then the packets go to all members of = the well-known group but are dropped by the ones without common = encryption keys.<br> <br> > I'd imagine that applications wanting to use GAAP as a zero = configuration multicast address allocation protocol as highlighted in = [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] would just not use = encryption for "zero configuration=E2=80=9D?<br> <br> Right, a tradeoff between plug-and-play and secure communication.<br> <br> > Perhaps section 8 should be amended to only suggest encryption when = deployed in a coordinated administrative domain where all GAAP nodes = share the same encryption configuration?<br> <br> I thought we had something like that. I'll leave this for Mike and Stig = to comment about.<br> <br> Dino<br> <br> > <br> > Thanks,<br> > Nico<br> > <br> >> On Jul 13, 2026, at 11:54=E2=80=AFAM, The IESG <<a = href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>> wrote:<br> >> <br> >> <br> >> The IESG has received a request from the Protocols for IP = Multicast WG (pim)<br> >> to consider the following document: - 'Group Address Allocation = Protocol<br> >> (GAAP)'<br> >> <draft-ietf-pim-gaap-18.txt> as Experimental = RFC<br> >> <br> >> The IESG plans to make a decision in the next few weeks, and = solicits final<br> >> comments on this action. Please send substantive comments to = the<br> >> <a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a> mailing lists by 2026-08-03. = Exceptionally, comments may<br> >> be sent to <a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a> instead. In either case, please = retain the beginning<br> >> of the Subject line to allow automated sorting.<br> >> <br> >> Abstract<br> >> <br> >> <br> >> This document describes a design for a lightweight = decentralized<br> >> multicast group address allocation protocol (named = GAAP and<br> >> pronounced "gap" as in "mind the gap"). The = base allocation protocol<br> >> requires no centralized service and minimal = configuration, although<br> >> deployments using encryption or administrative = scoping may require<br> >> configuration. The protocol runs among group = participants which need<br> >> a unique group address to send and receive = multicast packets.<br> >> Tailored for IPv4 and IPv6 networks, this design = offers a simple,<br> >> lightweight option rather than extending an = existing protocol.<br> >> <br> >> <br> >> <br> >> <br> >> The file can be obtained via<br> >> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/"= rel=3D"noreferrer" = target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/</a= ><br> >> <br> >> <br> >> <br> >> No IPR declarations have been submitted directly on this = I-D.<br> >> <br> >> <br> >> <br> >> <br> >> <br> >> _______________________________________________<br> >> pim mailing list -- <a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a><br> >> To unsubscribe send an email to <a = href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a><br> > <br> <br> </blockquote></div></div> _______________________________________________<br>pim mailing list -- = [email protected]<br>To unsubscribe send an email to = [email protected]<br></div></blockquote></div><br></div></div></body></ht= ml>= --Apple-Mail=_770B53FF-8464-4AFA-864F-9E443D23ED7C-- --===============3218482135033799302== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw aW0tbGVhdmVAaWV0Zi5vcmcK --===============3218482135033799302==--