Return-Path: X-Original-To: mboned@mail2.ietf.org Delivered-To: mboned@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3094A1088A08C for ; Fri, 26 Jun 2026 18:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782523334; bh=YBLQ8116IwA56eJ3NeH8cxxsBFPYW0Jx/oju3vXfRKU=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=S4+/RVehArZOvZi4NPSt45xkJDA7HgSqcNOEs//IpiFKy2gHnk7CmmgJsRmkxGFra dC/2DtWfBnjb0hYOQWtF4+5ijOaJCmr/SRhTCFxPdYOX5F1S3NaYe/vHti7Crfkm+c kE0wbgHUSZJ9C9Cmfdo/xUjmNZYv9rQPGS3Qxxwo= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V97xRQQYAXku for ; Fri, 26 Jun 2026 18:22:13 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7593210889E8B for ; Fri, 26 Jun 2026 18:20:38 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-51a868b6962so13631961cf.2 for ; Fri, 26 Jun 2026 18:20:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782523232; cv=none; d=google.com; s=arc-20260327; b=hhQ9VuMds0B+kH+SOCi917IXqmvaodzV9CU5E9oCSGMB2iYylsvF3tr7EMegit1g87 kb0jw5J5Gsb/fa4emlAahx2Ha+80PfltsWQyJEK1fcQlkzsXLl0JNtQcfT8XPdg/Dj9s xYlYQrRRhFmfw0oEWbPXjEvTD6lUleH3bp7jLhDl9RrNZn2PcHL2fO3qEdtDUFjhupBN SSCKJavO/xut0yp/xfjivERo78GltqyOLlNY/+fUG0cqfxLrwu0aLGbiealtAzkNiCCh HLwKsspbdY5VKJypsmwYsGHUL7qXdT7JxrLSO7/CshvEzjOpaXncSnsVutyY8KsUCF/7 fQbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=GN7aCyOcsfQh4NGs3s98zHSnQQgUeddTvW4MOVoc2gM=; fh=bxLYT5wATyUS3qOehZ1hqwFiykXpIoEqqZqOiyBQCDk=; b=gB1mUkzel5mjsXWoU/jlCF/MQibaL2ElYz1Ik9OvXXqEtvaJxEUT8ykutkoVE+ZuJc 4cGgwPqtyjXiYrNMb6T3uZR4YrMR+RIvlSOR5nWGexsTD5+By5GdwyWrIzjBxHS+HXia SBSQu46+QoaQazZPSGDfnJYknhQuQtD1+K5zXs7lVEEzu7hwd/Iob4IZwSSsW8dPGUx1 ++4kz0ioPZ65OkTf4kl8HA85Vqy60afDfl8yAsMt3AT3gNT2Yg1Wx8sc0G7QyesSi5R/ 35SGRPJIvEZGhq+y2xzp1NgLjY2G79qE+a9hgsxr0wHJppuHplWhHp1EZUrCT9bTfBZo O9DQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782523232; x=1783128032; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GN7aCyOcsfQh4NGs3s98zHSnQQgUeddTvW4MOVoc2gM=; b=ZR+fbNuhbluTYhva16xj7YOC8CcmN48sCWTbfqPGEB6cZPyeaVIzb9jXztHGjAvlH6 +zC4eUCRXrRVPXqyHvezMGcZFChHXz1HO14GNZnLK1CV5zd9M/pNeensAe2wf/o80InG nhab3GDQzH+UXxTuFYkhqiYrg/Ff8MN4Hv2F0h1qOVo41nMf0puf7WtUC1DZ6cqIsYK4 EKM2My2qiQ2/k9xhLqr60no43b0RQMByx6GktBG0Hz9kwuknTM922m0VZS1SC+VIWg5z piVhMHouCTUe96otO4ZbMjrjGFpmdVWLpe875PP9k84cjaVLFj89kbd7bwRCKcIkii6U HLcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782523232; x=1783128032; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GN7aCyOcsfQh4NGs3s98zHSnQQgUeddTvW4MOVoc2gM=; b=aR3B6avA64Ygszn6zEs16uNf1WHE9JnGuKnfgRQ9evy+v1t/Q7Zwm/KxmQgnane77r AOK1fIpdiE4dDAmy1hzzr2ejy2uTAHP0FEAiU1M+dM1kvQF+krYlGxq70nrCA2PZJfJx nbVtd7WvfRbK5Gw1Dmbg0orRmGOR68G0GtlAPGnkLoX+E0+5sMYJEayUniLkjAOhRXCn 4Y33zU8IXu5FnORNiRB+3ruldjF9Io3FzaxHIFqeNwxg5C6p0i9mkuelL9rDYT8cIEth OK3z00VqBMOpHfCpHwWQy65vbLXjnn6tQhP6Yuy+KUoPstr5JfTfajfBq88qKWFWAB+6 rXYQ== X-Gm-Message-State: AOJu0Yx29h+mzsjxk0dF66wgdB8CVULZ9JsmjTsyTEFWaB0mfadzQ346 2KRVqNBNERCNaKg3IdIBdc9yE+IxIjrQxlx3LX7ne/23O12hNKDIqaxtPD6rnrTf6wDOWCfSDqs N3UHM8vPMVqihBNZnSHOkUTy4Wab5nqU= X-Gm-Gg: AfdE7ck+aOVvi2S/SIzw58C0GimiiyapTe3CIkXS+qnBRrO2tzkNi+D/MCbvsre7aA8 bo3bRRqIxpcArBeBTujvSugA6JJPtim6RizZZQWXerLJ3SLKoq6fNx0Gw3RdbTZTb1bT4PUwnDR pEdFMv2cC2kBBL4yVSqLcsmbkWCJ2mgFrT11A0ATutvhKy60XrgQVdv65NqeWBPzcvjQt/UoHIZ bMPQoB9ghiPQMfjtVP0H5AHdzUvGigvTognR8XrI4sjx25w7VD7h6AGnnP98nX3abAkv8Y= X-Received: by 2002:a05:622a:1c0f:b0:50e:635b:5579 with SMTP id d75a77b69052e-51a726ffb5dmr133056361cf.19.1782523231617; Fri, 26 Jun 2026 18:20:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Fri, 26 Jun 2026 21:20:19 -0400 X-Gm-Features: AVVi8Cc_kr8k-bjUlyx750YgOCb9hkhOADhCTEZgqsEN-IxT5E1qvNJkeXPnNM8 Message-ID: To: "Zhang, Zhaohui (Jeffrey)" Content-Type: multipart/alternative; boundary="0000000000000646b20655320857" Message-ID-Hash: F4F47IBYXBV3YE2PIZSRIM7TPNJ2VE7P X-Message-ID-Hash: F4F47IBYXBV3YE2PIZSRIM7TPNJ2VE7P X-MailFrom: d3e3e3@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mboned.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "mboned@ietf.org" , "draft-ietf-mboned-non-source-routed-sr-mcast.all@ietf.org" , Routing Directorate X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BMBONED=5DRe=3A_=5BRTG-DIR=5DRtgDir_Early_review=3A_draft-ietf-m?= =?utf-8?q?boned-non-source-routed-sr-mcast-05?= List-Id: Mail List for the Mboned Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000000646b20655320857 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeffrey, You changes look OK to me. Thanks, 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 On Fri, Jun 26, 2026 at 5:37=E2=80=AFPM Zhang, Zhaohui (Jeffrey) < zhaohui.zhang@hpe.com> 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=3Ddraft-ietf-mboned-non-source-= routed-sr-mcast-05&url2=3Ddraft-ietf-mboned-non-source-routed-sr-mcast-06&d= ifftype=3D--html > > > > Jeffrey > > > > *From:* Donald Eastlake > *Sent:* Friday, June 19, 2026 1:21 PM > *To:* mboned@ietf.org > *Cc:* draft-ietf-mboned-non-source-routed-sr-mcast.all@ietf.org; Routing > Directorate > *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 =E2=80=9Cearly=E2=80=9D = review of this > draft: > https://datatracker.ietf.org/doc/draft-ietf-mboned-non-source-routed-sr-m= cast-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 submitt= ed 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 catalo= g > 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 reques= ts > 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 treate= d > consistently. For example, RFCs 6826 and 6513 are cited in similar contex= ts > 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 not= e > 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 ou= t > of scope work. Suggest removing it or, if you really want to keep it, mak= e > 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 becaus= e > 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 > --0000000000000646b20655320857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeffrey,

