Leo, I'm not going to comment on your blog, I have cc'd you on this message directly and would encourage you to join the mailing list and share your views on topics like this into the future.
The timing of your responses is unfortunate, given that this document has been with the RFC Editor for a while now, and essentially just completed AUTH-48 state. That said, IMO I do not believe your issues, addressed individually below, would materially influence the current content of the document either way. In general, and as outlined in the document several times, if this doesn't accommodate your current operational model then you certainly aren't required to use it; diversity is arguably an advantage of the current system. That said, I stand by the recommendations in the document as providing utility to network operations. Regarding the five issues you did bring up on your blog: --------- 1) ""Node" is not well defined. For ISC a node is at least two servers, however if the method in the draft were to approximate the level of granularity found in the RFC 4892 method each server would need to have an ASN so it could be identified by routing. This would require ISC to more than double the number of ASNs in use for F-Root." In reading your comment, and the recent discussion of draft-anycast-diagnostics.txt on [email protected] the last couple of days, I do agree that the definition of "node" is perhaps ambiguous. In hindsight, and for the reasons you outline, perhaps this is a feature, as in my mind "node" could encompass one OR more servers (e.g., 100s), and the routing architectures associated with those servers is left to the devises of the operator, but I'd expect that in most deployment models servers which share a common physical location and network connectivity model should certainly consider using the same routing domain identifier. BTW: the draft does NOT say "each server == node", so in your example you could in aggregate actually use one less AS than you appear to be using today ;-) --------- 2) "This method would all but render the various inconsistent-origin ASN reports available to be useless. To remain relevant, these reports would need to white-list all Anycasted services so they do not appear on the reports which would be a significant additional burden. These reports prove quite useful when networks with IP space, but without ASN's (or BGP) move from provider to provider." The utility of these reports is relative; I consider them of less utility than you, and in fact largely because today prefixes are originated from the same partitioned origin AS (e.g., the F-root model you outline and similar models employed by many others) in multiple locations, and as a result routing system information provides no discriminators of utility to aid in visibility and diagnosis of routing problems based solely on origin AS and identifiers for various services therein -- I'd prefer active data in the routing system providing this indication, hence the recommendations in the draft. --------- 3) "There are other mechanisms already in place that provide this level of data, often with increased precision. For instance, even if ISC were to drop the use of ASN 3557 and originate the service prefix from all of the local ASN's it would be impossible to identifiy a particular server via that method. ISC would continue to recommend using hostname.bind, the RFC 4892 mechanism, to identify F-Root servers; and would even view the RFC 5001 method as superior." I don't see any additional "precision" in your model that's not already enumerated in the current document, e.g., "service level query capabilities" in the Introduction. Both network and service level capabilities are useful, as conveyed in the current text. --------- 4) "This mechanism would likely increase the size of the DFZ routing table. While an Anycast prefix would only take up a single routing slot entry in a BGP device, BGP devices must also consider the paths available to reach that prefix. By creating more unique paths there will be increased memory consumption on all devices in the DFZ." False. Additional routes ("paths") for the prefixes in question exist either way in the respective Adj-RIBs-Ins throughout the routing system, as appropriate, and neither model should result in larger DFZ RIB or derived FIB sizes. On the other hand, as a purely academic exercise I think you could make a case that the extra path you add as a unique intermediate AS does consume additional Adj-RIB-In memory, as do any external elements that have to enumerate it and the common origin in AS-based routing or other policies ;-) --------- 5) "This mechanism is unlikely to help end users. Many Internet end users don't receive BGP feeds. Should their provider run a looking glass or similar service, it may not point to the same Anycast instance as the users connection due to the way that Anycast routing works. Thus this method would have the limited audience of people who actually run BGP speaking routers." This isn't aimed at "end users", although ultimately, it is about adding more transparency to service consumers. As discussed above, service level capabilities should indeed exist for "end users" and clients, I agree. This capability aims to help network operators and others that analyze routing system information to better diagnose issue with a given services and to ideally identify any anomalous or persistently misbehaving elements. Regarding users and looking glass information, yes, if they query an anycasted prefix in a looking glass that doesn't resolve to the node with which they're being routed, well, there's nothing magic here to fix that. OTOH, if it's their ISPs looking glass and resolves to the correct node, or if it's the ISP doing the diagnosis in their own routers, well, with this technique they now have an additional data point to inform operations. --------- Kicker) "In short, ISC believes this draft provides no advantages over the current methods ISC uses with F-Root. At the same time, it has the potential to do real harm to the useful inconsistent-origin ASN services, and may be another contributing factor adding to path bloat in the DFZ. ISC believes the RFC 4892 or RFC 5001 methods are vastly superior to identify DNS Anycast services, and believes similar functionality should be developed for any other Anycasted applications." As indicated above, your DFZ analysis is incorrect. Regarding RFC 4892 and 5001, the document already indicates that it is wholly complementary to these service level identifier capabilities and they are certainly not mutually exclusive. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
