Re: [GROW] last call for draft-ietf-grow-unique-origin-as-00

[Joe Abley <[e-mail]>]

On 2010-12-16, at 23:54, Peter Schoenmaker wrote:

> I would like to issue last call for draft-ietf-grow-unique-origin-as-00.  We
> will close last call Jan 2nd 2011.
> 
> Please review the draft and provide any last comments.

summary

I have reviewed the document and have a couple of comments. I don't have any great disagreement with the conclusion, but I don't feel that the document as written provides a clear path of logic to support it. I don't object to its publication as-is, but I feel that it could be improved.


substantive(ish)

Section 2 includes the text:

   Service level query capabilities may or may not provide a mechanism
   to identify which anycast node responded to a particular query,
   although this is likely both service (e.g., DNS or NTP) and
   implementation dependent.  For example, NSD, Unbound, and BIND all
   provide 'hostname.bind or hostname.id' [HNAME] query support that
   enables service-level identification of a given server.

NSD, unbound and BIND deserve references, I think (or should be generalised to "several prominent authority-only and resolver implementations").

HOSTNAME.BIND and ID.SERVER queries use the CHAOS class and the TXT RRType, not HNAME (I appreciate HNAME is just an anchor for an eref, but it's also an RRType, so there is potential for confusion). There is no deployed "HOSTNAME.ID" to my knowledge. A reference to RFC 5001 seems like it ought to be included.

Section 3 (the meat of the document) recommends that individual anycast nodes each originate their service prefixes from a different ASN (i.e. one ASN per anycast node, for the same service). The rationale given is, in my opinion, still weak (which is not to say it's a bad idea -- I just don't see a logical path towards the conclusion).

The operator of a service distributed using anycast might well use one of several available alerting systems to notify them if a service prefix is originated by an unusual AS number. It's not clear to me that in principle this is any easier than checking adjacencies to a single service-specific (i.e. not node-specific) origin AS. Both require ongoing maintenance (updating the list of legitimate origin ASes vs. updating the list of adjacencies). Whilst one might be less work than the other, I don't think it's the universal case that a consistent origin AS is easier, better or more practical. This depends on the deployment strategy for individual services.

I also don't understand the RPKI-related justification, perhaps because I'm insufficiently familiar with the mechanics of deploying it. Under what circumstances would it be difficult to identify who holds the key for a ROA in the case that a service-specific origin AS is used? The only example I can think of is the unusual case where responsibility for operating a service is distributed amongst many entities, such as with the AS112 project. This seems like a corner case.

The resource consumption issue is mentioned but largely dismissed because, with 32 bit AS numbers, we have lots of room and so why worry. While I appreciate that the document mainly discusses critical infrastructure (which is not defined, but the implication is presumably that the number of services distributed using anycast is fairly low) does this assessment sound as convincing for a service deployed using five hundred nodes deployed within ISPs as it does for service deployed using 30 nodes deployed at peering points?

In section 5 the document promotes the use of node-specific origin ASes for the benefit of network operators; the implication seems to be that the network operators concerned are not those responsible for operating the service. I don't the benefits to that community are very well explained in the document. What specifically does a node-specific origin AS allow an operator to do that they can't do with a service-specific origin AS? Again, I'm not arguing with the conclusion, just suggesting that the document does not lead the reader to it in a very satisfying fashion. I appreciate there's a link to a Renesys blog post buried in there, but I think the reasoning that supports the conclusion belongs in the document, not in an external reference (and I don't think that particular blog post describes the benefits of per-node origin ASes very clearly).

Section 8 actually contains no actions for the IANA, and (procedurally) I think it'd be kind to the IANA staff who have to process these documents if it simply said so. References to RIR policy in that section seem to lack teeth (there's nothing the IANA can do about assignment policy developed by individual RIR constituents). RFC 2434 might be a useful reference.


editorial

The document makes many varied uses of the stem "anycast", e.g. anycasted, anycasting. Anycasting has some heritage (e.g. the title of RFC1546). In 4786 we tried to use just "anycast", and use it as a noun. I have a personal preference for that approach, but quite possibly I'm the only one. I thought I'd mention it, anyway :-)


Joe