tl;dr: okay for TSV, because it's orthogonal to transport concerns as long as the colors aren't defined, or assumed to be definable across domains. I have concerns about the document's scope, though, or rather how it's framed. See inside for details.

Note: I've reviewed this document with two hats:

- as TSVART reviewer looking specifically for issues in the interaction between the routing architecture and layer 4.
- as someone interested in path-aware networking evaluating CAR + SR as a related technology in a slightly different paradigm.

Brian's standard RTG disclaimer: I have specifically *not* evaluated this document for consistency with the idioms of BGP or IDR; I assume the IDR working group has done that. Routing area terminology is mostly disjoint from higher-layer terminology (case in point: "transport"), and the documents I review from the routing area consistently assume a fairly deep grounding in the idioms of that community, so it's entirely possible that I'm missing things in this review, because this document is not written in a language in which I have any proficiency at all. That is a separate issue, but not one I expect the authors of this document to solve. :)

I'll reply with my second hat first, because the main architectural issue with respect to path awareness presented by this document is the basis of any concern I'd have as a transport reviewer. And I'll start with the positive: yay! Though the assumptions made in the application of SR to interdomain deployments and those made in path-aware networking space (which relaxes assumptions about who owns the endpoints, and explicitly foresees path information, here "color" information, exposed up the stack) are a bit different, this looks like a thoroughly workable technology for realizing path-aware interdomain networking between routers, which admittedly has a much easier deployment and operational model, being mostly congruent with the Way Things Are Done today (see RFC 9217 sections 2.7-2.8).

That said, I started off deeply confused about how this is actually supposed to work in an interdomain context. The document starts out in section 1.1 by pointing out that "color" is a uint32_t (bonus points to any router vendor that *actually* parses this as an RGBA value and shows it to the network engineer as such!) mapped to some intent, defined in RFC 9256.

"Color" isn't actually defined in RFC 9256, except as a uint32_t associated with some intent, so I was left with some confusion about how a color value actually selects some queueing strategy or other treatment that would be application-, transport-, or network-engineering relevant. I then stumbled across "Color Domain", which is practically going to be more or less coterminous with an administrative domain. In other words, this document talks about mechanism, leaving policy to local preference and/or future work. Section 2.8 makes this clear by assuming (in language that, apropos of nothing, reads somewhat like marketing to me) that "[t]he BGP CAR solution seemlessly supports this rare scenario" (that a CAR route crosses color domain boundaries), by... requiring color-rewriting gateways. :(

In other words, the deployment of CAR in an interdomain environment relies either on:

(1) An O(n^2) provider-pair mapping of color domains translated at each gateway between domains.

(2) A set of color domains larger than an administrative domain through which a set of operators agree on some values for color (I believe, without much evidence as I don't follow the space, that a similar thing is already happening with communities centered around certain IXPs); 

(2a) probably with an emergence of the structuring of the color numberspace so that interdomain translations can ignore the less/more significant bits and concentrate on a lingua-franca "mask" that mostly means the same thing in most places.

This seems to be at odds to me with the language in section 11, which assumes cross-domain color coordination isn't all that important because color is scoped to IP prefix, and therefore lack of color remapping doesn't lead to availability issues. "Adding this feature where it isn't supported across a domain boundary doesn't break routing", while being minimally acceptable for the deployability of the protocol, also isn't particularly ambitious.

To be clear, this is all perfectly fine. Leaving this document as a specification of mechanism (the easy part IMO) and leave the specification of policy (the hard part IMO) to be either future standardization work, or to emerge from collections of operators that realize value from this feature and want it to work across a peering point, leading to a de-facto standard (if at all), is a reasonable plan for protocol transition (see RFC8170). But, editorially, I'd rather see some language in the abstract/introduction that makes it clear that 
this is the intent, because as I read the abstract, the document promises something it's only delivering the easy half of.

With my transport (RTG folk: this means "layer 4") hat on, since it's the *semantics* of the treatments specified by the colors allowed to be attached to routes by BGP CAR that are evaluable from a TSV standpoint, the details of how these colors are defined and implemented determine whether a given deployment of BGP CAR is problematic or unproblematic for the transport protocols, this document is both fine and not fine from a transport standpoint. I suppose as long as networks don't, for example, define colors specifically for gratuitous violations of RFC 8085 (and why would they?), this document is OK for transport.