You changes look= OK to me.

Thanks,
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
=C2=A0Donald E. Eastlake 3rd
=C2=A02386 Panoram= ic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Fri, Jun 26, 2026 at 5:37=E2=80=AFPM Zhang, Zhaohui (Jeffrey) &= lt;zhaohui.zhang@hpe.com> w= rote:

Hi Donald,<= /u>

=C2=A0<= /span>

Thank you very much f= or your review and detailed comments/suggestions.

I have posted a new r= evision that addresses the comments.

=C2=A0<= /span>

https://author-tools.ietf.org/iddiff?url1= =3Ddraft-ietf-mboned-non-source-routed-sr-mcast-05&url2=3Ddraft-ietf-mb= oned-non-source-routed-sr-mcast-06&difftype=3D--html<= /span>

=C2=A0<= /span>

Jeffrey=

=C2=A0<= /span>

From: Donald Eastlake <d3e3e3@= gmail.com>
Sent: Friday, June 19, 2026 1:21 PM
To: mboned@ietf= .org
Cc: draft-ietf-mboned-non-source-routed-sr-mcast= .all@ietf.org; Routing Directorate <rtg-dir@ietf.org>
Subject: [RTG-DIR]RtgDir Early review: draft-ietf-mboned-non-source-= routed-sr-mcast-05

