That works for me... W
On Sat, Jun 2, 2018 at 3:37 PM Ted Lemon <[email protected]> wrote: > On Jun 2, 2018, at 12:13 PM, Tom Pusateri <[email protected]> wrote: > > The authors can discuss how they want to change this one or leave it for > later. > > > I would just suggest that we add: > > When an anycast service is configured on a particular IP address and port, > it must be the case that although there is more than one physical server > responding on that IP address, each such server can be treated as > equivalent. If a change in network topology causes packets in a > particular TCP connection to be sent to an anycast server instance that > does not know about the connection, the normal keepalive and TCP connection > timeout process will allow for recovery. If after the connection is > reestablished, the client's assumption that it is connected to the same > service is violated in some way, that would be considered to be incorrect > behavior in this context. It is however out of the possible scope for > this specification to make specific recommendations in this regard; that > would be up to follow-on documents that describe specific uses of DNS > stateful operations. > > I would suggest also that instead of "server instance" we say "service > instance," to avoid creating confusion between a service and a physical > device that provides that service, of which there could potentially be many > answering to a single IP address. > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
