Joel, The service address (a binary encoding of the service name, say foo.com) is provided via the ROSA overlay. As an overlay, the ingress SAR is addressed via a unicast address, directing the initial service request to the service instance (of possibly several available ones). So it's anycast semantic but it's not using IP anycast addresses.
With that in mind, the ROSA overlay provides a similar indirection as the DNS (for answering the mapping request from foo.com onto an IP address) but piggybacks that requests onto the initial data packet, continuing to send subsequent packets directly to the resolved IP address. Hence, for that service (and a set of possible other ones the chosen ROSA overlay supports), the ROSA overlay takes the role of the DNS. Other services may (and will) continue using the DNS if it well works for them. Best, Dirk -----Original Message----- From: Joel Halpern <jmh.dir...@joelhalpern.com> Sent: 29 June 2023 20:19 To: Dirk Trossen <dirk.tros...@huawei.com>; RTGWG <rtgwg@ietf.org> Cc: r...@ietf.org Subject: Re: Submitted ROSA gap analysis and arch drafts - avoiding DNS? 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. 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
