[Idr] John Scudder's No Objection on draft-ietf-idr-bgp-open-policy-19: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-idr-bgp-open-policy-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I’m happy to see this document proceeding forward. Thanks for all the work that
went into it, and into the shepherding. I do have a few points I’d like to
raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a
term with quite a bit of baggage in BGP, and without further qualification,
it’s likely to be interpreted as “routing policy configured by the router’s
operator”. I wondered at first if your choice of “policy” was deliberate, to
imply that the specification is not expected to be hard coded into the
implementation, but rather configured (or not) by the operator? But, the whole
point of the spec is to move away from using policy configuration to protect
against route leaks — requiring configuration to enact the import and export
“policies” given in §4 would fly in the face of the document’s raison d’être.
Furthermore, you close §4 with “the operator MUST NOT have the ability to
modify the policies defined in this section” — and that does help, but not
before considerable potential confusion is created by the unfortunate choice of
terminology.

So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be
hard coded into any compliant implementation. I strongly suggest you find a
term other than “policy” to express what you mean. For example, “procedures”
seems like a good replacement. You could say something like “the following
procedures apply to the processing of the OTC Attribute during route reception”
and “the following procedures apply to the processing of the OTC Attribute
during route transmission”. (You could also try to put it in terms of RFC 4271,
but it might be a bit painful.) I just grepped through §4 and a simple
replacement of “policy” with “procedure” throughout seems like it would be
almost sufficient.

I was ready to make this a DISCUSS until I came to the final sentence of §4.
That sentence does clarify matters sufficiently to reach the minimum bar, but I
think the document would be even more usable if further edits are made along
the lines above.

2. Section 4 says



   The OTC Attribute may be set by the egress policy of the remote AS or

   by the ingress policy of the local AS.

First, my earlier comment about “policy” applies here as well — you could maybe
say “on egress from the remote AS or on ingress to the local AS”. Beyond that,
I suggest changing the “may” (which is admittedly lower-case”) to a “might”,
which has even less risk of confusion with any kind of normative meaning.
Presumably what you mean is actually that if the remote AS is noncompliant with
this spec, the local AS will have to set the attribute, and this is a feature,
not a bug.

3. In Section 4 you write,

   The same OTC Attribute which is set locally also provides
   a way to detect route leaks by an AS multiple hops away if a route is
   received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be
several sentences. I don’t think it’s needed, or even desirable, to explain in
detail in this document how you might make use of the OTC Attribute for
troubleshooting, but if there’s a different document that does explain it, an
informative reference might not hurt. I’m pretty sure I remember this being
covered in one or more IDR and/or GROW presentations, but I don’t know if it
got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP
Roles”. The document, per se, doesn’t provide any such thing of course — an
implementation of the specification would provide such. “This document
specifies” would be more correct I think.

A second point related to the same sentence is that it feels like a poor fit to
refer to what you do in this spec as configuration automation, a term more
usually associated with automatic, typically database-driven, generation and
management of (router) configurations. In the second ¶ of §1, you identify
configuration as the bad, error-prone, legacy way of preventing route leaks. So
maybe something like, “This document specifies a means of replacing the
configuration-based method of route leak prevention, described above, with a
more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are
defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client,
and Peer. I think the definitions provided in §2 are better than those in §1.1,
and sufficient unto themselves, and that you could remove the first ¶ of §1.1.

6. You refer to transit and non-transit providers in many places throughout the
document. Although these seem to some of us like well-known terms of art that
need no reference, I have the feeling that may not be true for our entire
community, or worse still, different people might all “know” what it means but
with different definitions, and so it might be desirable to provide a citation.

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC
7705)? Mostly, I just have a free-floating unease here, because with the hacks
described in RFC 7705, a given router may represent itself as any one of
several different ASes, and your spec does ASN embedding and enforcement. Most
likely there would be no problem, since the egress rules in §4 suggest the OTC
attribute is to be attached as part of route transmission; therefore, a router
might be expected to attach whatever value is appropriate based on the ASN it’s
currently representing itself as. It might still be worth adding a note
cautioning implementors about this, though, since implementations tend to do
things for the sake of efficiency that spec authors aren’t expecting. One
optimization pattern is to pre-build updates and copy them to many different
transport connections; in such cases the OTC value might be prepopulated and
the implementor might need to give extra attention to the exception case where
a particular transport connection is representing a different ASN from the
router's "real" ASN.