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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi, John:

Thank you for the careful read and very thoughtful comments. Your comments help improve the usability and readability significantly.

We (authors) discussed off-list with you and closed the loop on all your comments. Now reporting back here on the full list.

We (Alexander and I) have updated the draft and uploaded version-20. The changes have been made as agreed with you off-list. We have also made some minor other editorial changes that we felt were needed. The diff file can be viewed here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-20.txt

Note: We used ‘built-in’ in a couple of places. Benjamin suggested replacing ‘built-in’ with a better phrase that is not vague. We’ll do that shortly as we respond to his comments.

Just in case others find it useful, inline comments marked with [AA/KS] are offered below.

Regards,
Sriram / Alexander


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


[AA/KS]: All your suggestions above are incorporated.
s/policy/procedure/  and   s/policies/procedures/  done wherever appropriate.


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.


[AA/KS]: We agree. Done. The new wording for that paragraph is now as follows:

   The OTC Attribute might be set at the egress of the remote AS or at
   the ingress of the local AS, i.e., if the remote AS is noncompliant
   with this specification, then the local AS will have to set the OTC
   Attribute if it is absent.  In both scenarios, the OTC value will be
   the same.  This makes the scheme more robust and benefits early
   adopters.


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.


[AA/KS]: Good point. The following is the expanded wording in place of the wording you cited above:

   …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.  For example, if an AS
   sets the OTC Attribute on a route sent to a Peer and the route is
   subsequently received by a compliant AS from a Customer, then the
   receiving AS detects (based on the presence of the OTC Attribute)
   that the route is a leak.

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,”


[AA/KS]:  Done. The following wording changes have been made:

Old text:

   This document provides configuration automation using BGP Roles,
   which are negotiated using a BGP Role Capability in the OPEN message
   [RFC5492].  An eBGP speaker may require the use of this capability
   and confirmation of BGP Role with a neighbor for the BGP OPEN to
   succeed.

   An optional, transitive BGP Path Attribute, called Only to Customer
   (OTC), is specified in Section 4.  It prevents ASes from creating
   leaks and detects leaks created by the ASes in the middle of an AS
   path.  The main focus/applicability is the Internet (IPv4 and IPv6
   unicast route advertisements).

New text:

   This document specifies a means of replacing the operator driven
   configuration-based method of route leak prevention, described above,
   with a built-in method for route leak prevention and detection.

   This method uses a new configuration parameter, BGP Role, which is
   negotiated using a BGP Role Capability in the OPEN message [RFC5492].
   An eBGP speaker may require the use of this capability and
   confirmation of BGP Role with a neighbor for the BGP OPEN to succeed.

Note: We’ll replace ‘built-in’ with a better phrase per Benjamin’s comment.


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.


[AA/KS]: Done. The paragraph of concern in Section 1.1 has been removed. The rest of Section 1.1 has been moved to Section 2 which is now titled Terminology.


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.


[AA/KS]: We agreed (off-list) that the wording and reference to RFC 7908 in the top paragraph in the Introduction are good and sufficient.


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.


[AA/KS]: Good suggestion. As agreed in the off-list discussion, we have added the following paragraph in the Additional Considerations (Section 5).

   In AS migration scenarios [RFC7705], a given router may represent
   itself as any one of several different ASes.  This should not be a
   problem since the egress procedures in Section 4 specify that the OTC
   Attribute is to be attached as part of route transmission.
   Therefore, a router is expected to set the OTC value equal to the ASN
   it is currently representing itself as.