Ballot for draft-ietf-bier-oam-requirements
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Thanks to the authors and the WG for their work on this document. I would like to discuss the usage of BCP14 keywords in this document in an effort to understand the intention/goal. My understanding is that these keywords are being used to convey requirements of OAM tools and solutions (i.e., application of existing specifications to BIER or development of new specifications for BIER). It is NOT intended to put requirements on implementations - that would be the job of those specifications and not this informational document. With that context, I find that while most of text in this document is aligned with that objective, there are a couple of instances where it is giving the impression of placing normative requirements on implementations or specifying behaviors. "Thus, an implementation of BIER OAM MUST protect the control plane from spoofed replies. Also, an implementation of BIER OAM MUST provide control of the number of BIER OAM messages sent to the control plane." Perhaps? s/an implementation of BIER OAM/a BIER OAM solution/ "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." Please see how this can be rephrased as a requirement rather than a behavior.
Hi Greg, Nagendra, Mach, and Santosh, Thank you for the effort put into this document. Thanks to Gyan Mishra for the OPSDIR review. Please find below some points for DISCUSSion: # Terminology CURRENT: * In-band OAM is an active OAM or hybrid OAM method [RFC7799] in which OAM packets traverse the same set of links and interfaces, and receive the same QoS treatment, as the monitored BIER flow (traffic flows in [RFC7011]). * Out-of-band OAM refers to an active OAM method in which the path traversed through the BIER domain is not topologically identical to that of the monitored BIER flow, or in which the OAM test packets receive different QoS treatment, or both. As you may know, there is an effort to recommend against use of in-band and out-of-band terms in OAM context [1]. I’m afraid these definitions do not reflect recent discussion in this area. For better technical clarity, there might be a need to separate topological congruity vs. received forwarding behavior. These are distinct dimensions. More importantly, the use in the requirement is confusing to me: CURRENT: 7. 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. ## What is meant by “transmitted in-band”? The definition in 1.1.1 does only define “in-band OAM”? ## Are we sure that we always require that such tests must cover both matters (e.g., embedded tracing) vs received forwarding behavior (e.g., QoS)? Aren’t there case when the BIER OAM tool can target one of these? ## I have the same questions for out-of-band. ## I checked all related documents adopted by BIER (draft-ietf-bier-path-mtu-discovery, draft-ietf-bier-ping, draft-ietf-bier-bfd, in particular) and none of them use those terms. # Controllers CURRENT: 3. It SHOULD be possible to initialize a BIER OAM session from a centralized controller. I guess this is a MUST. Any reason why this is SHOULD? BTW, s/ centralized controller/controller as how controllers are deployed is up to the taste of operators. # Controllers again CURRENT: 7. 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. This MUST seems inconsistent with cases where the test is triggered by a controller. # Normative references At list the following ones need to be listed as normative: [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>. [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>.
# I would separate the formulation of each requirement vs. examples. Putting the examples as a separate para would be an easy fix. # nit + multicast domain OLD: This document lists the Operations, Administration, and Maintenance (OAM) requirements for the BIER layer see Section 4.2 of [RFC8279]) of the multicast domain. NEW: This document lists the Operations, Administration, and Maintenance (OAM) requirements for the BIER layer (Section 4.2 of [RFC8279]) of the multicast domain. BTW, I don’t parse what is meant by “multicast domain” here. # Extended version CURRENT: The term "BIER OAM" is used in this document interchangeably with a more extended version, "set of OAM protocols, methods, and tools for BIER layer". Extended version of what? Is it compared to what is defined, e.g., RFC6291? # Network node CURRENT: * OAM session is a communication established between network nodes to perform OAM functions like fault detection, performance monitoring, and localization [RFC7276]. Do we consider a controller as a “network node”? If so, please consider making that explicit in the definition. # Ingress/Egress endpoints Consider adding entries for those in the terminology section. # Dive into solution space? CURRENT: 8. BIER OAM MUST support bi-directional OAM methods. Such methods MAY combine in-band monitoring or measurement in the forward direction with out-of-band notification, as defined in Section 1.1.1, in the reverse direction (i.e., from the egress toward the ingress endpoint of the OAM test session, as in Point-to-Multipoint (p2mp) BFD with active tail [RFC9780]). ## The text with MAY seems to me diving into the solution space. ## Do we have an authoritative reference to cite for bidir OAM? # Sub-requirement CURRENT: 9. BIER OAM MUST support the ability of any BFR in the given BIER domain to monitor Isn’t this falling under REQ#2? # MTU CURRENT: 10. BIER OAM MUST support Path Maximum Transmission Unit discovery [RFC1191]. Isn’t this a sub-case of connectivity verification checks? Wouldn’t make sense to generalize the requirement and mention MTU as an example? # Requirements Order CURRENT: 12. BIER OAM MUST support active and passive performance measurement methods [RFC7799]. I would position this one near REQ#4. Cheers, Med [1] The WG was informed about that effort per https://mailarchive.ietf.org/arch/msg/bier/JL5E9GjP8jkn1-2Bs2fsKoU4sFw/