On 2010-09-16, at 08:26, Danny McPherson wrote: > On Sep 16, 2010, at 8:19 AM, Benson Schliesser wrote: > >> I support this document as worthwhile for WG adoption. However I do have >> some comments.
I also support adoption, although I would like to see the document become more of a recorded discussion on the relative merits of unique-origin-AS vs. overloaded-origin-AS than a general recommendation for one over the other. >> The first comment is that, while I agree with the conclusions of the >> document in general, I don't entirely see what operational problems are >> caused by single-ASN anycast deployments. It certainly seems more >> convenient to have unique ASNs for each node, but I can't imagine a concrete >> need. > > Detection of route leaks is _much more difficult if a common origin ASN could > pop up anywhere with any set of adjacent upstream ASNs. I'd like to see a worked example that illustrates these difficulties. Whilst node identification is useful and to be recommended (e.g. see RFC 4786 section 4.9) it's not clear to me that it's good general advice to insist that this be done with AS_PATH. > This helps with that aspect. Additionally, if a particular node were > exhibiting some anomalous conditions, e.g., routing instabilities resulting > the in entire prefix being surprised via flap damping, or perhaps some > aberrant datapath behavior, this would provide a discriminator for which > operators might consider routing policy specification over. The advice we got from a number of prominent vendors at the time we were working on 4786 was that prefixes aren't damped; paths are damped. The choice of origin AS hence only makes a difference in the case where multiple anycast nodes are advertising service prefixes to the same adjacent AS. This is functionally identical to a flapping interconnect between (say) two ISPs in a situation where there are multiple adjacencies between their ASes, e.g. peering in multiple cities/continents/whatever. >> My second comment is that the document should acknowledge the case where a >> common ASN is desirable. For instance, information "hiding" might be a >> desired benefit of using a single ASN for all nodes. Obviously the draft >> should recommend the approach with the most benefit, having enumerated the >> pros and cons. But it should acknowledge the cons of multiple ASNs (aka the >> pros of single ASN) as well. > > Yeah, another good point. I'll give due consideration to both these points > in the next revision. We went down the road of using different AS numbers per node at ISC when we distributed F-Root, but still used a consistent origin AS (3557). The per-node AS was the next one in the AS_PATH (i.e. ..._peer_node_3557$). It was observed more than once that we were wasting number resources (16-bit AS numbers) by assigning an AS per node. Increasing tolerance for 32-bit AS numbers mitigates this, but there is I think some truth in the general rule that any time you treat resources as infinite they wind up being very finite. Another practical consideration is that many ASes with whom you might want to peer (as the operator of an anycast content distribution system of some kind) will be happy to talk to you if they can reach your AS in multiple locations, because that fits their existing peering model. Suggest a different AS in each location and the answer is no, because you don't meet their multiple-location policy. Joe _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
