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

[Ketan Talaulikar <[e-mail]>]

Hi John,

Thanks again for your comments and helpful suggestions. We've just posted
an update with changes to address your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26

There is now an overview of the entire process on the receiving router as
it relates to RFC4271 at the beginning of Sec 4.2 "Reception of an SR
Policy NLRI". As you've indicated, we do need to explain the term "usable"
since it varies from the base BGP spec - that is now included. The term
"acceptable" has been done away with since that is nothing by "validation".
The term "propagate" is fairly well-known and even referenced (though not
formally) in RFC4271 - but a reference to the specific section of RFC4271
is now added as suggested by you.

Could you please take a look and let me know what you think?

Thanks,
Ketan (on behalf of co-authors)


On Tue, Sep 26, 2023 at 9:39 PM John Scudder <[e-mail]> wrote:

> 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