[MBONED]Re: [RTG-DIR]RtgDir Early review: draft-ietf-mboned-non-source-routed-sr-mcast-05

[Donald Eastlake <[e-mail]>]

Hi Jeffrey,

You changes look OK to me.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


On Fri, Jun 26, 2026 at 5:37 PM Zhang, Zhaohui (Jeffrey) <
[e-mail]> wrote:

> Hi Donald,
>
>
>
> Thank you very much for your review and detailed comments/suggestions.
>
> I have posted a new revision that addresses the comments.
>
>
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-mboned-non-source-routed-sr-mcast-05&url2=draft-ietf-mboned-non-source-routed-sr-mcast-06&difftype=--html
>
>
>
> Jeffrey
>
>
>
> *From:* Donald Eastlake <[e-mail]>
> *Sent:* Friday, June 19, 2026 1:21 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; Routing
> Directorate <[e-mail]>
> *Subject:* [RTG-DIR]RtgDir Early review:
> draft-ietf-mboned-non-source-routed-sr-mcast-05
>
>
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-mboned-non-source-routed-sr-mcast-05.txt/__;!!NEt6yMaO-gk!Dlv9nAyOZu53WxrWLea8hs_A3NGG6tYEucVqgDYkax2C67cWnZvRcaZxcQSt5efpLr5AHVq4XAE0nT0$>
> 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
> <https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!Dlv9nAyOZu53WxrWLea8hs_A3NGG6tYEucVqgDYkax2C67cWnZvRcaZxcQSt5efpLr5AHVq4gUmAUmg$>
>
> 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
>  [e-mail]
>