Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
draft-ietf-grow-unique-origin-as-01

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

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.

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.

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.

When do the authors anticipate closing their advertisement for sponsorship?

"Others?  Your name could be here......."

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.