[dns-operations] anycast ops willing to review a IETF draft?

[Wes Hardaker]

Hi Klaus,

Thanks for your feedback on the draft.  I'll respond to some of the
comments that Giovane didn't comment on (specifically the ones related
to pre-generating maps before turning a service on).

> Strictly - "Collecting Detailed Anycast Catchment Maps" can not be
> done before "Actual Deployment".
[...and a few other related comments...]

Yes and no, but I understand your point.  You can actually perform
expected load maps ahead of turning on a service if you have "something"
deployed in advance.  If you have to ship equipment in advance to
perform the measurement then yes, the utility of this recommendation is
reduced to only helping you determine what the loads will be after you
flip the final switch for your production routes (but after you've done
most of the deployment work).  However, it may be possible to get
operator help, or a VM temporarily spun up in a number of potential
locations in advance of actually shipping equipment.  This would help
determine which location you actually want to deploy to.  For example,
I've spoken with network operators that have said they could do this for
me if I wanted to.

> And setting up BGP and have all ISPs accept the prefixes is sometimes
> more work then deplyoing the name servers.

That's a valid point some (much) of the time, but is situation
dependent.  But yes, you do need to have a working and willing
relationship with the potential site in question in order to perform any
sort of routing measurement (be it with shipped physical, their physical
or a VM).  Whether or not to try the techniques in [Vries17b] certainly
depends on the easiness of setting it up.  In some situations, it may
not be worthwhile, I agree.  However, I think the difficulty in using
the technique in [Vries17b] varies widely depending on infrastructure
availability and relationships.

> Further, [Vries17b] tells you how the load will be distributed, but it
> won't tell you if this distribution is good or not, or how the user
> experience (RTT) will be.

Could you further elaborate on what you mean by "distribution is good or
not", because "good" and "not good" are subjective without metrics to
base a decision on.

However, your point about RTT's is absolutely true.  Our document isn't
trying to state, however, that "all metrics will be perfect", but rather
to point out some techniques, backed by academic research, that may
help.  Indeed, [Vries17b] does not measure RTTs; its goal was to measure
load, as you mentioned.  If you have a reference for a peer-reviewed,
academic paper that discusses measurement of RTTs in advance of service
deployment, we'd love to reference it within this potential
Informational RFC.

I suspect there are many other (well-known even0 techniques for helping
operators select and measure potential performance of new anycast sites.
You might consider writing a BCP using your expertise in that area?  It
would likely be a highly useful document.  Our document is not intending
to be a "how to", but I agree that a "how to" would be useful.

> In case of B-root, the anycast does hardly give better performance,
> only reliability.

This is outside the scope of the paper (along with some your other
valuable comments), but I will state this sentence is absolutely true.
The [Vries17b] section of this potential RFC is not trying to classify
what "good" or "bad" is.  Specifically, The paper never discusses "good"
or why you might want to select sites or routing policies to hit a
particular load or other measurement target (RTT, eg).  [Vries17b]'s
goal was to provide operators with additional information to make
choices with, and not to be a comprehensive "how to" document.

>> Operators can spot sub-optimal routing
> How helps [Vries17b] in spotting sub-optimal routing?

[Vries17b provides in-depth knowledge of your catchment reach.  As I
agreed above, it doesn't measure RTT; but it does give you data points
that allows operators to determine, in advance, whether or not their
reach will be roughly what they were hoping for.  "Sub-optimal" may
include "not enough reach" or may include "way too much reach".

> That is true, but IMO it would be more important to give advices how to
> choose a "good" location before doing [Vries17b]

I'd love to read, and would support, someone writing a comprehensive BCP
about how to do site selection.  Again, that's not the point of this
Informational document.

-- 
Wes Hardaker
USC/ISI