[RSSAC Caucus] RSSAC026v2 definition of Instance

[Paul Vixie]

+1.

⁣Get BlueMail for Android ​

On 29 Jan 2020, 08:20, at 08:20, Brian Dickson <brian.peter.dickson at gmail.com> wrote:
>On Thu, Jan 23, 2020 at 12:18 PM Paul Vixie <paul at redbarn.org> wrote:
>
>> On Thursday, 23 January 2020 18:59:19 UTC Karl Reuss wrote:
>> > The current definition of Instance in the RSSAC026 lexicon is
>somewhat
>> > ambiguous.
>> > > When anycast routing is used to allow more than one server to
>have the
>> > > same IP address, each one of those servers is commonly referred
>to as
>> an
>> > > instance. For root servers, one refers to "an instance of J-root"
>to
>> mean
>> > > one of the network locations answering to J-root’s IP address.
>> > The first sentence says it's a server, and the second sentence says
>it's
>> a
>> > location. In the current draft, the definition has been changed to
>this:
>> > > *When anycast routing is used to allow more than one server to
>have the
>> > > same IP address, each one of those servers is commonly referred
>to as
>> an
>> > > instance or anycast instance. For root servers, one refers to "an
>> > > instance of J-root" to mean one of the network servers answering
>to one
>> > > of J-root’s IP addresses.*
>> > So now it's a server on one address (which implies there's another
>> instance
>> > on J-root's other IP address).
>> >
>> > Paul thought this could use some discussion and I agree.
>>
>> i agree also.
>>
>> > In my mind, using the word 'server' to define something in this
>context
>> is
>> > confusing.  Is a server a piece of equipment or a software process?
> I
>> > think of an instance as "equipment used at a location used by an
>operator
>> > to provide DNS service".  If I had to define it as a single word, I
>would
>> > say it's a location.
>>
>> since we've known here of cases where two instances in adjacent racks
>each
>> had
>> multiple servers and its own local load balancer but spoke to two
>> different
>> internet exchanges which were present in the same data center,
>"location"
>> is
>> wrong. that's in fact where we got "instance".
>>
>> > At one location for D-root we have 4 Dell servers in the same rack.
>They
>> are
>> > each talking BGP with a router that's using ECMP to reach them. 
>Each
>> Dell
>> > is answering on v4 and v6.   I consider this one instance.
>> >
>> > What do others think?
>>
>> i agree, that's an "instance", because it is a dedicated collection
>of
>> server
>> and network equipment operated as a root name server, having upstream
>> connectivity not shared by any other instance. however, a lot of
>rootops
>> no
>> longer operate their own equipment in some "location(s)", and so
>share
>> server
>> and network equipment with "instances" of other root servers. so,
>> "instance"
>> will have to be defined to account for virtualization including both
>the
>> cloudflare model and the PCH model. i don't know yet exactly how to
>do
>> that.
>>
>> noting that c-root has always used dedicated server equipment but has
>> never
>> had dedicated network equipment (it plugs into cogentco edge routers
>which
>> may
>> also serve other customers), "instance" may have to be defined in
>terms of
>> unique servers which might be virtual, having unique upstream
>connectivity
>> among other instances of the same root server. by leaving out
>"equipment"
>> and
>> leaving out "network", a version of "instance" might suit all current
>and
>> contemplated root server deployments, including the cloudflare and
>PCH
>> models.
>>
>
>I think it may be a bit cleaner to discuss anycast (generally) and then
>what is meant by an anycast instance, and finally what an anycast
>instance
>of a particular root server identity is.
>
>Here's a brief attempt at this:
>
>Anycast is the routing technique of advertising the reachability of a
>> prefix from more than one router, typically (but not exclusively) as
>a
>> global BGP announcement.
>
> An *anycast routing instance* is a single such routing announcement.
>
>The *anycast instance of a root server identity* is the server or set
>of
>> servers reachable via a *single anycast routing instance* of the
>> corresponding identity's IPv4 and/or IPv6 prefix.
>
>
>It leaves unspecified any of the (IMHO unimportant details) of what the
>servers actually are (physical/virtual, dedicated/shared), and leaves
>the
>"network location" as an abstracted "anycast routing instance", for
>similar
>reasons.
>It also allows for flexibility in whether the servers are single-stack
>or
>dual-stack for IPv4/IPv6 announcements/services.
>
>Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200129/0bc767f7/attachment.html>