[RSSAC Caucus] [Ext] FOR REVIEW: RSSAC026v2: RSSAC Lexicon

[Paul Vixie]

On Thursday, 30 January 2020 00:47:11 UTC Paul Hoffman wrote:
> 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.

i see what you want and i understand why you want it. however, i do not think 
this goal is achievable. i'll explain in detail, below.

> However, there is some circularity and repetition that might get in the way
> for use of the terms. The following is based on Wes' proposal, along with
> Terry's idea. It has a bit of editing to match the current formatting, to
> simplify, and to tie the definitions together a bit closer. It is presented
> in the order it could appear in the document.

thank you for this draft, it's an excellent next step toward publication. for 
brevity, i will omit most of the text which i think is perfect.

> =====
> 
> root server operator  ...
> 
> root server identifier ...
> 
> root server ...
> 
> root server instance
> A root server instance is the portion of a root server operator's
> infrastructure that serves root data at one of the IP addresses associated
> with a root server identifier.
> 
> instance (anycast instance) ## remove ...
> root server identity  ## remove ...
> 
> =====

in the elided (...) text, there's an implication that an operator with two 
identifiers (like verisign with A and J) is the same as an operator with two 
addresses (like IPv4 and IPv6). this probably deserves to be clarified, 
because an instance can serve multiple addresses in the second case but not in 
the first case. but i will not focus on that element in this review.

> Thoughts?

i harkened to brian's observation that the foundation of meaning for the term 
'root server instance' was its reachability. your definition accurately 
removes 'site' and 'location' which are not accurate discriminators, but 
leaves us with no discriminator at all, because there is no discriminant for 
the word 'portion'. it's not just any portion, it's a very particular portion.

for example at cogentco, C has two servers per instance, using ECMP load 
balancing, and these are called 'a' and 'b'. one allowable 'portion of a root 
server operator's infrastructure that serves root data at one of the IP 
addresses associated with' C root would be all of the 'a' boxes worldwide. 
this would be crazy, since the 'a' boxes are not related to each other other 
than by their similarities of purpose and of configuration.

we have dispensed with 'site' and 'location' as relationships which would 
define a 'portion of' as a 'root server instance', and that's good (says me). 
what remaining relationship do the constituents of such a 'portion' actually 
have, that makes that 'portion of' into an 'instance'? in brian's draft, the 
relationship was based on reach. that is, on shared connectivity which is 
disjoint from all constituents of all _other_ instances of the same root 
server.

if we don't want to talk about routing or mention the word "anycast" i'll be 
fine with that. in the past, some f-root instances were private, available 
within some autonomous system but in no way globally reachable. those were 
'instances' and they do fit some technical definitions of 'anycast' but not 
others (because an IGP like OSPF is different from an EGP such as BGP.) so, 
'anycast' is tarnished with confusion, and i'm happy to see it go.

however, we have to have a discriminant for 'portion of'. my proposal is:

"A root server instance is the portion of a root server operator's 
infrastructure [dedicated to serving] root data at one [or more] of the IP 
addresses associated with a root server identifier [and having connectivity 
disjoint from all other instances of the same server]."

-- 
Paul