Document: draft-ietf-bier-oam-requirements Title: Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer Reviewer: Dale Worley Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-bier-oam-requirements-18 Reviewer: Dale R. Worley Review Date: 2025-10-05 IETF LC End Date: 2025-10-08 IESG Telechat date: [not known] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. I am not an expert on routing. So I cannot comment on whether the list of requirements in section 2 is necessary or sufficient for BIER OAM. From from an outside-looking-in point of view, I have the following questions about the requirement statements. I expect that they are all "nits", the authors and WG agree on the intention of the requirements and what I am requesting is that they be more clearly stated (for the inexpert reader). I assume that the term "support XYZ" is understood to mean that the BIER OAM specification MUST specify particular ways of doing XYZ, not just the general concept "It must be possible to put on top of BIER OAM some method of doing XYZ." Although I notice that requirements 2, 3, and 6 do not use the word "support"; do they apply to BIER OAM in a different way than the others? 5. BIER OAM MUST support unidirectional OAM methods, both continuity check (e.g., Bidirectional Forwarding Detection (BFD) [RFC8562]) and performance measurement (e.g., Simple Two-way Active Measurement Protocol (STAMP) [RFC8762]). Is "unidirectional OAM" a known term of art? Naively I do not think of any OAM operation as "unidirectional", as any OAM operation will involve some client element sending packets to effect an OAM operation to some targeted server element, which will send a response. But perhaps "unidirectional OAM" means "OAM that is only concerned with one direction of packet flow on the particular path". 6. BIER OAM packets in the forward direction (i.e., from the ingress toward the egress endpoint(s) of the OAM test session) MUST be transmitted in-band, as defined in Section 1.1.1. Is "in the forward direction" a known term of art? The statement seems to presuppose that all OAM operations are test sessions of traffic from an ingress endpoint to an egress endpoint. But ISTM that many "management" operations involve a control device issuing e.g. configuration commands to controlled devices. But perhaps "OAM" is a term of art restricted to "monitoring traffic flows and generating test traffic flows" and does not include such "operational" traffic as configuration operations. 8. BIER OAM MUST support proactive monitoring of BFER availability by a BFR in the given BIER domain, e.g., p2mp BFD active tail support [RFC9780]. The phrase "by a BFR" seems ambiguous. Does it mean that there MUST exist *some* BFR that can monitor, or MUST *every* BFR be able to monitor? The quantifier of "BFR" here seems to be very important, and probably that phrase should be clarified and moved toward the beginning of the sentence. E.g. "BIER OAM MUST support the ability of any BFR in the given BIER domain to proactively monitor BFER availability...". But that raises the question of *which* BFER paths each BFR MUST be capable of monitoring. I suspect the WG has a consensus on that but it isn't stated explicitly here to my reading. 12. BIER OAM MUST support unidirectional performance measurement methods to calculate throughput, loss, delay, and delay variation metrics [RFC6374]. STAMP ([RFC8762] and [RFC8972]) is an example of an active performance measurement method and performance metrics that may be applied in a BIER domain. The Alternate Marking Method, described in [RFC9341] and [RFC9342], is an example of a hybrid measurement method ([RFC7799]) that may be applied in a BIER domain. The use of the plural "methods" literally means that OAM MUST support more than one one method. I suggest "BIER OAM MUST support unidirectional performance measurement method(s) that (together) calculate throughput, loss, delay, and delay variation metrics [RFC6374]" 13. BIER OAM MUST support defect notification mechanism, like Alarm Indication Signal [RFC6427]. Any BFR in the given BIER domain MAY originate a fault management message [RFC6427] addressed to any subset of BFRs within the domain. As above, I suggest "BIER OAM MUST support defect notification mechanism(s)." The second sentence isn't phrased quite right; it is stated as something that a BFR MAY do but the requirement is implicitly a MUST on the BIER OAM design. I suggest "BIER OAM MUST provide a way for [or "support"] any BFR in the given BIER domain to originate a fault management message [RFC6427] addressed to any subset of BFRs within the domain." I notice that many other requirements specify that BIER OAM must support a particular feature and then name a particular technique as one way the feature could be supported. But this requirement specifies that the defect notification mechanism MUST be RFC6427 in the second sentence. Although oddly, the first sentence just names RFC6427 as one possible notification mechanism. Is RFC6427 a MUST or just an example? One or the other sentence should be adjusted accordingly. 14. BIER OAM MUST support methods to enable the survivability of a BIER layer. These recovery methods MAY use protection switching and restoration. This seems too vague to me. Is the intention "BIER OAM MUST support one or more methods that enable the survivability of a BIER layer."? This is a case where the meaning of "support" is particularly important. There are a few requirements that have single sentences that describe MUST requirements and then mention a possible mechanism for satisfying that MUST. This applies to requirements 5, 8, 10, and 13. For clarity, I suggest separating the example into a different sentence than the MUST to avoid any confusion regarding what is being required. Requirement 12 is an example of what I think is a better format. [END] _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
