RE: Submitted ROSA gap analysis and arch drafts - avoiding DNS?
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 Sent: 29 June 2023 20:19 To: Dirk Trossen ; RTGWG 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
Re: Submitted ROSA gap analysis and arch drafts - avoiding DNS?
On Fri, 30 June 2023, 04:19 Joel Halpern, 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 > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
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
