[RTG-DIR] RtgDir Early Review: draft-ietf-idr-bgp-flowspec-oid-11.txt

[Geoff Huston <[e-mail]>]

(copy to rtg-dir - any followups should include as cc [e-mail], [e-mail])

Hello

I have been selected to do a routing directorate “early” review of this draft: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

A co-chair of the IDR, Susan Hares, has requested an early review of this document

For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-idr-bgp-flowspec-oid-11.txt
Reviewer: Geoff Huston
Review Date: 3 July 2020
Intended Status: Standards Track

Summary: 

I have some major concerns about this document, mainly relating to updates to an RFC-to-be even before the original document has been published as an RFC. I assume that there are reasons why the original document (draft-ietf-idr-rfc5575bis) was not updated directly, particularly given that the initial drafts of this validation revision document predates the initial drafts rfc5575bis document. It is therefore unclear why the process of review of the 5575bis document has not adopted this revised specification during the course of the development of the bis document during its development. The question I am left with is: What has changed in recent times that would make revision of a published RFC more likely than revision of an in-progress working group draft?

Comments:

The document clearly describes the motivation of the revised validation  procedures (reduced operational complexity for dissemination of BGP policy rules when using a route controller).

The proposed revision is susceptible to misunderstanding. It takes the set of three conditions specified in RFC5575bis, where all the conditions must hold for the Flow Specification NLRI to be validated, and altering one of these condition to be two conditions, either of which can hold. The three further comments (labelled 1 through 3 in section 4.1) are unclear in their intent. It is also unclear why the second paragraph in section 4.1 is labelled "a." when there is no subsequent section labelled "b.". The indentation of the succeeding paras of section 4.1 suggest that they are part of the redefinition of step(b) of the validation procedures in RFC5575bis, but the text is descriptive rather than prescriptive and the cumulative intent of this proposed revision is entirely unclear to this reviewer.

It is unfortunate that RFC5575bis chose to add further validation conditions beside the three conditions labelled (a), (b) and (c) in the body of the text in Section 6. This refinement to the original three conditions (a.,b., and c.) is unclear. The revised text in this draft makes this state even more confusing. If the intent of this draft was to clarify the intent of RFC5575 as well as adding additional criteria for validation, then this does not appear to have been achieved.

It is unclear for me that the publication of RFC5575bis and the publication of this draft as further revision to RFC5575bis serves the purpose of extending the utility of the Flowspec validation procedure in a useful manner. If 5575bis is flawed in its description of a clear unambiguous validation procedure then its process through to publication should be halted and the document passed back to the WG. If, on the other hand, the WG is happy with the bis document in its current states, and happy in the light of the knowledge of the existence of this revisionm draft, then it would appear that the working group is unwilling to contemplate the revisions proposed in this draft, and the intent of this draft as a working gropup document is at best confusing.