<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2020 at 4:47 PM Paul Hoffman <<a href="mailto:paul.hoffman@icann.org">paul.hoffman@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wes' formulation seem close to me. I disagree with the proposal that this document should define "anycast" and "anycast routing instance" or "anycast site": that won't help almost any reader of the document. Those things are important to the operators, but there is enough variety of operations that nailing those down by definitions would not be helpful.<br></blockquote><div><br></div><div>I think the question isn't whether "anycast" is necessary, it is rather whether including "anycast" (definition and reference) improves understanding, including to those less familiar or less technical.</div><div><br></div><div>Having a fairly high-level/generic description of anycast, along with a few examples, might suffice, rather than having to nail down definitions.</div><div>Examples could include the following:</div><div>- External BGP announcements from a stand-alone instance (not hosted on anyone else's network infrastructure)</div><div>- Internal BGP announcements, when instances are hosted on someone else's network infrastructure (including the possibility of a single external BGP announcement effectively covering multiple instances learned via internal BGP)</div><div>- Non-BGP announcements, when instances are hosted on someone else's network infrastructure. Those could include OSPF or ISIS.</div><div><br></div><div>The high-level description of an anycast instance might need to indicate that what distinguishes a single instance from something that contains multiple instances, is whether all the hosts that can be reached on the IP address of the RSI, are behind a single router or a small number of routers (e.g. in an ECMP scheme).</div><div><br></div><div>It may be sufficient to explain that from a particular vantage point, it is expected that all queries in a small time window, should only reach a single anycast instance, although they may reach a variety of servers within that instance.</div><div>Two distinct vantage points will either hit the same instance, or two different instances.</div><div>It may also be helpful in describing the nature of anycast instances creating what amounts to a "watershed" as far as vantage points are concerned.</div><div><br></div><div>I.e. what the definitions should try to do, IMHO, is allow a person unfamiliar with anycast to understand why they see what they see when looking at root server identities, regardless of whether the word "anycast" is used. </div><div><br></div><div>Brian</div></div></div>