=C2=A0

Hi,

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft:=C2=A0https://datatracker.ietf.org/doc/dr= aft-ietf-mboned-non-source-routed-sr-mcast-05.txt/
The routing directorate will, on request from the working group chair, perf= orm 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 resol= ved 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. How= ever, there are a few issues some of which would likely lead to requests fo= r changes later in the process.

Medium Issues:

References: The biggest issue I see is the classification of references int= o Normative and Informational. With a couple of exceptions, it appears that= all the RFC references were declared Normative while all the draft referen= ces were classified Informational. However, since this draft is targeted at Informational, in my opinion, the= re should be few, if any, Normative references. Generally, Normative refere= nces 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 consistentl= y. 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 b= efore 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:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 &= quot;one" do not seem to appear in RFC 8402. Perhaps it should say &qu= ot;a major benefit" or something else. This would probably imply a par= allel change to the wording of the last sentence in the 2nd paragraph, maybe del= eting "principle and". I note that RFC 8402 is careful to say thi= ngs 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 refere= nce. It seems unnecessary, especially since it is with regard to out of sco= pe work. Suggest removing it or, if you really want to keep it, make it a p= roper Informational reference.

Section 3, 1st sentence: "perfect" sounds a bit like marketing. S= uggest replacing this sentence with something like: "BIER was designed= and developed independently of SR, but is a good fit for an SR network bec= ause 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 th= e SR benefit of no per-flow state except at ingress nodes"

Section 8: You might get by with this Security Considerations section. Howe= ver, it would be stronger if a sentence were added noting that the choice a= mong the options described in the draft has security-relevant tradeoffs (fo= r example, controller-based solutions add the controller as a trust point and attack surface; ingress replicatio= n 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"<= br>
Section 6: "labels that leads" -> "labels that lead"=

Section 6: "run PIM protocol" -> "run the PIM protocol&qu= ot;

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
=C2=A0Donald E. Eastlake 3rd
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.co= m

--0000000000000646b20655320857--