Subject: grow: Re: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-04.txt)

From: Bill Woodcock <[email-masked]>
Date: Thu, 20 Jul 2006 21:58:30 -0700

> 2.  Terminology
>    Anycast: the practice of making a particular Service Address
>       available in multiple, discrete, autonomous locations, such that
>       datagrams sent are routed to one of several available locations.

...routed to the topologically nearest of several...

>    Local-Scope Anycast: reachability information for the anycast  
> Service
>       Address is propagated through a routing system in such a way  
> that
>       a particular anycast node is only visible to a subset of the  
> whole
>       routing system.
>
>    Local Node: an Anycast Node providing service using a Local-Scope
>       Anycast address.

I think this is Vixie-specificism which just muddies the waters.  To  
the best of my knowledge, nobody else tries to do this, or uses this  
terminology.  I've never seen a reasoned argument that there was any  
reason to do this, nor heard that anyone else had considered doing  
it.  I'm not sure it needs to be documented outside of ISC tech- 
notes, for ISC staffers who have to maintain it.

Besides, any particular anycast node is, pretty much by definition,  
only visible to a subset of the whole routing system.  So that's not  
a useful definition of something that's been purposely hamstrung.

And you're missing "Anycast Instance."

And if you're going to define "Service Address," you should probably  
define "Unique Address" as well, just for the sake of thoroughness.

>    Anycast is the name given to the practice of making a Service  
> Address
>    available to a routing system at Anycast Nodes in two or more
>    discrete locations.

Why do you care whether people do it at two or more discrete  
locations?  It just needs to be two or more instances, to be  
anycast.  Who cares where they're located?

>        Topological nearness within the
>        routing system does not, in general, correlate to round-trip
>        performance across a network; in some cases response times may
>        see no reduction, and may increase.

It does, in general.  It does not always do so, however.  And while  
it's technically correct to use "and" between "reduction" and "may  
increase," I think your purpose would probably be better served by an  
"or."

> 4.1.  Protocol Suitability

The general rule is that protocols don't matter, but critical  
stateful transactions, like online banking sessions, should be  
handled by unique addresses when possible.

And you may as well take the opportunity to debunk the fallacy about  
problems with TCP.  I have no idea why there are still idiots, ten  
years later, who still think there's a problem, but the point of an  
RFC is to convey information to the clueless, so you might as well  
avail yourself of the chance.

> 4.4.5.  Reverse Path Forwarding Checks

Is this necessary?  It doesn't have anything to do with anycast.

> 4.4.6.  Propagation Scope

Again, this goes into excessive detail on a unique implementation,  
for which there's no evidence of desirability.

>    nodes' internal and external/connecting
>    infrastructure should be scaled to
>    support loads far in excess of the average

More specificity here wouldn't hurt.  "Nodes' internal and connecting  
infrastructure should be scaled in accordance with the "be liberal in  
what you accept and conservative in what you send" principle.   
Specifically, the capacity of each node should be engineered with the  
expectation that traffic will spill over from other adjacent nodes  
which fail, are withdrawn, or are overrun by DDoS attacks.  Likewise,  
nodes should be capable of absorbing potentially much larger volumes  
of traffic than they can actually serve, without unintentionally  
failing-over to adjacent nodes, and multiplying the burden which  
they're already carrying."

> 4.8.3.  Intra-Node Interior Connectivity
>    The IGP in which all nodes participate can be
>    viewed as a single point of failure.

How so?  In what case would the IGP override local routes within a  
node, and bring it down?

> 4.9.  Node Identification by Clients

You might point out that many people run simple web servers on their  
anycast servers, which just serve a page with the name of the site on  
it, to facilitate the work of amateur diagnosticians.

> 6.3.  Service Hijacking
>
>    It is possible that an unauthorised party might advertise routes
>    corresponding to anycast Service Addresses across a network, and by
>    doing so capture legitimate request traffic or process requests  
> in a
>    manner which compromises the service (or both).  A rogue Anycast  
> Node
>    might be difficult to detect by clients or by the operator of the
>    service.

That this isn't something to which anycast nodes are particularly  
vulnerable, and I'm not sure that it makes any sense to say that it's  
less likely to be noticed if it's done to them...  It might also be  
worth pointing out that this is potential abuse of the technique.   
That is, the attack you're describing is, in fact, anycast.  It's  
just rogue anycast, whether or not the address is otherwise anycasted.

Otherwise, looks great.  Nice work.

                                        -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 20 Jul 2006 22:23:19 -0700 (PDT)

> Just to be clear here, if the WG Chair includes your review comments in
    > the write up to the AD (and I'm happy to do so) are you happy to have this
    > document (-04) passed to the IESG for publication as a BCP?

Oh, yeah, I suppose so.  If my nit-pickiness mattered, I'd have gotten 
around to it earlier.

                                -Bill

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Jul 2006 15:18:29 +1000

Hi Bill,

Thanks indeed for these review comments.

You concluded your review with the comment

>Otherwise, looks great.  Nice work.

Just to be clear here, if the WG Chair includes your review comments in the 
write up to the AD (and I'm happy to do so) are you happy to have this 
document (-04) passed to the IESG for publication as a BCP?

regards,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Jul 2006 17:32:05 +1000

>Oh, yeah, I suppose so.  If my nit-pickiness mattered, I'd have gotten

Thanks Bill - I'll include your review comments in the proto write-up to 
the ADs, assuming that this document passes WG Last Call.

regards,

     Geoff