Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
Note: This ballot was opened for revision 01 and is now closed.
(Jari Arkko; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I have a number of comments that don't quite make it to the level of Discusses, but I would surely welcome it were you to attend to them. --- I feel it would be worth going the extra mile to clarify what level of uniqueness you are asking for. You have text such as: This document makes recommendations regarding the use of per-node unique origin ASNs for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. (Abstract) and In order to be able to better detect changes to routing information associated with crtical anycasted resources, globally anycasted services with partitioned origin ASNs SHOULD utilize a unique origin ASN per node where possible. (Section 3) Owing to the lamentable state of the education system, there is considerable risk that people will not know whether you mean: - A globally-unique ASN is allocated per node or - A node-unique ASN is allocated per anycasted service --- The Routing Directorate review by Stig Venaas raised the following issues that I think should be attended to. Section 2 Regarding traceroute it says: enables service-level identification of a given server. Tools such as traceroute are also used to determine which location a given query is being routed to, although it may not reveal local-scope anycast instances, or if there are multiple servers within a given anycast node, which of the servers responded to a given query, in particular when multiple servers within an anycast node are connected to a single IP router. When utilizing these service level capabilities, Why is local-scope emphasized here? I would think that traceroute always gives you one node. It may be a particular global node, or a local node, depending on your location. It may not reveal local-scope, but it may not reveal global-scope either. They key thing is that you get only one. And you may not know what the scope is either. Am I missing something, or should the text be changed? --- Section 2 Regarding synchronization of instances it says: Additionally, while it goes without saying that anycasted services should always strive for exact synchronization across all instances of an anycasted service address, if local policies or data plane response manipulation techniques were to "influence" responses within a given region in such a way that those response are no longer authentic or that they diverge from what other nodes within an anycasted service were providing, then it should be an absolute necessity that those modified resources only be utilized by service consumers within that region or influencer's jurisdiction. Isn't this a bit DNS centric? I can think of anycast services where different nodes intentionally have different content. I'm not sure if it necessarily is important to restrict it to region or jurisdiction either. It all depends on the service. Maybe rephrase this to point out that this may be an important issue, depending on the service? --- Nit: In the paragraph above I found this line: a given region in such a way that those response are no longer ^^^^^^^^ s/response/responses
(Dan Romascanu; former steering group member) (was Discuss) No Objection
1. ASN should be expanded earlier, probably as soon as the title of the document. 2. In the IANA Considerations section all the text that follows the statement that no actions are required from IANA does not seem IANA related and could be dropped.
(Pete Resnick; former steering group member) No Objection
It's not clear to me why this document is going for BCP rather than standards track, but I expect this topic will be discussed in the context of other documents on the agenda this week, so I'm not going to hold up this one specifically.
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
If you have not already done so, please coordinate with DNSOP regarding <https://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-ops/> and consider whether either document should discuss the other.
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
When do the authors anticipate closing their advertisement for sponsorship? "Others? Your name could be here......."
(Wesley Eddy; former steering group member) No Objection
Section 3 seems like it would work better if the 4th paragraph (on ASN conservation) were moved up to be the 1st paragraph, since it would describe why the rest of the section is now advisable after the addition of support for 32-bit ASNs, and it also describes what this document means by the "critical infrastructure" term that's used in some of the other paragraphs in this section.. Note: idnits complains that the 2119 boilerplate doesn't exist and that 2119 is included as a reference but not referred to in the document.