[Idr] Comment on terminology in Section 4 of draft-ietf-idr-segment-routing-te-policy-24

[John Scudder <[e-mail]>]

Hi Authors,

I was looking for something in draft-ietf-idr-segment-routing-te-policy-24 and got hung up on your use of terminology in Section 4 and its subsections.

You use several terms that are colloquially pretty clear — “acceptable," “usable,” and “propagation” are the ones I picked out. My concern is that these aren’t well-defined terms of art in the context of BGP. One fix would be to rewrite the section with exquisitely correct reference to the model used by RFC 4271, talking about Adj-RIBs-In, Adj-RIBs-Out, movement of routes between them, and so on. That would be a lot of work, though, and would make the document less readable for the casual punter. So I don’t want to advocate for that.

It seems to me that a reasonable middle ground would be to introduce definitions of these terms, along the lines of,

4.2.1

The term “acceptable” as used in this section refers to whether a route is syntactically and semantically well-formed and is eligible to be considered for route selection during the decision process (Section 9.1 of [RFC4271]).

4.2.2 

The term “usable” as used in this section refers to whether a route that was selected by the decision process for installation (Section 9.1. of [RFC4271]) is eligible to be instantiated in the forwarding plane of the local router, but does not limit its eligibility for propagation (see Section 4.2.4).

4.2.4

The term “propagate” as used in this section refers to what Section 9.1.3 of [RFC4271] calls “route dissemination”.

(I’ll grant you that RFC 4271 does itself talk about propagating things, in a few places, so it’s debatable as to whether this definition is strictly needed. But read on.)

I think/hope some updates like these might make the sentence that currently opens Section 4.2.4 a little less mind-bendingly weird when read as plain English: "SR Policy NLRIs that have been determined acceptable and valid can be evaluated for propagation, even the ones that are not usable.” The (ab)use of the term “usable” is the key here, the other definitions are of less importance but it seems worth being thorough. The quoted sentence is, in a way, the exception that proves the rule — by which I mean, if the model had been straightforward to begin with, it wouldn’t have been necessary to introduce a sentence to say “yes yes, you can reflect a route even though we told you it’s not ‘usable’."

I doubt the text I’ve proposed is ideal, it’s just a first draft.

I note that a basic problem here is that in our document set, we’ve diverged fairly far from the “select, install in Loc-RIB, forward” paradigm used by RFC 4271, yet we haven’t introduced any new formal model or terms. First, the model was twisted around by l3vpns, but at least those kept the concept of different RIBs and FIBs so it still kind of worked. Now you’re taking building blocks introduced for l3vpn and pushing them further, but without carrying along the RIB and FIB constructs. I’m reminded of cartoon tropes where a character stands on thin air and is fine until they look down… and then they fall. I kind of have the feeling that we have walked out past the “floor” of our formal model, such as it was, and are standing on thin air, and some of our specs only work as long as we don’t look down. Metaphorically speaking of course.

Hopefully, it will be clear that I’m not seeking terminological perfection here, and I don’t think it’s the job of this spec or group of authors to fix the formal foundations of our protocol. I'm just hoping to keep the document clear and precise enough that people who aren’t part of the in-crowd can reasonably hope to use it.

Thanks,

—John