[Tsv-art] Tsvart early review of draft-ietf-idr-bgp-car-05

[Brian Trammell via Datatracker <[e-mail]>]

Reviewer: Brian Trammell
Review result: On the Right Track

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.