MIME-Version: 1.0
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 19 Jun 2026 13:21:09 -0400
Message-ID: 
 <CAF4+nEGc_EVQQw1zu_xE44YjmQxbi6hq46skXGK+838M55udgA@mail.gmail.com>
To: mboned@ietf.org
Content-Type: multipart/alternative; boundary="00000000000075584506549e85cd"
Message-ID-Hash: PR44627QS7TUEJH2ZM3NKASUNOGRALND
CC: draft-ietf-mboned-non-source-routed-sr-mcast.all@ietf.org,
 Routing Directorate <rtg-dir@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BMBONED=5DRtgDir_Early_review=3A_draft-ietf-mboned-non-source-ro?=
	=?utf-8?q?uted-sr-mcast-05?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mboned/oZCtIB6loRcpAnlXTbXcKpFlpZU>

--00000000000075584506549e85cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re=
view of this
draft:
https://datatracker.ietf.org/doc/draft-ietf-mboned-non-source-routed-sr-mca=
st-05.txt/
The routing directorate will, on request from the working group chair,
perform an =E2=80=9Cearly=E2=80=9D 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

--00000000000075584506549e85cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,<br><br>I have been selected to do a r=
outing directorate =E2=80=9Cearly=E2=80=9D review of this draft:=C2=A0<a hr=
ef=3D"https://datatracker.ietf.org/doc/draft-ietf-mboned-non-source-routed-=
sr-mcast-05.txt/">https://datatracker.ietf.org/doc/draft-ietf-mboned-non-so=
urce-routed-sr-mcast-05.txt/</a><br>The routing directorate will, on reques=
t from the working group chair, perform an =E2=80=9Cearly=E2=80=9D review o=
f a draft before it is submitted for publication to the IESG.<br><br>For mo=
re information about the Routing Directorate, please see <a href=3D"https:/=
/wiki.ietf.org/en/group/rtg/RtgDir">https://wiki.ietf.org/en/group/rtg/RtgD=
ir</a><br><br>draft-ietf-mboned-non-source-routed-sr-mcast-05<br>Reviewer: =
Donald Eastlake 3rd<br>Review Date: 19 June 2026<br>Intended Status: Inform=
ational<br><br>Summary:<br>I have some minor concerns about this document t=
hat I think should be resolved before it is submitted to the IESG.<br><br>C=
omments:<br>This is a well written informational survey that provides a use=
ful catalog of options for non-source-routed (SR) multicast routing in SR n=
etworks. However, there are a few issues some of which would likely lead to=
 requests for changes later in the process.<br><br>Medium Issues:<br><br>Re=
ferences: The biggest issue I see is the classification of references into =
Normative and Informational. With a couple of exceptions, it appears that a=
ll the RFC references were declared Normative while all the draft reference=
s were classified Informational. However, since this draft is targeted at I=
nformational, in my opinion, there should be few, if any, Normative referen=
ces. Generally, Normative references are things you must read to implement =
what is specified in an RFC, but this draft doesn&#39;t specify any protoco=
l. At an absolute minimum, references should be treated consistently. For e=
xample, RFCs 6826 and 6513 are cited in similar contexts but one is listed =
as Normative and the other as Informational<br><br>Missing: This document i=
s missing the required IANA Considerations section. (While it is not absolu=
tely 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 d=
ocuments, such as this, where IANA does not need to do anything is as follo=
ws:<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 This document has no IANA actions.<b=
r>	<br>(see draft-ietf-ianabis-rfc8126bis).)<br><br>Minor Issues:<br><br>Se=
ction 1, 1st paragraph, last sentence. I&#39;m not sure what being &quot;th=
e number one principle&quot; means. The words &quot;principle&quot; and &qu=
ot;one&quot; do not seem to appear in RFC 8402. Perhaps it should say &quot=
;a major benefit&quot; or something else. This would probably imply a paral=
lel change to the wording of the last sentence in the 2nd paragraph, maybe =
deleting &quot;principle and&quot;. I note that RFC 8402 is careful to say =
things like state is only maintained at ingress nodes; it does not simply s=
ay no per-flow state.<br><br>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.<br><br>Section =
3, 1st sentence: &quot;perfect&quot; sounds a bit like marketing. Suggest r=
eplacing this sentence with something like: &quot;BIER was designed and dev=
eloped 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.&quot=
;<br><br>Section 5: Suggest something like &quot;SR-P2MP does not follow th=
e number one principle of SR after all&quot; -&gt; &quot;SR-P2MP does not p=
rovide the SR benefit of no per-flow state except at ingress nodes&quot;<br=
><br>Section 8: You might get by with this Security Considerations section.=
 However, it would be stronger if a sentence were added noting that the cho=
ice among the options described in the draft has security-relevant tradeoff=
s (for example, controller-based solutions add the controller as a trust po=
int and attack surface; ingress replication changes traffic-amplification p=
roperties).<br><br>Nits:<br><br>Section 3, 3rd paragraph: &quot;sthat&quot;=
 -&gt; &quot;that&quot;<br><br>Section 3, 4th bullet point: Suggest &quot;i=
n BIER WG&quot; -&gt; &quot;in the BIER WG&quot; and &quot;brown field&quot=
; -&gt; &quot;brownfield&quot;<br><br>Section 6: &quot;labels that leads&qu=
ot; -&gt; &quot;labels that lead&quot;<br><br>Section 6: &quot;run PIM prot=
ocol&quot; -&gt; &quot;run the PIM protocol&quot;<br><br>Donald<br>=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<br>=C2=A0Donald E. Eastlake 3rd<br>=C2=A02386 Panoramic Circle=
, Apopka, FL 32703 USA<br>=C2=A0<a href=3D"mailto:d3e3e3@gmail.com">d3e3e3@=
gmail.com</a><br></div>
</div>

--00000000000075584506549e85cd--