On Sep 16, 2010, at 12:31 PM, Joe Abley wrote: > 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.
OK, I can try to talk about the ease of use of a common AS, the number space preservation, etc.. I'm happy to try and captures the pros and cons of each and will attempt to accommodate in the next spin. > 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. So I can expand on what's in the draft and perhaps reconsider text. However, I think simply the fact that there's no unique discriminator in the routing system in and of itself should illustrate why detection of leaks or rogue instances is problematic. Beyond AS_PATH, I can't think of another mandatory transitive attribute in BGP that would be used to discriminate particular instances and align with work being done to align with current RPKI machinery. I didn't intended to insist anything, just to highlight that it can be useful in oeprations. On redraft I'll try to reflect that. > 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. That's not my understanding, my understanding is that most (all?) implementations are per-prefix (I would love to see per-path implementation, and hope folks correct me here), and the measurements I've seen around this highlight just that. E.g.,: <http://www.cs.ucla.edu/~jpark/dupbgp.pdf> Further, RFC 2439 S 4.4.3 and beyond suggests only prefix and length need to be considered. Path is much harder, obviously. > 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. Well, intermediate ASes in the path, as F-root does, don't entirely address my problem. That is, a detection model would have to accept the set of adjacent ASNs for a given origin {origin, adjacent_as_group(1..n)}, where path set could be hundreds of adjacent ASNs. I want to be very specific about origin and adjacent topology models ( {origin1, adjacent_as(1,2)} | {origin2,adjacent_as(3,4) | ..). Further, if one wanted to employ RPKI machinery origin is useful. > 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. And that's yet another reason why highlighting the benefits and utility of this is important. Good feedback as usual Joe, I'll try to accommodate your concerns in the next revision. Thanks! -danny _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
