Ballot for draft-ietf-bier-oam-requirements

Discuss

Ketan Talaulikar
Mohamed Boucadair

Yes

Gunter Van de Velde

No Objection

Erik Kline

No Record

Andy Newton
Deb Cooley
Gorry Fairhurst
Jim Guichard
Mahesh Jethanandani
Mike Bishop
Orie Steele
Paul Wouters
Roman Danyliw
Éric Vyncke

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Ketan Talaulikar
(was No Objection) Discuss
Discuss (2025-10-15) Sent
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.
Mohamed Boucadair
Discuss
Discuss (2025-10-15) Sent
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>.
Comment (2025-10-15) Sent
# 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/
Gunter Van de Velde
Yes
Erik Kline
No Objection
Andy Newton
No Record
Deb Cooley
No Record
Gorry Fairhurst
No Record
Jim Guichard
No Record
Mahesh Jethanandani
No Record
Mike Bishop
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Éric Vyncke
No Record