Early Review of draft-ietf-mboned-non-source-routed-sr-mcast-05
review-ietf-mboned-non-source-routed-sr-mcast-05-rtgdir-early-eastlake-2026-06-19-00

Hi,

I have been selected to do a routing directorate “early” review of this
draft:
https://datatracker.ietf.org/doc/draft-ietf-mboned-non-source-routed-sr-mcast-05.txt/
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.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

draft-ietf-mboned-non-source-routed-sr-mcast-05
Reviewer: Donald Eastlake 3rd
Review Date: 19 June 2026
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.

Comments:
This is a well written informational survey that provides a useful catalog
of options for non-source-routed (SR) multicast routing in SR networks.
However, there are a few issues some of which would likely lead to requests
for changes later in the process.

Medium Issues:

References: The biggest issue I see is the classification of references
into Normative and Informational. With a couple of exceptions, it appears
that all the RFC references were declared Normative while all the draft
references were classified Informational. However, since this draft is
targeted at Informational, in my opinion, there should be few, if any,
Normative references. Generally, Normative references are things you must
read to implement what is specified in an RFC, but this draft doesn't
specify any protocol. At an absolute minimum, references should be treated
consistently. For example, RFCs 6826 and 6513 are cited in similar contexts
but one is listed as Normative and the other as Informational

Missing: This document is missing the required IANA Considerations section.
(While it is not absolutely required that this section be maintained into
the RFC to be, so it may have instructions to the RFC Editor to remove it
before publication, IANA strongly prefers that it be maintained. The
current preferred wording for documents, such as this, where IANA does not
need to do anything is as follows:

        This document has no IANA actions.

(see draft-ietf-ianabis-rfc8126bis).)

Minor Issues:

Section 1, 1st paragraph, last sentence. I'm not sure what being "the
number one principle" means. The words "principle" and "one" do not seem to
appear in RFC 8402. Perhaps it should say "a major benefit" or something
else. This would probably imply a parallel change to the wording of the
last sentence in the 2nd paragraph, maybe deleting "principle and". I note
that RFC 8402 is careful to say things like state is only maintained at
ingress nodes; it does not simply say no per-flow state.

Section 1, paragraph 3: a naked URL to meeting minutes is an unusual
reference. It seems unnecessary, especially since it is with regard to out
of scope work. Suggest removing it or, if you really want to keep it, make
it a proper Informational reference.

Section 3, 1st sentence: "perfect" sounds a bit like marketing. Suggest
replacing this sentence with something like: "BIER was designed and
developed independently of SR, but is a good fit for an SR network because
it can maintain the SR benefit of no per-flow state at non-ingress nodes."

Section 5: Suggest something like "SR-P2MP does not follow the number one
principle of SR after all" -> "SR-P2MP does not provide the SR benefit of
no per-flow state except at ingress nodes"

Section 8: You might get by with this Security Considerations section.
However, it would be stronger if a sentence were added noting that the
choice among the options described in the draft has security-relevant
tradeoffs (for example, controller-based solutions add the controller as a
trust point and attack surface; ingress replication changes
traffic-amplification properties).

Nits:

Section 3, 3rd paragraph: "sthat" -> "that"

Section 3, 4th bullet point: Suggest "in BIER WG" -> "in the BIER WG" and
"brown field" -> "brownfield"

Section 6: "labels that leads" -> "labels that lead"

Section 6: "run PIM protocol" -> "run the PIM protocol"

Donald
===============================
 Donald E. Eastlake 3rd
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com