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

[Susan Hares <[e-mail]>]

Brian:

Thank you for your careful review on the architecture.   What is necessary for transport to understand is the attempt for the network to provide a "smarter" traffic forwarding through the network based on Intent.
What we needed was tips from Transport Review was:

  1.  Whether the document was clear  -
  2.  What it might want or expect from a "smarter" (intent) network.

I appreciate your comments on where the document is unclear.  As the shepherd, I will work with the authors to refine the document.

If you have any comments on what transport might want or expected from a "smarter" (intent) network flow.

Below I provide you with a few comments that may help other TSV reviewers.

Sue Hares
========
A few comments

Your comments on, O (N**2) mapping for Color domains where a color domain is limited by configuration.  The color domain can be limited by configuration as:

  1.  an IGP domains within a single AS, or
  2.  a group of ASes.

The color mappings may map via configuration (Color blue in AS-1 = Color green AS-2 = low delay) [Per sections 2.5 and 2.8].  Or the color mappings may use an Extended BGP community (LCM) (section 2.10)

This proposal suggests the following two variant of routes

  1.  Color + NLRI + optional TLVs
  2.  NLRI + BGP communities

Attaching BGP communities (normal, extended, large, and wide) is not new. The mechanisms for handling color aware routing are.  Color aware routing attempts to group traffic entering networks by Intent.   The "head end" routers steer traffic into forwarding paths.  The traffic can either be "user traffic" (service traffic) or transport pathway (groups of service traffic).

Spring has been working on a draft to set requirements [draft-hr-spring-intentaware-routing-using color], but discussion abounds.

Just for your reference, RFC9315 (IRTF) provides some background on Intent Routing.   Let me go through 3 terms from RFC9315 in case this might help you refine some of your comments.

  *   Intent routing - is a high level operational goal of traffic forwarding - at the level of network services to pass "Transport" level traffic [
  *   Policy Routing - defines specific polices within routing or forwarding.
  *   Service model - is a high level data model


From: Brian Trammell via Datatracker <[e-mail]>
Sent: Tuesday, January 16, 2024 3:22 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Tsvart early review of draft-ietf-idr-bgp-car-05

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 do
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzBlMTYxNGVkNzMxOGUwNTM0MTkyZTE0NzljMTEyOWZmLzE3MDUzOTMyOTcuMQ==#key=9e4654bacd8ef00b9b5949573cade586>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


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.