Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

[Danny McPherson <[e-mail]>]

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 [e-mail] 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.