[pim] Re: [Shepherding AD review] review of draft-ietf-p im-gaap-17

--===============4738875503652447908==
Content-Type: multipart/alternative; boundary="0000000000004f93010656d9d6f1"

--0000000000004f93010656d9d6f1
Content-Type: text/plain; charset="UTF-8"

Hi Linus,

Thanks for the review. We are in last call now so in the final stages but
we will add one line which should satisfy your first question:


> 1)
>
> Am I understanding correctly that for a specific scope all
> GAAP claim messages use the same, single multicast destination address?
> 224.0.1.x and FF0X::TBD? Wouldn't that become a bit noisy if all
> GAAP hosts were sending claims to all other GAAP hosts,
> especially with larger scopes?
>
> What was the reason to decide against sending a record to the
> specific multicast address it is trying to claim? Similar to how
> in IPv6 Neighbor Discovery for duplicate address detection
> such neighbor solicitation messages are sent to the very specific,
> mapped solicited-node multicast address for a unicast address which
> a host wants to claim?
>
> I would have also expected a note on IP header destination
> (and source?) address in section "4. GAAP Message Format"?
>

We use a single well-known address so nodes can discover collisions before
committing to a candidate address, targeting the candidate address directly
would mean joining it before knowing it's free. Noise is bounded by the
periodic/jittered claim timer and per-group suppression. In section 4, we
can add: "The destination IP address is the GAAP Group Address (see Section
9.2); the source IP address is the sender's own address."


>
> 2)
>
> Why UDP and not ICMP? Isn't GAAP in its nature "internet control"
> traffic? Wouldn't GAAP have it easier with adoption, too, if it
> were an ICMP type, especially with RFC 4890 (Recommendations for
> Filtering ICMPv6 Messages in Firewalls)?
>

ICMP has no port concept, so it can't support the NAT/firewall traversal
model GAAP already relies on (destination-port filtering, per section 4). A
new ICMP type would also need its own registry process and ICMP is
filtered/rate-limited at least as often as UDP in practice.


>
> 3)
>
> Is trying to get a 100% collision free multicast address
> allocation a hard requirement for some applications? Or more
> a "nice to have" feature? Applications still need to check the
> message format on that address anyway, right? Is that always worth
> the extra coordination traffic and extra implementation overhead?
>
> (I was kind of wondering if in addition there could be a benefit of
> having a GAAP-light variant. One without GAAP claim messages and on
> a separate "GAAP-light" Multicast Group Allocation
> Range? Maybe with a larger range as the range size + sha256
> would then be the only means to avoid collisions?
> Maybe a GAAP-light could also help with the adoption of,
> be a stepping stone for GAAP?)
>

Yes apps rely on it to avoid manual coordination entirely. A lighter-weight
variant is an interesting idea but would be a separate protocol/draft, out
of scope for GAAP itself.


>
> 4)
>
> Group name: Is there a recommended format (other than ASCII)
> which applications should follow? Or is this left open
> intentionally? If two unrelated, incompatible apps were choosing
> the same group name then they would create a collision undetectable
> by GAAP, right?
>

Take a look at Section 7. GAAP detects hash collisions between different
group names, but can't detect two apps accidentally/deliberately using the
same group name; that's explicitly out of scope, left to naming conventions.


>
> Again, thanks for all your work on this, really looking forward to
> its adoption.
>

And thank you for the review. It should be published soon.
mike


>
> Regards, Linus
>

--0000000000004f93010656d9d6f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Linus,</div><div><br></div><div>Thanks for the rev=
iew. We are in last call now so in the final stages but we will add one lin=
e which should satisfy your first question:</div><div><br></div><div class=
=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><br>
1)<br>
<br>
Am I understanding correctly that for a specific scope all<br>
GAAP claim messages use the same, single multicast destination address?<br>
224.0.1.x and FF0X::TBD? Wouldn&#39;t that become a bit noisy if all<br>
GAAP hosts were sending claims to all other GAAP hosts,<br>
especially with larger scopes?<br>
<br>
What was the reason to decide against sending a record to the<br>
specific multicast address it is trying to claim? Similar to how<br>
in IPv6 Neighbor Discovery for duplicate address detection<br>
such neighbor solicitation messages are sent to the very specific,<br>
mapped solicited-node multicast address for a unicast address which<br>
a host wants to claim?<br>
<br>
I would have also expected a note on IP header destination<br>
(and source?) address in section &quot;4. GAAP Message Format&quot;?<br></b=
lockquote><div><br></div><div>We use a single well-known address so nodes c=
an discover collisions before committing to a candidate address, targeting =
the candidate address directly would mean joining it before knowing it&#39;=
s free. Noise is bounded by the periodic/jittered claim timer and per-group=
 suppression. In section 4, we can add: &quot;The destination IP address is=
 the GAAP Group Address (see Section 9.2); the source IP address is the sen=
der&#39;s own address.&quot;</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
<br>
2)<br>
<br>
Why UDP and not ICMP? Isn&#39;t GAAP in its nature &quot;internet control&q=
uot;<br>
traffic? Wouldn&#39;t GAAP have it easier with adoption, too, if it<br>
were an ICMP type, especially with RFC 4890 (Recommendations for<br>
Filtering ICMPv6 Messages in Firewalls)?<br></blockquote><div><br></div><di=
v>ICMP has no port concept, so it can&#39;t support the NAT/firewall traver=
sal model GAAP already relies on (destination-port filtering, per section 4=
). A new ICMP type would also need its own registry process and ICMP is fil=
tered/rate-limited at least as often as UDP in practice.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3)<br>
<br>
Is trying to get a 100% collision free multicast address<br>
allocation a hard requirement for some applications? Or more<br>
a &quot;nice to have&quot; feature? Applications still need to check the<br=
>
message format on that address anyway, right? Is that always worth<br>
the extra coordination traffic and extra implementation overhead?<br>
<br>
(I was kind of wondering if in addition there could be a benefit of<br>
having a GAAP-light variant. One without GAAP claim messages and on<br>
a separate &quot;GAAP-light&quot; Multicast Group Allocation<br>
Range? Maybe with a larger range as the range size + sha256<br>
would then be the only means to avoid collisions?<br>
Maybe a GAAP-light could also help with the adoption of,<br>
be a stepping stone for GAAP?)<br></blockquote><div><br></div><div>Yes apps=
 rely on it to avoid manual coordination entirely. A lighter-weight variant=
 is an interesting idea but would be a separate protocol/draft, out of scop=
e for GAAP itself.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
<br>
4)<br>
<br>
Group name: Is there a recommended format (other than ASCII)<br>
which applications should follow? Or is this left open<br>
intentionally? If two unrelated, incompatible apps were choosing<br>
the same group name then they would create a collision undetectable<br>
by GAAP, right?<br></blockquote><div><br></div><div>Take a look at Section =
7. GAAP detects hash collisions between different group names, but can&#39;=
t detect two apps accidentally/deliberately using the same group name; that=
&#39;s explicitly out of scope, left to naming conventions.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Again, thanks for all your work on this, really looking forward to<br>
its adoption.<br></blockquote><div><br></div><div>And thank you for the rev=
iew. It should be published soon.</div><div>mike</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards, Linus<br>
</blockquote></div></div>

--0000000000004f93010656d9d6f1--


--===============4738875503652447908==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp
bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw
aW0tbGVhdmVAaWV0Zi5vcmcK

--===============4738875503652447908==--