Early Review of draft-ietf-mboned-non-source-routed-sr-mcast-04
review-ietf-mboned-non-source-routed-sr-mcast-04-opsdir-early-farrel-2026-06-09-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer
for this Internet-Draft.

The Operational Directorate reviews all operational and management-
related Internet-Drafts to ensure alignment with operational best
practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management
in IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management
Area Directors (Ops ADs), the authors should consider them alongside
other feedback received.

**Document**: draft-ietf-mboned-non-source-routed-sr-mcast-04

**Reviewer**: Adrian Farrel

**Review Date**: 2026-06-10

**Intended Status**: Informational

---

## **Summary**

I have some **minor** concerns about this document, and a list of nits.
Once these are resolved, I think the document will be ready for
advancement.

But I wonder whether the draft has been shown to SRV6OPS for their
comments.

## **General Operational Comments Alignment with RFC 5706bis**

While this document is clearly all about deployment and operations, it
is not explicit about opearoinal and management considerations and lacks
a specific "Operatioal Considerations" section.

The authors could consider adding a brief section if they feel there is
useful operational guidance to be provided for consideration of the
various multicast deployment options.

Topics that you might consider are:
- how are packet flows diagnosed?
- what configuration is needed?
- what are the relative control plane and management plane loads

## **Minor Issues**

It would be nice if the document was more clear about its purpose.

As it stands, the Abstract says "this document discusses non-sourced-
routed options for multicast in an SR network with either MPLS or
IPv6/SRv6 data plane." Is that it? This is just a discussion?

Why should someone read this document? Who is it for? What is its
message?

The Introduction is a little better with...
   This document summarizes options for non-source-routed multicast in
   an SR network, including traditional multicast technologies, BIER,
   and various SR specific solutions.  The pros and cons of each
   solution are listed for considerations by operators and vendors, with
   regard to the principle and characteristic of SR as mentioned above.
...but that is still light on the motive for reading the document. What
does the reader get from it? What is the purpose of the
"considerations"?

---

Section 3 is full of useful information, but the list of bullet points
are presented as unsubstantiated assertions. I don't mean to disbelieve
the authors, and I accept that this document has been reviewed by the WG
which has (presumably) not disputed any of the points, but rendered like
this, the information has to be subject to academic suspicion. And the
final bullet sounds very much like marketing!

It is probably the case that there is no formal (or informal) survey at
which you can point, so the solution might be to put this in the context
of the authors' viewpoint. Such as:
OLD
   with the following developments:
NEW
   with the following developments that the authors have observed:
END

---

Section 6

   The FUNCT
   bits correspond to the tree-identifying label in SRmpls-P2MP, and the
   LOC bits get the traffic from an upstream node to a downstream node
   (which could be directly or indirectly connected).

Are you sure? FUNCT is usually used to identify the endpoint behavior
which in this case would be "End.P2MP" or something, while the ARGS
field would contain the tree identifier.

---

Section 7 gives a good collection of points for consideration, but I'm
not sure it really helps in the decision process. Could you perhaps
present this as a series of decision points?

---

Section 8

It seems to me that you could usefully discuss the different security
implications of the different approaches. Do some of them have better
or worse exposure? Since P2MP is an amplification, are there different
risks of an amplification attack?

---

Section 9

I think some of your references are normative: they are dependencies for
correctly understanding this dcument.

[RFC8402]
[RFC9262]
[I-D.zzhang-pim-multicast-scaling-considerations]
[RFC7761]
[RFC4875]
[RFC6388]
[RFC7473]
[RFC8279]
[I-D.ietf-bier-pim-signaling]
[I-D.ietf-pim-sr-p2mp-policy]
[RFC9524]
[I-D.ietf-bess-bgp-multicast]
[I-D.ietf-bess-bgp-multicast-controller]
[RFC8986]

## **Nits**

idnits points out that the document lacks an IANA considerations section

---

It would be better to not use the term "traditional multicast
technologies" (etc.). There a concern in some spheres that the word
"traditional" is insufficiently clear [1] , but the IESG asks that we
avoid it in line with their principles for inclusive lanuage [2].

Actually, the term makes me chuckle. My father's father practiced
multicast in the old way according to tradition. He hand-carved packets
from the heart of the willow tree and sent them into the air using a
steam-powered launcher.

I suspect that, because IP multicast has not been around so long, you
can probably list all of these technologies. If the list at the top of
section 2 is full, then you're done. If it is not full, then perhaps
your term of choice might be "per-tree state-based multicast".

[1]
https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions
[2]
https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-inclusive-language-20210511/

---

Abstract

OLD
w/o
NEW
without
END

OLD
the otherwise needed protocols
NEW
the protocols that would otherwise be needed
END

OLD
can also be removed from the network
NEW
are also not needed in the network
END

---

1.

OLD
the otherwise needed protocols
NEW
the protocols that would otherwise be needed
END

OLD
can also be removed from the network
NEW
are also not needed in the network
END

---

1.

Wouldn't it be better to reference the MSR6 proceedings than the
BoF request?

https://datatracker.ietf.org/meeting/114/materials/minutes-114-msr6-00

---

1.

   As discussed in [I-D.zzhang-pim-multicast-scaling-considerations],
   end-to-end multicast is best via IP multicast trees, though they
   could be transported over some (underlay) tunnels.

What is "they" in this context.
It reads like the trees are transported, but you probably mean the
packets or flows.

---

1.

   In that regard,
   when we talk about multicast in SR networks, we refer to the
   multicast in the underlay SR network - whether it is for underlay
   tunnels transporting overlay multicast (e.g., [RFC6513]), or for end-
   to-end IP multicast directly through (vs. over) the SR network.

This sentence is probably important for the document, but it is very
hard to parse. I wonder whether you could have a go at re-writing it.

---

2.

   While SR allows simplification of state, protocols and centralized
   SDN-control, the traditional methods of delivering multicast traffic
   run contrary to those SR goals.

Something wrong with the punctuation. Probably add a comma after
"protocols".

---

2.

   While with IR there is no per-tree state on those intermediate nodes,
   multiple copies of the same packet may be sent over the same link.

To avoid confusion, s/may/might/

---

2.

   If efficient replication is required, PIM/mLDP/RSVP-TE P2MP can still
   be used for multicast even in an SR network.  Deploying SR in the
   network does not mandate changing the solution that is in place for
   Multicast.

Is "efficient replication" the correct term? I think you are after
efficient network usage.

s/Multicast/multicast/

---

3.

   Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast

and

   However, BIER uses a new forwarding plane that cannot be implemented

Not so new any more. First BIER RFC published in 2017 from an I-D first
posed in 2014.

Anyway "new" never sits well in an RFC.

---

3.

s/Several Major router vendors/Several major router vendors/

---

3.

   *  Some major router vendors have had or will soon have interoperable
      production support of BIER on certain platforms.

I suspect you want s/have had/have/
"Have had" sounds like it is no longer available.

---

5.

OLD
SR-P2MP refers to trees setup not by mLDP or RSVP-TE.  It could
NEW
SR-P2MP refers to trees not set up by mLDP or RSVP-TE.  They could
END

---

5.

s/(e.g. SRv6)/(i.e., SRv6)

---

7.

   *  If most of nodes can support it, BIER is the best choice, because
      it removes state from the network and simplifies the control-plane
      (like SR does).

   *  If efficient multicast replication is required, mLDP/RSVP-TE/PIM
      can still be used for multicast purpose if that is acceptable.

This reads as though BIER is not efficient. Is that your intention?