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

["Brian Trammell (IETF)" <[e-mail]>]

hi Sue,

switching inline as per tradition :)

> On 17 Jan 2024, at 01:24, Susan Hares <[e-mail]> wrote:
> 
> 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:


Something might have gone missing in this request, because I received the document as a “please look at this document and say whether it’s good for transport”. So thanks for following up with these questions!

>     • Whether the document was clear  -

I followed the technical details to the limits of my routing ability, so no worries there. My only clarity comment is that the framing of the doc doesn’t make it clear up front that it specifies the mechanism for color-aware routing, leaving the policy either as future work for IDR or out-of-scope as an operational concern. Some language to make this more clear up front and in Section 11, especially, would be appreciated.

>     • What it might want or expect from a “smarter” (intent) network. 

I’m not sure I can represent the opinions of the *entire* transport area accurately here, because there is a Variety Of Opinion in this space ;) Indeed, it might make sense to turn this into a thread in tsvarea@ and-or panrg@. 

There’s recent work on path properties from PANRG that might be of some use here: [RFC 9473](https://datatracker.ietf.org/doc/rfc9473/). This vocabulary was built for a superset of the architectural assumptions made in SR, so it might be of some use.

Personal opinion: I see those 32 bits in the color field and I automatically think of it as a bit field, with most of the bits reserved for intradomain use, and a small number of the bits defined to encode “high level” layer-4/layer-7-relevant preferences.

You’ll get different opinions from different transport folks, but I’ve always been partial to one bit signaling loss-latency-tradeoff. This has been referred to LoLa: draft-fossati-tsvwg-lola attempted to map this onto DSCP and mobile services, draft-trammell-plus-spec and related work specifies this as the L flag in the PLUS header. Equivalent patterns show up in a lot of domains in compute and networking, because they occupy a sweet spot in the tradeoff space between simplicity and capability. 

You could have additional bits for reordering-tolerance and jitter-tolerance, but you don’t need many in the “standard” space. Most of the bits can be used for operator-specific mappings, or larger emergent community applications centered around an IXP.

(My earlier comment about just parsing the color as RGBA was a joke… but if we did specify at most three bits, those bits *could* map to RGB, and and establish a shorthand, e.g. referring to “red” (Rgb) or “cyan” (rGB) paths. This might actually be worth considering as not-a-joke.)

>  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:
>     • an IGP domains within a single AS, or
>     • 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 
>     • Color + NLRI + optional TLVs
>     • 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).   

Okay, so could this proposal be seen as a way to replace community-based hacks with color as a first-order feature of the routing control plane?

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

Thanks for the pointer (it was, I think, referenced in the document) — I’ll have a look.

>  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

Thanks!

Cheers,

Brian

>   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 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.