On Fri, 30 June 2023, 04:19 Joel Halpern, <[email protected]> wrote:
> One of the arguments made in these documents seems to be that by using > this technology you can reduce latency by skipping the DNS step. > > I do not see how that works. Are you assuming that applications will > have the anycast address for a given service hard coded? And that all > operators providing this service will use the same anycast address for > the service? That seems a big ask but unless you do that, DNS is still > required. Encoding service or function identifiers has been done in multicast addresses rather than using DNS to discover them. In IPv6 multicast addresses there are both well-known IANA and locally defined multicast group ids in addresses. One perspective on anycast is that it is similar to multicast, except that the packet is being delivered to only 1 of possibility many anycast destinations, rather than being duplicated if necessary and being delivered to all of possibility many multicast destinations. Unicast - 1 to 1 Anycast - 1 to any Multicast - 1 to many I came up with the following formal IPv6 anycast addressing scheme a while back which accommodated both well known and locally defined service or function identifiers in anycast addresses, heavily inspired by IPv6 multicast's identifier capabilities. https://datatracker.ietf.org/doc/html/draft-smith-6man-form-func-anycast-addresses Regards, Mark. And that is putting aside the fact that we have found that > the indirection through DNS and the resultant decoupling is very helpful. > > Yours, > > Joel > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
