Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-bier-te-arch-13> for your review

[Toerless Eckert <[e-mail]>]

I was alredy 30% through it, when i got hit by another IETF thing with deadline
today... There is progress... stay tuned - and thanks for kicking me in the back ;-)

Cheers
    Toerless

On Fri, Aug 19, 2022 at 10:36:23AM -0700, Lynne Bartholomew wrote:
> Dear authors,
> 
> Checking in with you regarding the status of this document.  Please review our questions below in this email thread, and let us know how this document should be updated.
> 
> Please let us know of any issues or concerns that you might have.
> 
> Thank you!
> 
> RFC Editor/lb
> 
> > On Aug 12, 2022, at 10:19 AM, Lynne Bartholomew <[e-mail]> wrote:
> > 
> > Dear authors,
> > 
> > Checking in with you regarding the status of this document.  Please review our questions below in this email thread, and let us know how this document should be updated.
> > 
> > Thank you!
> > 
> > RFC Editor/lb
> > 
> > 
> >> On Aug 5, 2022, at 11:56 AM, Lynne Bartholomew <[e-mail]> wrote:
> >> 
> >> Dear authors,
> >> 
> >> Checking in with you regarding the status of this document.  Please review our questions below in this email thread, and let us know how this document should be updated.
> >> 
> >> The files are posted here:
> >> 
> >>  https://www.rfc-editor.org/authors/rfc9262.txt
> >>  https://www.rfc-editor.org/authors/rfc9262.html
> >>  https://www.rfc-editor.org/authors/rfc9262.pdf
> >>  https://www.rfc-editor.org/authors/rfc9262.xml
> >>  https://www.rfc-editor.org/authors/rfc9262-diff.html
> >>  https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
> >>  https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
> >> 
> >>  https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
> >>  https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
> >> 
> >> Thank you!
> >> 
> >> RFC Editor/lb
> >> 
> >>> On Jul 22, 2022, at 3:13 PM, Lynne Bartholomew <[e-mail]> wrote:
> >>> 
> >>> Hi, Toerless.  Thank you for letting us know, and no worries.  Good point about IETF 114; we will hold off on the reminders until August 5 or so.
> >>> 
> >>> Thanks again for checking in, and we hope that IETF 114 goes well!
> >>> 
> >>> RFC Editor/lb
> >>> 
> >>>> On Jul 22, 2022, at 2:52 PM, Toerless Eckert <[e-mail]> wrote:
> >>>> 
> >>>> 
> >>>> No, sorry for the delay. Unfortunately, there is a lot of stuff
> >>>> to prepare for IETF114, so i will only get to this shortly after
> >>>> IETF114 ;-(
> >>>> 
> >>>> But thank you so much for your work.
> >>>> 
> >>>> Cheers
> >>>> Toerless
> >>>> 
> >>>> On Fri, Jul 22, 2022 at 02:09:10PM -0700, Lynne Bartholomew wrote:
> >>>>> Dear authors,
> >>>>> 
> >>>>> We do not believe that we have heard from you regarding this document's readiness for publication.  Please see the questions below.
> >>>>> 
> >>>>> The latest files are posted here:
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9262.xml
> >>>>> https://www.rfc-editor.org/authors/rfc9262.html
> >>>>> https://www.rfc-editor.org/authors/rfc9262.pdf
> >>>>> https://www.rfc-editor.org/authors/rfc9262.txt
> >>>>> https://www.rfc-editor.org/authors/rfc9262-diff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9262-alt-diff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
> >>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff2.html
> >>>>> 
> >>>>> Thank you!
> >>>>> 
> >>>>> RFC Editor/lb
> >>>>> 
> >>>>>> On Jul 11, 2022, at 6:47 PM, [e-mail] wrote:
> >>>>>> 
> >>>>>> Authors,
> >>>>>> 
> >>>>>> While reviewing this document during AUTH48, please resolve (as necessary) 
> >>>>>> the following questions, which are also in the XML file.
> >>>>>> 
> >>>>>> 1) <!-- [rfced] First-page header:  We do not see multiple initials used
> >>>>>> for the authors of this document in any published RFC or in the draft
> >>>>>> references where the same authors are listed (e.g.,
> >>>>>> draft-eckert-bier-te-frr).  Are the multiple initials intended as a
> >>>>>> precedent for future RFCs?  If not, we suggest using single initials.
> >>>>>> 
> >>>>>> Original:
> >>>>>> T.T.E. Eckert, Ed.
> >>>>>> M.M. Menth
> >>>>>> G.C. Cauchie
> >>>>>> 
> >>>>>> Suggested (per published RFCs and current documents):
> >>>>>> T. Eckert, Ed.
> >>>>>> M. Menth
> >>>>>> G. Cauchie -->
> >>>>>> 
> >>>>>> 
> >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> >>>>>> title) for use on <https://www.rfc-editor.org/search>. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 3) <!-- [rfced] We found a comment called "Removed for now by review
> >>>>>> with Lou Berger" in the original XML file with the section title "BIER-TE and 
> >>>>>> Traffic Engineering (BIER-TE)."  Please confirm that the removal of this section 
> >>>>>> is correct.  (If you need to restore the section, we will do so via the 
> >>>>>> pre-edited draft version.) -->
> >>>>>> 
> >>>>>> 
> >>>>>> 4) <!-- [rfced] Abstract and Section 1:  Because per other RFCs and
> >>>>>> Internet searches "Interior Gateway Routing protocol" usually refers
> >>>>>> to Cisco's IGRP, we looked up definitions of "IGP" and updated these
> >>>>>> sentences accordingly, in an effort to avoid possible confusion for
> >>>>>> some readers.  If these updates do not convey your intended meaning,
> >>>>>> please provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Except for the optional routed adjacencies, BIER-TE does not require
> >>>>>> a BIER routing underlay, and can therefore operate without depending
> >>>>>> on an "Interior Gateway Routing protocol" (IGP).
> >>>>>> ...
> >>>>>> Except for
> >>>>>> the optional routed adjacencies, BIER-TE does not require a BIER
> >>>>>> routing underlay, and can therefore operate without depending on an
> >>>>>> "Interior Gateway Routing protocol" (IGP).
> >>>>>> 
> >>>>>> Currently:
> >>>>>> Except for the optional routed adjacencies,
> >>>>>> BIER-TE does not require a BIER routing underlay and can therefore
> >>>>>> operate without depending on a routing protocol such as the Interior
> >>>>>> Gateway Protocol (IGP).
> >>>>>> ...
> >>>>>> Except for
> >>>>>> the optional routed adjacencies, BIER-TE does not require a BIER
> >>>>>> routing underlay and can therefore operate without depending on a
> >>>>>> routing protocol such as the Interior Gateway Protocol (IGP). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 5) <!-- [rfced] Section 2.1:  We defined "BFIR" as "Bit-Forwarding
> >>>>>> Ingress Router" per RFC 8556 and per the definition of "BFER(s)".
> >>>>>> Please let us know any objections.
> >>>>>> 
> >>>>>> Original:
> >>>>>> All BFRs
> >>>>>> can act as an ingress BFR (BFIR), BFR1, BFR3, BFR4 and BFR6 can also
> >>>>>> be BFERs.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> All
> >>>>>> BFRs can act as a Bit-Forwarding Ingress Router (BFIR); BFR1, BFR3,
> >>>>>> BFR4, and BFR6 can also be BFERs. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 6) <!-- [rfced] Section 2.1:  We found "This is showing the ability of
> >>>>>> the shown BIER-TE Topology" difficult to follow.  We updated this
> >>>>>> sentence as noted below.  Please let us know if this is incorrect.
> >>>>>> 
> >>>>>> Original:
> >>>>>> This is
> >>>>>> showing the ability of the shown BIER-TE Topology to make the traffic
> >>>>>> pass across any possible path and be replicated where desired.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> This
> >>>>>> demonstrates the ability of the BIER-TE Topology, as shown in
> >>>>>> Figure 1, to make the traffic pass across any possible path and be
> >>>>>> replicated where desired. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 7) <!-- [rfced] Section 2.1:  We had trouble with this sentence.
> >>>>>> If the suggested text is not correct, please clarify "non-L2, but
> >>>>>> routed/tunneled forwarding of BIER-TE packets".
> >>>>>> 
> >>>>>> Original:
> >>>>>> To emphasize non-L2, but routed/tunneled forwarding of
> >>>>>> BIER-TE packets, these adjacencies are called "forward_routed".
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> To specify routed/tunneled forwarding of BIER-TE packets
> >>>>>> (i.e., not Layer 2), these adjacencies are called "forward_routed()"
> >>>>>> adjacencies. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 8) <!-- [rfced] Section 2.1:  We had trouble following the "and"
> >>>>>> relationships in these two sentences.  If the suggested text does not
> >>>>>> preserve your intended meaning, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> A
> >>>>>> packet from BFR1 to be received by BFR4, and from BFR4 to be received
> >>>>>> by BFR6 and from there to be received by BFR3 uses
> >>>>>> (p2,p3,p4,p6,p7,p9).  A packet from BFR1 to be received by BFR3, and
> >>>>>> from BFR3 to be received by BFR6 there to be received by BFR4 uses
> >>>>>> (p1,p3,p4,p5,p8,p9).
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> A
> >>>>>> packet from BFR1 to be received by BFR4, then from BFR4 to be
> >>>>>> received by BFR6, and finally from BFR6 to be received by BFR3, uses
> >>>>>> (p2,p3,p4,p6,p7,p9).  A packet from BFR1 to be received by BFR3,
> >>>>>> then from BFR3 to be received by BFR6, and finally from BFR6 to be
> >>>>>> received by BFR4, uses (p1,p3,p4,p5,p8,p9). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 9) <!-- [rfced] Section 2.3:  We had trouble following this sentence.
> >>>>>> If the suggested text is not correct, please clarify "and therefore
> >>>>>> also no unique BFR-id".
> >>>>>> 
> >>>>>> Original:
> >>>>>> 2.  The BIER-TE layer forwarding plane does not require BFRs to
> >>>>>> have a unique BP and therefore also no unique BFR-id.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> 2.  The BIER-TE layer forwarding plane does not require BFRs to
> >>>>>> have a unique BP; therefore, a unique BFR-id is not needed
> >>>>>> either. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 10) <!-- [rfced] Section 3.1:  We had trouble following the use of "may
> >>>>>> also be preferred to" in this sentence.  If the suggested text is not
> >>>>>> correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> When a BIER-TE controller is used, then the signaling for the
> >>>>>> Multicast Flow Overlay may also be preferred to operate through a
> >>>>>> central point of control.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> When a BIER-TE controller is used, it might also be preferable that
> >>>>>> Multicast Flow Overlay signaling be performed through a central
> >>>>>> point of control. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 11) <!-- [rfced] Section 3.2:  We could not follow this sentence.  If the
> >>>>>> suggested text is not correct, please clarify "but instead their
> >>>>>> functions are summarized together in Section 4.2" (i.e., what do
> >>>>>> "instead", "their", and "summarized together" refer to?).
> >>>>>> 
> >>>>>> Original:
> >>>>>> In the (non-TE) BIER architecture [RFC8279], the BIER control plane
> >>>>>> is not explicitly separated from the BIER forwarding plane, but
> >>>>>> instead their functions are summarized together in Section 4.2.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> In the (non-TE) BIER architecture [RFC8279], the BIER control plane
> >>>>>> is not explicitly separated from the BIER forwarding plane.  See
> >>>>>> Section 4.2 for a description of relevant functions. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 12) <!-- [rfced] Section 3.2:  We changed "for a BIER-TE sub-domains" to
> >>>>>> "for BIER-TE subdomains" in this sentence.  Please let us know if it
> >>>>>> should be "for a BIER-TE subdomain" instead.
> >>>>>> 
> >>>>>> Original:
> >>>>>> 1.  Determine the desired BIER-TE topology for a BIER-TE sub-
> >>>>>> domains: the native and/or overlay adjacencies that are
> >>>>>> assigned to BPs.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> 1.  Determine the desired BIER-TE topology for BIER-TE subdomains:
> >>>>>> the native and/or overlay adjacencies that are assigned to
> >>>>>> BPs. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 13) <!-- [rfced] Section 3.2:  We do not see entropy/Entropy mentioned in
> >>>>>> any of the cited sections.  Please confirm that these citations are
> >>>>>> correct and will be clear to readers.
> >>>>>> 
> >>>>>> Original:
> >>>>>> 2.  Determine the BitStrings and optionally Entropy.  This is
> >>>>>> discussed in Section 3.2.1.2, Section 3.5 and Section 5.3.4. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 14) <!-- [rfced] Section 3.2:  To what does "the main responsibility"
> >>>>>> refer?  If the suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Different aspects
> >>>>>> of this and the next point are discussed throughout
> >>>>>> Section 3.2.1 and in Section 4.3, but the main responsibility
> >>>>>> of these two points is with the Multicast Flow Overlay
> >>>>>> (Section 3.1), which is architecturally inherited from BIER.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> Different aspects
> >>>>>> of this point, as well as the next point, are discussed
> >>>>>> throughout Section 3.2.1 and in Section 4.3, but the main
> >>>>>> purpose of these two points relates to the Multicast Flow
> >>>>>> Overlay (Section 3.1), which is architecturally inherited from
> >>>>>> BIER. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 15) <!-- [rfced] Regarding this note from you:
> >>>>>> 
> >>>>>> [RFC-Editor: the following text has three references to anchors 
> >>>>>> topology-control, topology-control-1 and tree-control. Unfortunately, 
> >>>>>> XMLv2 does not offer any tagging that reasonable references are generated
> >>>>>> (i had this problem already in RFCs last year. Please make sure there 
> >>>>>> are useful-to-read cross-references in the RFC in these three places 
> >>>>>> after you convert to XMLv3.]
> >>>>>> 
> >>>>>> With v3, it appears to us that the "topology-control" and
> >>>>>> "tree-control" tags, whose anchors are embedded in "top-level"
> >>>>>> "<dd>" elements, are working properly in the .html and .pdf
> >>>>>> outputs.  However, the "topology-control-1" link, whose anchor was
> >>>>>> embedded in a nested "<li>" element, was translated in the text of
> >>>>>> Section 3.2.1.1 by v3 (as it was in the submitted v2 copy) as
> >>>>>> "(Section 3.2, Paragraph 3, Item 2.2.1)", which was inaccurate given
> >>>>>> that the list is only two levels deep.
> >>>>>> 
> >>>>>> We applied 'format="none"' to the "topology-control-1" xref as
> >>>>>> follows:  <xref target="topology-control-1" format="none">.  We also
> >>>>>> included a pointer to Section 3.2, as noted below.  Please check the
> >>>>>> updated links in the .html and .pdf outputs, and let us know any
> >>>>>> concerns.
> >>>>>> 
> >>>>>> Original:
> >>>>>> The first item of BIER-TE topology control (Section 3.2, Paragraph 3,
> >>>>>> Item 2.2.1) includes network topology discovery and BIER-TE topology
> >>>>>> creation.
> >>>>>> 
> >>>>>> Currently (two links, the first more specific than the second):
> >>>>>> The first item listed for BIER-TE topology control (Section 3.2)
> >>>>>> includes network topology discovery and BIER-TE topology creation. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 16) <!-- [rfced] Section 3.2.1.1:  We had trouble determining what is
> >>>>>> listed in this sentence and how they relate to each other.  If the
> >>>>>> suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> In other networks, topology discovery may rely on protocols including
> >>>>>> extending a "Link-State-Protocol" based IGP into the BIER-TE
> >>>>>> controller itself, [RFC7752] (BGP-LS) or [RFC8345] (YANG topology) as
> >>>>>> well as BIER-TE specific methods, for example via
> >>>>>> [I-D.ietf-bier-te-yang].
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> In other networks, topology discovery may rely on such protocols as
> >>>>>> those that include extending an IGP based on a link-state protocol
> >>>>>> into the BIER-TE controller itself, e.g., BGP-LS [RFC7752] or YANG
> >>>>>> topology [RFC8345], as well as methods specific to BIER-TE - for
> >>>>>> example, via [BIER-TE-YANG]. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 17) <!-- [rfced] Section 3.2.1.1:  Should "BitPositions/adjacencies" be
> >>>>>> "BPs/adjacencies", and should "SI:BitPositions" be "SIs:BPs"?
> >>>>>> The only other instances of the form "BitPosition" that we see are
> >>>>>> "GetFirstBitPosition" and "GetNextBitPosition" in the figures in
> >>>>>> Section 4.4.
> >>>>>> 
> >>>>>> Original:
> >>>>>> When the BIER-TE topology is determined, the BIER-TE Controller then
> >>>>>> pushes the BitPositions/adjacencies to the BIFT of the BFRs.  On each
> >>>>>> BFR only those SI:BitPositions are populated that are adjacencies to
> >>>>>> other BFRs in the BIER-TE topology. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 18) <!-- [rfced] Section 3.2.1.1:  For ease of the reader, we defined
> >>>>>> "SDN" as "Software-Defined Network" per RFC 8279.  If this is
> >>>>>> incorrect, please provide the correct definition.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Vendor-specific CLI on the BFRs is also an option (as in many
> >>>>>> other SDN solutions lacking definition of standardized data models).
> >>>>>> 
> >>>>>> Currently:
> >>>>>> A vendor-specific CLI on the BFRs is also an option (as in
> >>>>>> many other Software-Defined Network (SDN) solutions lacking
> >>>>>> definitions of standardized data models). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 19) <!-- [rfced] Section 3.2.1.2:  Does "such as shortest path trees, ..."
> >>>>>> refer to the policy reasons or the different overlay flows?  If the
> >>>>>> suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Likewise, the BitString from
> >>>>>> the same BFIR to the same set of BFER can be different for different
> >>>>>> overlay flows for policy reasons such as shortest path trees, Steiner
> >>>>>> trees (minimum cost trees), diverse path trees for redundancy and so
> >>>>>> on.
> >>>>>> 
> >>>>>> Suggested (assuming that the different overlay flows apply here):
> >>>>>> Likewise, for policy reasons, the BitString from
> >>>>>> the same BFIR to the same set of BFERs can be different for such
> >>>>>> different overlay flows as shortest path trees, Steiner trees
> >>>>>> (minimum-cost trees), diverse path trees for redundancy, and so on. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 20) <!-- [rfced] Section 3.2.1.2:  We do not see the word "tree" used in
> >>>>>> [I-D.ietf-bier-multicast-http-response].  Please confirm that this
> >>>>>> citation is correct and will be clear to readers.
> >>>>>> 
> >>>>>> Original:
> >>>>>> See also [I-D.ietf-bier-multicast-http-response] for an application
> >>>>>> leveraging BIER-TE engineered trees. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 21) <!-- [rfced] Section 3.2.1.4:  For ease of the reader, we expanded
> >>>>>> "FRR" as "Fast Reroute".  Please let us know any objections.
> >>>>>> 
> >>>>>> Original:
> >>>>>> When link or nodes fail or recover in the topology, BIER-TE could
> >>>>>> quickly respond with FRR procedures such as [I-D.eckert-bier-te-frr],
> >>>>>> the details of which are out of scope for this document.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> When links or nodes fail or recover in the topology, BIER-TE could
> >>>>>> quickly respond with Fast Reroute (FRR) procedures such as those
> >>>>>> described in [BIER-TE-PROTECTION], the details of which are out of
> >>>>>> scope for this document. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 22) <!-- [rfced] Section 3.3:  Because the "or" in "and/or" would mean
> >>>>>> that there would not be a combination, we updated this sentence as
> >>>>>> follows.  If this update does not properly convey your intended
> >>>>>> meaning, please provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> This is driven by a combination of state established by
> >>>>>> the BIER-TE control plane and/or the multicast flow overlay as
> >>>>>> explained in Section 3.1.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> This is driven by state established by the BIER-TE
> >>>>>> control plane, the multicast flow overlay as explained in
> >>>>>> Section 3.1, or a combination of both. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 23) <!-- [rfced] Section 3.3:  For ease of the reader, we defined "DSCP"
> >>>>>> as "Differentiated Services Code Point".  If this is incorrect,
> >>>>>> please provide the correct definition.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Processing of other BIER header fields such as DSCP
> >>>>>> is outside the scope of this document.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> Processing of other BIER header fields, such as the
> >>>>>> Differentiated Services Code Point (DSCP) field, is outside the
> >>>>>> scope of this document. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 24) <!-- [rfced] Section 3.4:  Does "This" mean "This process", "This
> >>>>>> calculation", or something else?  Please clarify.
> >>>>>> 
> >>>>>> Original (the previous sentence is included for context):
> >>>>>> BIER relies on the routing underlay to calculate paths towards BFERs
> >>>>>> and derive next-hop BFR adjacencies for those paths.  This commonly
> >>>>>> relies on BIER specific extensions to the routing protocols of the
> >>>>>> routing underlay but may also be established by a controller. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 25) <!-- [rfced] Section 3.4:  For ease of the reader, we expanded "BFD"
> >>>>>> as "Bidirectional Forwarding Detection".  If this is incorrect,
> >>>>>> please provide the correct definition.
> >>>>>> 
> >>>>>> Original:
> >>>>>> If the BFR intends to support FRR for BIER-TE, then the BIER-TE
> >>>>>> forwarding plane needs to receive fast adjacency up/down
> >>>>>> notifications: Link up/down or neighbor up/down, e.g. from BFD.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> If the BFR intends to support FRR for BIER-TE, then the BIER-TE
> >>>>>> forwarding plane needs to receive fast adjacency up/down
> >>>>>> notifications: link up/down or neighbor up/down, e.g., from
> >>>>>> Bidirectional Forwarding Detection (BFD). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 26) <!-- [rfced] Section 3.5:  Please confirm that "TE" stands for
> >>>>>> "Traffic Engineering" and not "Tree Engineering" here.  We would
> >>>>>> like to spell it out as appropriate, because the standalone term
> >>>>>> "TE" is not used anywhere else in this document.
> >>>>>> 
> >>>>>> Original (the previous sentence is included for context):
> >>>>>> Traffic Engineering ([I-D.ietf-teas-rfc3272bis]) provides performance
> >>>>>> optimization of operational IP networks while utilizing network
> >>>>>> resources economically and reliably.  The key elements needed to
> >>>>>> effect TE are policy, path steering and resource management.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> The key elements needed to effect Traffic Engineering are
> >>>>>> policy, path steering, and resource management. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 27) <!-- [rfced] Section 3.5:  Because Section 4.2.1 discusses
> >>>>>> forward_connected() adjacencies and Section 4.2.2 discusses
> >>>>>> forward_routed() adjacencies, we changed "4.2.1" to "4.2.2" here.
> >>>>>> Please let us know any concerns (e.g., should the instances of
> >>>>>> "forward_routed()" be "forward_connected()" here?).
> >>>>>> 
> >>>>>> Original:
> >>>>>> The resource usage of the BIER-TE traffic
> >>>>>> admitted by the BIER-TE controller can be solely tracked on the BIER-
> >>>>>> TE Controller based on local accounting as long as no
> >>>>>> forward_routed() adjacencies are used (see Section 4.2.1 for the
> >>>>>> definition of forward_routed() adjacencies).
> >>>>>> 
> >>>>>> Currently:
> >>>>>> The resource usage of the BIER-TE traffic
> >>>>>> admitted by the BIER-TE controller can be solely tracked on the BIER-
> >>>>>> TE Controller based on local accounting as long as no
> >>>>>> forward_routed() adjacencies are used (see Section 4.2.2 for the
> >>>>>> definition of forward_routed() adjacencies). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 28) <!-- [rfced] Section 4.1:  This sentence reads oddly, as a BIFT is
> >>>>>> already defined as being a table.  May we update as suggested?
> >>>>>> If not, please clarify "it is a table as shown".
> >>>>>> 
> >>>>>> Original (the previous two sentences are included for context;
> >>>>>> "shown shown" has been corrected):
> >>>>>> The BIER-TE BIFT is the equivalent to the BIER BIFT for (non-TE)
> >>>>>> BIER.  It exists on every BFR running BIER-TE.  For every BIER sub-
> >>>>>> domain (SD) in use for BIER-TE, it is a table as shown shown in
> >>>>>> Figure 4.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> For every BIER subdomain (SD) in use
> >>>>>> for BIER-TE, the BIFT would be constructed per the example shown in
> >>>>>> Figure 4. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 29) <!-- [rfced] Section 4.1:  Does "those adjacencies forwarding
> >>>>>> entries" mean "those adjacencies that forward entries", "those
> >>>>>> adjacencies' forwarding entries", or something else?
> >>>>>> 
> >>>>>> Original:
> >>>>>> In BIER-TE, each BIFT-index and therefore SI:BP indicates one or more
> >>>>>> adjacencies between BFRs in the topology and is only populated with
> >>>>>> those adjacencies forwarding entries on the BFR that is the upstream
> >>>>>> for these adjacencies. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 30) <!-- [rfced] We incorporated the "BIER-TE Bit Index Forwarding Table
> >>>>>> (BIFT)" text that appeared at the bottom of Figure 4 into the
> >>>>>> figure's title, as it appears to say the same thing as the original
> >>>>>> figure title (but provides the expansion for "BIFT").  Please let us
> >>>>>> know any objections.
> >>>>>> 
> >>>>>> Original:
> >>>>>> ...
> >>>>>>  BIER-TE Bit Index Forwarding Table (BIFT)
> >>>>>> 
> >>>>>> Figure 4: BIER-TE BIFT with different adjacencies
> >>>>>> 
> >>>>>> Currently:
> >>>>>> ...
> >>>>>> Figure 4: BIER-TE Bit Index Forwarding Table (BIFT) with
> >>>>>>              Different Adjacencies -->
> >>>>>> 
> >>>>>> 
> >>>>>> 31) <!-- [rfced] Section 4.1:  Please clarify the meaning of "the BIER-TE
> >>>>>> Forwarding Procedures".  Are they found elsewhere in this document
> >>>>>> or perhaps in another RFC?  Please specify the section number or RFC,
> >>>>>> as applicable.
> >>>>>> 
> >>>>>> Original:
> >>>>>> The BIFT is then used to forward packets, according to the rules
> >>>>>> specified in the BIER-TE Forwarding Procedures. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 32) <!-- [rfced] Section 4.1:  We do not see "controller" mentioned in
> >>>>>> Section 5.1.6.  Please confirm that this citation is correct and will
> >>>>>> be clear to readers.
> >>>>>> 
> >>>>>> Original:
> >>>>>> See Section 5.1.6 for an example of how a
> >>>>>> BIER-TE controller could assign BPs to (logical) adjacencies shared
> >>>>>> across multiple BFRs, Section 5.1.3 for an example of assigning the
> >>>>>> same BP to different adjacencies, and Section 5.1.9 for general
> >>>>>> guidelines regarding re-use of BPs across different adjacencies. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 33) <!-- [rfced] Section 4.2.2:  We had trouble with the usage of
> >>>>>> "either" and determining what "or by" refers to in this sentence.
> >>>>>> If the suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> This identification can either rely on the BIER/BIER-TE co-
> >>>>>> existence mechanisms described in Section 4.3, or by explicit support
> >>>>>> for a BIER-TE payload type in the tunneling encapsulation.
> >>>>>> 
> >>>>>> Suggested (assuming that this identification relies on either
> >>>>>> the mechanisms or explicit support):
> >>>>>> This identification can rely on either the BIER/BIER-TE co-
> >>>>>> existence mechanisms described in Section 4.3 or explicit support
> >>>>>> for a BIER-TE payload type in the tunneling encapsulation. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 34) <!-- [rfced] Section 4.3:  We found the wording of this sentence
> >>>>>> confusing, as it prompted us to search RFC 8279 for "maximum" and
> >>>>>> "MTU" (only to find that it doesn't mention either term).  May we
> >>>>>> rephrase as suggested?  If not, please provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Like [RFC8279], handling of "Maximum Transmission Unit" (MTU)
> >>>>>> limitations is outside the scope of this document and instead part of
> >>>>>> the BIER-TE packet encapsulation and/or flow overlay.  See for
> >>>>>> example [RFC8296], Section 3.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> The handling of Maximum Transmission Unit (MTU) limitations is
> >>>>>> outside the scope of this document and is not discussed in
> >>>>>> [RFC8279].  Instead, this process is part of the BIER-TE packet
> >>>>>> encapsulation and/or flow overlay; for example, see [RFC8296],
> >>>>>> Section 3. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 35) <!-- [rfced] Section 4.3:  This paragraph is difficult to follow.
> >>>>>> Does "which" mean that the fixed mapping never explicitly partitions
> >>>>>> the BIFT-id space, or can the fixed mapping sometimes explicitly
> >>>>>> partition the BIFT-id space, in which case "which" should be "that"?
> >>>>>> Does "same or different SD" mean "same SD or a different SD",
> >>>>>> "same SD or different SDs", or something else?
> >>>>>> 
> >>>>>> If the suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> When a fixed mapping from BSL, SD and SI to BIFT-id is used which
> >>>>>> does not explicitly partition the BIFT-id space between BIER and
> >>>>>> BIER-TE, such as proposed for non-MPLS forwarding with [RFC8296]
> >>>>>> encapsulation in [I-D.ietf-bier-non-mpls-bift-encoding] revision 04,
> >>>>>> section 5, then it is necessary to allocate disjoint SDs to BIER and
> >>>>>> BIER-TE BIFTs so that both can be addressed by the BIFT-ids.  The
> >>>>>> encoding proposed in section 6. of the same document does not
> >>>>>> statically encode BSL or SD into the BIFT-id, but allows for a
> >>>>>> mapping, and hence could provide for the same freedom as when MPLS is
> >>>>>> being used (same or different SD for BIER/BIER-TE).
> >>>>>> 
> >>>>>> Suggested (assuming that the fixed mapping never explicitly
> >>>>>> partitions the BIFT-id space; also assuming "different SDs"):
> >>>>>> When a fixed mapping from BSL, SD, and SI to a BIFT-id is used,
> >>>>>> which does not explicitly partition the BIFT-id space between BIER
> >>>>>> and BIER-TE - for example, as proposed for non-MPLS forwarding with
> >>>>>> BIER encapsulation [RFC8296] in [NON-MPLS-BIER-ENCODING], Section 5
> >>>>>> - it is necessary to allocate disjoint SDs to BIER and BIER-TE BIFTs
> >>>>>> so that both can be addressed by the BIFT-ids.  The encoding
> >>>>>> proposed in Section 6 of [NON-MPLS-BIER-ENCODING] does not
> >>>>>> statically encode the BSL or SD into the BIFT-id, but the encoding
> >>>>>> permits a mapping and hence could provide the same freedom as when
> >>>>>> MPLS is being used (the same SD, or different SDs for BIER/BIER-TE). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 36) <!-- [rfced] Section 4.4:  Because Figures 4 and 5 are referred to as
> >>>>>> "pseudocode", we changed "<artwork>" in the XML file to <sourcecode>
> >>>>>> with type="pseudocode".  Please let us know any concerns.  For
> >>>>>> information regarding <sourcecode> types, please see
> >>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 37) <!-- [rfced] Section 4.4:  We had trouble following this sentence.
> >>>>>> If the suggested text is not correct, please clarify the meaning of
> >>>>>> "to create duplicates".
> >>>>>> 
> >>>>>> Original:
> >>>>>> This protects against BIER replication on any
> >>>>>> possible further BFR to create duplicates ([2]).
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> This prevents BIER's replication logic from creating duplicates on
> >>>>>> any possible further BFRs ([2]). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 38) <!-- [rfced] Section 4.4:  This sentence does not parse.  If the
> >>>>>> suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> This Forwarding Pseudocode can support the required BIER-TE
> >>>>>> forwarding functions (see Section 4.5), forward_connected(),
> >>>>>> forward_routed() and local_decap(), but not the recommended functions
> >>>>>> DNC flag and multiple adjacencies per bit nor the optional function,
> >>>>>> ECMP() adjacencies.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> This Forwarding Pseudocode can support the required BIER-TE
> >>>>>> forwarding functions (see Section 4.5) - forward_connected(),
> >>>>>> forward_routed(), and local_decap() - but cannot support the
> >>>>>> recommended functions (DNC flag and multiple adjacencies per bit)
> >>>>>> or the optional function (i.e., ECMP() adjacencies). -->
> >>>>>> 
> >>>>>> 
> >>>>>> 39) <!-- [rfced] Section 4.4:  xml2rfc v3 now permits subscripting and
> >>>>>> superscripting.  Would you like to use superscripting in "BSL^2*SI"?
> >>>>>> If yes, should "2*SI" be superscripted, or only the "2"?
> >>>>>> 
> >>>>>> (For an example of superscripting in a recent RFC, see the
> >>>>>> "Implementation Note" paragraph in Appendix A of RFC 9260
> >>>>>> (https://www.rfc-editor.org/rfc/rfc9260.html).
> >>>>>> 
> >>>>>> Original:
> >>>>>> *  This pseudocode eliminates per-bit F-BM, therefore reducing the
> >>>>>> size of BIFT state by BSL^2*SI and eliminating the need for per-
> >>>>>> packet-copy BitString masking operations except for adjacencies
> >>>>>> with the DNC flag set: -->
> >>>>>> 
> >>>>>> 
> >>>>>> 40) <!-- [rfced] Section 4.5:  We changed "forwarded_routed" to
> >>>>>> "forward_routed()", as this was the only instance of "forwarded"
> >>>>>> in this document that was followed by an underscore.  Please let us
> >>>>>> know if this is incorrect (i.e., should all instances of "forward_"
> >>>>>> be "forwarded_"?).
> >>>>>> 
> >>>>>> Original:
> >>>>>> This is an
> >>>>>> optional requirement, because for ECMP deployments using BIER-TE one
> >>>>>> can also leverage ECMP of the routing underlay via forwarded_routed
> >>>>>> adjacencies and/or might prefer to have more explicit control of the
> >>>>>> path chosen via explicit BP/adjacencies for each ECMP path
> >>>>>> alternative.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> This is an
> >>>>>> optional requirement, because for ECMP deployments using BIER-TE one
> >>>>>> can also leverage the routing underlay ECMP via forward_routed()
> >>>>>> adjacencies and/or might prefer to have more explicit control of the
> >>>>>> path chosen via explicit BPs/adjacencies for each ECMP path
> >>>>>> alternative. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 41) <!-- [rfced] Section 5.1.1:  Does "P2P" stand for "peer-to-peer" or
> >>>>>> "point-to-point" in this document?  We would like to define it for
> >>>>>> ease of the reader.
> >>>>>> 
> >>>>>> Original:
> >>>>>> On a P2P link that connects two BFRs, the same bit position can be
> >>>>>> used on both BFRs for the adjacency to the neighboring BFR. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 42) <!-- [rfced] Section 5.1.4:  Should the vertical line for p3 in
> >>>>>> Figure 8 be aligned under a "+" sign, as are the other vertical
> >>>>>> lines)?
> >>>>>> 
> >>>>>> Original (best viewed with a fixed-point font such as Courier;
> >>>>>> dashed lines are broken so that they will not be confused with a
> >>>>>> comment):
> >>>>>>      BFR1
> >>>>>>       |p1
> >>>>>> LAN1-+-+- -+- - -+
> >>>>>>    p3|  p4|   p2|
> >>>>>>    BFR3 BFR4  BFR7
> >>>>>> 
> >>>>>> Figure 8: LAN Example
> >>>>>> 
> >>>>>> Perhaps:
> >>>>>>      BFR1
> >>>>>>       |p1
> >>>>>> LAN1-+-+- -+- - -+
> >>>>>>   p3|   p4|   p2|
> >>>>>>   BFR3  BFR4  BFR7
> >>>>>> 
> >>>>>> Figure 8: LAN Example
> >>>>>> 
> >>>>>> Or possibly:
> >>>>>>      BFR1
> >>>>>>       |p1
> >>>>>> LAN1-+-+- - -+- - -+
> >>>>>>     p3|   p4|   p2|
> >>>>>>     BFR3  BFR4  BFR7
> >>>>>> 
> >>>>>> Figure 8: LAN Example -->
> >>>>>> 
> >>>>>> 
> >>>>>> 43) <!-- [rfced] Section 5.1.4:  Please clarify the meaning of
> >>>>>> "Adjacencies of such BFRs into their LAN".  Does it mean "Adding
> >>>>>> adjacencies of such BFRs to these LANs" or something else?
> >>>>>> 
> >>>>>> Original:
> >>>>>> Adjacencies of such BFRs into their LAN still need a
> >>>>>> separate bit position. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 44) <!-- [rfced] We have removed "(SA)" as SA is not used elsewhere in the 
> >>>>>> text.  Please let us know any objections. 
> >>>>>> 
> >>>>>> Original:
> >>>>>> This type of optimized BP could be used for example when all traffic
> >>>>>> is "broadcast" traffic (very dense receiver set) such as live-TV or
> >>>>>> many-to-many telemetry including situation-awareness (SA).
> >>>>>> -->
> >>>>>> 
> >>>>>> 
> >>>>>> 45) <!-- [rfced] Section 5.1.6:
> >>>>>> 
> >>>>>> a) As all other mentions of "ring" related to Figure 9 are singular,
> >>>>>> we changed "the rings shown in Figure 9" to "the ring shown in
> >>>>>> Figure 9".  Note:  If this update is incorrect, please review all
> >>>>>> instances of the singular "ring" in this section, and let us know if
> >>>>>> they should be changed to "rings" (e.g., "entering the ring", "any
> >>>>>> BFR in the ring").
> >>>>>> 
> >>>>>> b) To what text does the colon after "to BFR1" refer - the next
> >>>>>> paragraph or the next two paragraphs (in which case we should indent
> >>>>>> the text in question)?  If neither, may we change the colon to a
> >>>>>> period?
> >>>>>> 
> >>>>>> Original:
> >>>>>> For the rings shown in Figure 9, a single bit position will suffice
> >>>>>> to forward traffic entering the ring at BFRa or BFRb all the way up
> >>>>>> to BFR1:
> >>>>>> 
> >>>>>> Currently:
> >>>>>> For the ring shown in Figure 9, a single bit position will suffice to
> >>>>>> forward traffic entering the ring at BFRa or BFRb all the way up to
> >>>>>> BFR1: -->
> >>>>>> 
> >>>>>> 
> >>>>>> 46) <!-- [rfced] Section 5.1.7:  Regarding this question from you:
> >>>>>> [RFC-Editor: A reviewer (Lars Eggert) noted that the infinite "to use" 
> >>>>>> in the following sentence is not correct. The same was also noted for 
> >>>>>> several other similar instances. The following URL seems to indicate 
> >>>>>> though that this is a per-case decision, which seems undefined: https://writingcenter.gmu.edu/guides/choosing-between-infinitive-and-gerund-to-do-or-doing. What exactly should be done about this ?].
> >>>>>> 
> >>>>>> Thank you for asking this question.  We reviewed all such instances
> >>>>>> in this document and updated the text where needed.  Please review,
> >>>>>> and let us know any concerns regarding our updates. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 47) <!-- [rfced] Section 5.1.9:  To which paragraph or paragraphs does
> >>>>>> the colon in "useful path choices:" refer?  Should the paragraph or
> >>>>>> paragraphs be indented?  If so, which paragraph(s)?  Alternatively,
> >>>>>> may we change the colon to a period?
> >>>>>> 
> >>>>>> Original:
> >>>>>> Packets with both BP 0:5 and BP
> >>>>>> 0:6 would now be able to reach both BFR2 and BFR3 and the still
> >>>>>> existing re-use of BP 0:7 between BFR2 and BFR3 is a case of (B)
> >>>>>> where reuse of BP is perfect because it does not limit the set of
> >>>>>> useful path choices: -->
> >>>>>> 
> >>>>>> 
> >>>>>> 48) <!-- [rfced] Section 5.1.9:  Does "5 areas" refer to areas 2...6, or
> >>>>>> should it be "six areas"?  Also, please confirm that "through other
> >>>>>> BPs for the Core to" should not be "through other BPs from the core
> >>>>>> to".
> >>>>>> 
> >>>>>> Original:
> >>>>>> These two BPs could be reused across the 5
> >>>>>> areas.  Packets would be replicated through other BPs for the Core to
> >>>>>> the desired subset of areas, and once a packet copy reaches the ring
> >>>>>> of the area, the two ring BPs come into play. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 49) <!-- [rfced] Section 5.1.10:  We had trouble following this sentence.
> >>>>>> We updated it as follows.  If this is incorrect, please clarify
> >>>>>> "subnet adjacent neighbor".
> >>>>>> 
> >>>>>> Original:
> >>>>>> Without any optimization, a BIER-TE Controller would attempt to map
> >>>>>> the network subnet topology 1:1 into the BIER-TE topology and every
> >>>>>> subnet adjacent neighbor requires a forward_connected() BP and every
> >>>>>> BFER requires a local_decap() BP.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> Without any optimization, a BIER-TE Controller would attempt to map
> >>>>>> the network subnet topology 1:1 into the BIER-TE topology, every
> >>>>>> adjacent neighbor in the subnet would require a forward_connected()
> >>>>>> BP, and every BFER would require a local_decap() BP. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 50) <!-- [rfced] Section 5.3.1:  We had trouble following "packets that
> >>>>>> need to be sent ... require different BIER packets" in this sentence.
> >>>>>> Is it correct to say that packets require packets?  If not, please
> >>>>>> (1) let us know if the suggested text preserves your intended
> >>>>>> meaning or (2) provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> For (non-TE) BIER and BIER-TE forwarding, the most important result
> >>>>>> of using multiple SI and/or sub-domains is the same: Packets that
> >>>>>> need to be sent to BFERs in different SIs or sub-domains require
> >>>>>> different BIER packets: each one with a BitString for a different
> >>>>>> (SI,sub-domain) combination.
> >>>>>> 
> >>>>>> Suggested (guessing that the packets must be sent as distinct BIER
> >>>>>> packets):
> >>>>>> For (non-TE) BIER and BIER-TE forwarding, the most important result
> >>>>>> of using multiple SIs and/or subdomains is the same: packets that
> >>>>>> need to be sent to BFERs in different SIs or subdomains must be sent
> >>>>>> as distinct BIER packets, each one with a BitString for a different
> >>>>>> (SI,subdomain) combination. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 51) <!-- [rfced] Section 5.3.1:  "BIER architecture shared by BIER-TE"
> >>>>>> did not seem to be quite the correct wording here.  We updated this
> >>>>>> sentence as follows.  If this update is incorrect, please provide
> >>>>>> clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> For BIER and BIER-TE forwarding themselves there is also no
> >>>>>> difference whether different SIs and/or sub-domains are chosen, but
> >>>>>> SI and sub-domain have different purposes in the BIER architecture
> >>>>>> shared by BIER-TE.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> For BIER and BIER-TE forwarding, it doesn't matter whether or not
> >>>>>> different SIs and/or subdomains are chosen, but SIs and subdomains
> >>>>>> have different purposes in the BIER architecture in cases where it
> >>>>>> also applies to BIER-TE. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 52) <!-- [rfced] Section 5.3.2:  We found this paragraph difficult to
> >>>>>> follow.  We updated it as noted below.  Please review carefully.  If
> >>>>>> anything is incorrect, please provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> "Desired" topology because it depends on the physical topology, and
> >>>>>> on the desire of the operator to allow for explicit path steering
> >>>>>> across every single hop (which requires more bits), or reducing the
> >>>>>> number of required bits by exploiting optimizations such as unicast
> >>>>>> (forward_routed()), ECMP() or flood (DNC) over "uninteresting" sub-
> >>>>>> parts of the topology - e.g. parts where different trees do not need
> >>>>>> to take different paths due to path steering reasons.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> "Desired" topology means that it depends on the physical topology and
> >>>>>> the operator's desire to
> >>>>>> 
> >>>>>> *  permit explicit path steering across every single hop (which
> >>>>>> requires more bits), or
> >>>>>> 
> >>>>>> *  reduce the number of required bits by exploiting optimizations
> >>>>>> such as unicast (forward_routed()), ECMP(), or flood (DNC) over
> >>>>>> "uninteresting" sub-parts of the topology, e.g., parts where, for
> >>>>>> path steering reasons, different trees do not need to take
> >>>>>> different paths. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 53) <!-- [rfced] Section 5.3.4:  It appears to us that "it needs" refers
> >>>>>> to the flow overlay applications, in which case it should be "they
> >>>>>> need".  May we update as suggested?  If not, please clarify what "it"
> >>>>>> refers to.
> >>>>>> 
> >>>>>> Original (the previous sentence is included for context.  "BIFR"
> >>>>>> has been corrected):
> >>>>>> The flow overlay on the BIFR can
> >>>>>> then independently of the controller calculate the SI:BitString for
> >>>>>> all desired BFERs by OR'ing their BitStrings.  This allows for flow
> >>>>>> overlay applications to operate independently of the controller
> >>>>>> whenever it needs to determine which subset of BFERs need to receive
> >>>>>> a particular packet.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> This allows flow
> >>>>>> overlay applications to operate independently of the controller
> >>>>>> whenever they need to determine which subset of BFERs needs to receive
> >>>>>> a particular packet. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 54) <!-- [rfced] Section 5.3.5:  Does "their" in this sentence refer to
> >>>>>> subdomains, BIER and BIER-TE, or something else?  If the suggested
> >>>>>> text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original (the previous sentence is included for context):
> >>>>>> A.  BIER and BIER-TE have different BFR-id in the same sub-domain.
> >>>>>> This allows higher replication efficiency for BIER because their BFR-
> >>>>>> id can be assigned sequentially, while the BitStrings for BIER-TE
> >>>>>> will have also the additional bits for the topology.
> >>>>>> 
> >>>>>> Suggested (assuming that "their" means "BIER and BIER-TE BFR-ids"):
> >>>>>> A.  BIER and BIER-TE have different BFR-ids in the same subdomain.
> >>>>>> This allows higher replication efficiency for BIER because the
> >>>>>> BIER and BIER-TE BFR-ids can be assigned sequentially, while the
> >>>>>> BitStrings for BIER-TE will also have the additional bits for
> >>>>>> the topology. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 55) <!-- [rfced] Section 5.3.6.1:  These sentences did not parse well.
> >>>>>> We updated as follows.  If these updates do not convey your intended
> >>>>>> meaning, please provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Allocating SIs to areas with initially sufficiently many spare bits
> >>>>>> for growths can help to alleviate this issue.  Or renumber BFERs
> >>>>>> after network expansion.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> Allocating SIs to areas that initially have sufficiently many spare
> >>>>>> bits for growth can help alleviate this issue.  Alternatively, BFERs
> >>>>>> can be renumbered after network expansion. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 56) <!-- [rfced] Section 5.3.6.1:  We found the two "even"s in this
> >>>>>> sentence confusing.  We updated as follows.  If this is incorrect,
> >>>>>> please provide clarifying text.
> >>>>>> 
> >>>>>> Original:
> >>>>>> This example shows that intelligent BFR-id allocation within at least
> >>>>>> sub-domain 0 can even be helpful or even necessary in BIER.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> This example shows that intelligent BFR-id allocation within at least
> >>>>>> subdomain 0 can be helpful or even necessary in BIER. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 57) <!-- [rfced] Section 5.3.6.2:
> >>>>>> 
> >>>>>> a) To what does the colon in "area edge BFR:" refer - the next
> >>>>>> paragraph, or the next two paragraphs?  We would like to indent the
> >>>>>> text of the next paragraph or the next two paragraphs, as
> >>>>>> appropriate.  Alternatively, could the colon be changed to a period?
> >>>>>> 
> >>>>>> b) We had trouble following the text in the second paragraph.  If the
> >>>>>> suggested text is not correct, please clarify "the bits indicate bits
> >>>>>> for topology and BFER" and "For BFER in the same area as in the BFIR".
> >>>>>> 
> >>>>>> Original:
> >>>>>> These bits are then set up with the
> >>>>>> right forward_routed() adjacencies on the BFIR and area edge BFR:
> >>>>>> 
> >>>>>> On all BFIRs in an area j|j=1...6, bia in each BIFT:SI is populated
> >>>>>> with the same forward_routed(BFRja), and bib with
> >>>>>> forward_routed(BFRjb).  On all area edge BFR, bea in
> >>>>>> BIFT:SI=k|k=1...6 is populated with forward_routed(BFRka) and beb in
> >>>>>> BIFT:SI=k with forward_routed(BFRkb).
> >>>>>> 
> >>>>>> For BIER-TE forwarding of a packet to a subset of BFERs across all
> >>>>>> areas, a BFIR would create at most 6 copies, with SI=1...SI=6, In
> >>>>>> each packet, the bits indicate bits for topology and BFER in that
> >>>>>> topology plus the four bits to indicate whether to pass this packet
> >>>>>> via the ingress area a or b border BFR and the egress area a or b
> >>>>>> border BFR, therefore allowing path steering for those two "unicast"
> >>>>>> legs: 1) BFIR to ingress area edge and 2) core to egress area edge.
> >>>>>> Replication only happens inside the egress areas.  For BFER in the
> >>>>>> same area as in the BFIR, these four bits are not used.
> >>>>>> 
> >>>>>> Suggested (second paragraph):
> >>>>>> For BIER-TE forwarding of a packet to a subset of BFERs across all
> >>>>>> areas, a BFIR would create at most six copies, with SI=1...SI=6.  In
> >>>>>> each packet, these bits in turn indicate bits for the topology and
> >>>>>> the BFERs in that topology, plus the four bits to indicate whether
> >>>>>> to pass this packet via the ingress area a or b border BFR and the
> >>>>>> egress area a or b border BFR, therefore allowing path steering for
> >>>>>> those two "unicast" legs: 1) BFIR to ingress area edge and 2) core
> >>>>>> to egress area edge.  Replication only happens inside the egress
> >>>>>> areas.  For BFERs that are in the same area as the BFIR, these four
> >>>>>> bits are not used. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 58) <!-- [rfced] Section 6:  We had trouble following the meaning of
> >>>>>> "results of the routing protocol".  Is "results of" necessary?
> >>>>>> If the suggested text is not correct, please clarify.
> >>>>>> 
> >>>>>> Original:
> >>>>>> Attacking the protocols for the BIER routing
> >>>>>> underlay or (non-TE) BIER layer control plane, or impairment of any
> >>>>>> BFR in a domain may lead to successful attacks against the results of
> >>>>>> the routing protocol, enabling DoS attacks against paths or the
> >>>>>> addressing (BFR-id, BFR-prefixes) used by BIER.
> >>>>>> 
> >>>>>> Suggested:
> >>>>>> Attacking the protocols for the BIER routing
> >>>>>> underlay or (non-TE) BIER layer control plane, or the impairment of
> >>>>>> any BFRs in a domain, may lead to successful attacks that target the
> >>>>>> routing protocol, enabling DoS attacks against paths or the
> >>>>>> addressing (BFR-ids, BFR-prefixes) used by BIER. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 59) <!-- [rfced] Section 6:  This sentence did not parse.  We updated it
> >>>>>> as follows.  If this is incorrect, please clarify "same degree of
> >>>>>> looping packets as possible".
> >>>>>> 
> >>>>>> Original:
> >>>>>> In
> >>>>>> result, BIER-TE has the same degree of looping packets as possible
> >>>>>> with unintentional or malicious loops in the routing underlay with
> >>>>>> BIER or even with unicast traffic.
> >>>>>> 
> >>>>>> Currently:
> >>>>>> As a result, looping packets can occur in BIER-TE to the same degree
> >>>>>> as is possible with unintentional or malicious loops in the routing
> >>>>>> underlay with BIER, or even with unicast traffic. -->
> >>>>>> 
> >>>>>> 
> >>>>>> 60) <!-- [rfced] We note that https://dl.acm.org/doi/10.5555/2692227.2692232 resolves, but <https://dx.doi.org/> was unable to find 10.5555/2692227.2692232 in the system.  We found this DOI: 10.3233/JHS-1994-3405, but it's unclear to use if you chose to avoid <https://content.iospress.com/articles/journal-of-high-speed-networks/jhs3-4-05> because it requires payment.  Please review and let us know if any updates are needed. 
> >>>>>> 
> >>>>>> Original:
> >>>>>> [RCSD94]   Zhang, H. and D. Domenico, "Rate-Controlled Service
> >>>>>>          Disciplines",  Journal of High-Speed Networks, 1994, May
> >>>>>>          1994, <https://dl.acm.org/doi/10.5555/2692227.2692232>.
> >>>>>> -->
> >>>>>> 
> >>>>>> 
> >>>>>> 61) <!-- [rfced] Appendix A:  We made quite a few updates to this section
> >>>>>> in an effort to clarify the text.  Please review all updates
> >>>>>> carefully.  If anything is incorrect, please provide clarifying text.
> >>>>>> 
> >>>>>> For example, please clarify the following if our updates to the text
> >>>>>> in question are incorrect:
> >>>>>> 
> >>>>>> * what "either" refers to in the second paragraph
> >>>>>> * what "This can be called" refers to; we changed "This" to "These
> >>>>>> segments"
> >>>>>> * what "SID" stands for; we defined it as "Segment Identifier" per
> >>>>>> RFC 8402
> >>>>>> * what "would directly replicate to it" means; we changed it to "would
> >>>>>> directly replicate traffic on it" -->
> >>>>>> 
> >>>>>> 
> >>>>>> 62) <!-- [rfced] Please review the "Inclusive Language" portion of the
> >>>>>> online Style Guide at
> >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> >>>>>> and let us know if any changes are needed.  Aside from "native", our script did not identify problematic terms. 
> >>>>>> -->
> >>>>>> 
> >>>>>> 
> >>>>>> 63) <!-- [rfced] Please let us know if any changes are needed for the
> >>>>>> following:
> >>>>>> 
> >>>>>> a) The following terms were used inconsistently in this document.
> >>>>>> We chose to use the latter forms.  Please let us know any objections.
> >>>>>> 
> >>>>>> BIFT index (1 instance) / BIFT-index (7 instances)
> >>>>>> 
> >>>>>> ECMP adjacencies (2 instances) / ECMP() adjacencies (10 instances)
> >>>>>> 
> >>>>>> FBM (1 instance) / F-BM
> >>>>>> 
> >>>>>> forward_routed adjacency (or adjacencies) (3 instances) /
> >>>>>> forward_routed() adjacency (or adjacencies) (19 instances)
> >>>>>> 
> >>>>>> Leaf BFER (1 instance in text) / leaf BFER (2 instances in text)
> >>>>>> 
> >>>>>> Non-Leaf BFER (1 instance in text) /
> >>>>>> non-Leaf BFER (3 instances in text) /
> >>>>>> non-leaf BFER (5 instances in text)
> >>>>>> 
> >>>>>> p2p / P2P (in running text)
> >>>>>> 
> >>>>>> traffic engineering / Traffic Engineering (in running text)
> >>>>>> (We see that "Tree Engineering" is consistently
> >>>>>> initial-capitalized in this document, so we went with the
> >>>>>> initial-capitalized form for "Traffic Engineering" as well.)
> >>>>>> 
> >>>>>> b) The following terms appear to be used inconsistently in this
> >>>>>> document.  Please let us know which form is preferred.
> >>>>>> 
> >>>>>> accelerated hardware forwarding (text) /
> >>>>>> Accelerated/Hardware forwarding comparison (section title)
> >>>>>> (In other words, does the slash ("/") serve a specific purpose?)
> >>>>>> 
> >>>>>> BIER-TE controller / BIER-TE Controller
> >>>>>> (For example, we see "... by the BIER-TE controller can be solely
> >>>>>> tracked on the BIER-TE Controller" in Section 3.5.)
> >>>>>> 
> >>>>>> (We also see both "controller" and "Controller" where used more
> >>>>>> generally, e.g., "a controller", "a Controller".  For
> >>>>>> consistency, please advise regarding which form should be used.)
> >>>>>> 
> >>>>>> BIER-TE Topology / BIER-TE topology (in running text)
> >>>>>> 
> >>>>>> entropy / Entropy (for example, "entropy field", "Entropy fields",
> >>>>>> "and optionally Entropy", "the packet entropy")
> >>>>>> 
> >>>>>> Flow overlay / flow overlay (in running text)
> >>>>>> (We see the lowercase form "routing underlay" used consistently
> >>>>>> in running text.)
> >>>>>> 
> >>>>>> Forwarding Pseudocode / forwarding pseudocode (in running text)
> >>>>>> 
> >>>>>> IP/IPv6 / IPv4/IPv6
> >>>>>> 
> >>>>>> leaf-BFER (noun) / leaf BFER (noun)
> >>>>>> (We do not see any instances of  "non-leaf-BFER" where used as
> >>>>>> a noun.  We suggest removing the hyphen after "leaf", as it
> >>>>>> appears that the term appears to indicate whether or not a
> >>>>>> BFER is a "leaf".)
> >>>>>> 
> >>>>>> Multicast Flow Overlay (3 instances in running text) /
> >>>>>> multicast flow overlay (6 instances in running text)
> >>>>>> 
> >>>>>> SIs/BitStrings / SI:BitString / SI:BitStrings
> >>>>>> Should the slash ("/") be a colon (":"), and should
> >>>>>> "SI:BitStrings" be "SIs:BitStrings"?
> >>>>>> 
> >>>>>> (We also see one instance of "SI:BitPositions".) -->
> >>>>>> 
> >>>>>> 
> >>>>>> Thank you.
> >>>>>> 
> >>>>>> RFC Editor
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> On Jul 11, 2022, at 6:40 PM, [e-mail] wrote:
> >>>>>> 
> >>>>>> *****IMPORTANT*****
> >>>>>> 
> >>>>>> Updated 2022/07/11
> >>>>>> 
> >>>>>> RFC Author(s):
> >>>>>> --------------
> >>>>>> 
> >>>>>> Instructions for Completing AUTH48
> >>>>>> 
> >>>>>> Your document has now entered AUTH48.  Once it has been reviewed and 
> >>>>>> approved by you and all coauthors, it will be published as an RFC.  
> >>>>>> If an author is no longer available, there are several remedies 
> >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>>> 
> >>>>>> You and you coauthors are responsible for engaging other parties 
> >>>>>> (e.g., Contributors or Working Group) as necessary before providing 
> >>>>>> your approval.
> >>>>>> 
> >>>>>> Planning your review 
> >>>>>> ---------------------
> >>>>>> 
> >>>>>> Please review the following aspects of your document:
> >>>>>> 
> >>>>>> *  RFC Editor questions
> >>>>>> 
> >>>>>> Please review and resolve any questions raised by the RFC Editor 
> >>>>>> that have been included in the XML file as comments marked as 
> >>>>>> follows:
> >>>>>> 
> >>>>>> <!-- [rfced] ... -->
> >>>>>> 
> >>>>>> These questions will also be sent in a subsequent email.
> >>>>>> 
> >>>>>> *  Changes submitted by coauthors 
> >>>>>> 
> >>>>>> Please ensure that you review any changes submitted by your 
> >>>>>> coauthors.  We assume that if you do not speak up that you 
> >>>>>> agree to changes submitted by your coauthors.
> >>>>>> 
> >>>>>> *  Content 
> >>>>>> 
> >>>>>> Please review the full content of the document, as this cannot 
> >>>>>> change once the RFC is published.  Please pay particular attention to:
> >>>>>> - IANA considerations updates (if applicable)
> >>>>>> - contact information
> >>>>>> - references
> >>>>>> 
> >>>>>> *  Copyright notices and legends
> >>>>>> 
> >>>>>> Please review the copyright notice and legends as defined in
> >>>>>> RFC 5378 and the Trust Legal Provisions 
> >>>>>> (TLP – https://trustee.ietf.org/license-info/).
> >>>>>> 
> >>>>>> *  Semantic markup
> >>>>>> 
> >>>>>> Please review the markup in the XML file to ensure that elements of  
> >>>>>> content are correctly tagged.  For example, ensure that <sourcecode> 
> >>>>>> and <artwork> are set correctly.  See details at 
> >>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>>>> 
> >>>>>> *  Formatted output
> >>>>>> 
> >>>>>> Please review the PDF, HTML, and TXT files to ensure that the 
> >>>>>> formatted output, as generated from the markup in the XML file, is 
> >>>>>> reasonable.  Please note that the TXT will have formatting 
> >>>>>> limitations compared to the PDF and HTML.
> >>>>>> 
> >>>>>> 
> >>>>>> Submitting changes
> >>>>>> ------------------
> >>>>>> 
> >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> >>>>>> the parties CCed on this message need to see your changes. The parties 
> >>>>>> include:
> >>>>>> 
> >>>>>> *  your coauthors
> >>>>>> 
> >>>>>> *  [e-mail] (the RPC team)
> >>>>>> 
> >>>>>> *  other document participants, depending on the stream (e.g., 
> >>>>>>  IETF Stream participants are your working group chairs, the 
> >>>>>>  responsible ADs, and the document shepherd).
> >>>>>> 
> >>>>>> *  [e-mail], which is a new archival mailing list 
> >>>>>>  to preserve AUTH48 conversations; it is not an active discussion 
> >>>>>>  list:
> >>>>>> 
> >>>>>> *  More info:
> >>>>>>    https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>>>>> 
> >>>>>> *  The archive itself:
> >>>>>>    https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>>>> 
> >>>>>> *  Note: If only absolutely necessary, you may temporarily opt out 
> >>>>>>    of the archiving of messages (e.g., to discuss a sensitive matter).
> >>>>>>    If needed, please add a note at the top of the message that you 
> >>>>>>    have dropped the address. When the discussion is concluded, 
> >>>>>>    [e-mail] will be re-added to the CC list and 
> >>>>>>    its addition will be noted at the top of the message. 
> >>>>>> 
> >>>>>> You may submit your changes in one of two ways:
> >>>>>> 
> >>>>>> An update to the provided XML file
> >>>>>> — OR —
> >>>>>> An explicit list of changes in this format
> >>>>>> 
> >>>>>> Section # (or indicate Global)
> >>>>>> 
> >>>>>> OLD:
> >>>>>> old text
> >>>>>> 
> >>>>>> NEW:
> >>>>>> new text
> >>>>>> 
> >>>>>> You do not need to reply with both an updated XML file and an explicit 
> >>>>>> list of changes, as either form is sufficient.
> >>>>>> 
> >>>>>> We will ask a stream manager to review and approve any changes that seem
> >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> >>>>>> and technical changes.  Information about stream managers can be found in 
> >>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
> >>>>>> 
> >>>>>> 
> >>>>>> Approving for publication
> >>>>>> --------------------------
> >>>>>> 
> >>>>>> To approve your RFC for publication, please reply to this email stating
> >>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> >>>>>> as all the parties CCed on this message need to see your approval.
> >>>>>> 
> >>>>>> 
> >>>>>> Files 
> >>>>>> -----
> >>>>>> 
> >>>>>> The files are available here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9262.xml
> >>>>>> https://www.rfc-editor.org/authors/rfc9262.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9262.pdf
> >>>>>> https://www.rfc-editor.org/authors/rfc9262.txt
> >>>>>> 
> >>>>>> Diff file of the text:
> >>>>>> https://www.rfc-editor.org/authors/rfc9262-diff.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9262-rfcdiff.html (side by side)
> >>>>>> 
> >>>>>> Diff of the XML: 
> >>>>>> https://www.rfc-editor.org/authors/rfc9262-xmldiff1.html
> >>>>>> 
> >>>>>> The following files are provided to facilitate creation of your own 
> >>>>>> diff files of the XML.  
> >>>>>> 
> >>>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>> https://www.rfc-editor.org/authors/rfc9262.original.v2v3.xml 
> >>>>>> 
> >>>>>> XMLv3 file that is a best effort to capture v3-related format updates 
> >>>>>> only: 
> >>>>>> https://www.rfc-editor.org/authors/rfc9262.form.xml
> >>>>>> 
> >>>>>> 
> >>>>>> Tracking progress
> >>>>>> -----------------
> >>>>>> 
> >>>>>> The details of the AUTH48 status of your document are here:
> >>>>>> https://www.rfc-editor.org/auth48/rfc9262
> >>>>>> 
> >>>>>> Please let us know if you have any questions.  
> >>>>>> 
> >>>>>> Thank you for your cooperation,
> >>>>>> 
> >>>>>> RFC Editor
> >>>>>> 
> >>>>>> --------------------------------------
> >>>>>> RFC9262 (draft-ietf-bier-te-arch-13)
> >>>>>> 
> >>>>>> Title            : Tree Engineering for Bit Index Explicit Replication (BIER-TE)
> >>>>>> Author(s)        : T.T.E. Eckert, Ed., M.M. Menth, G.C. Cauchie
> >>>>>> WG Chair(s)      : Tony Przygienda, Greg Shepherd
> >>>>>> 
> >>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>> 
> >>>> -- 
> >>>> ---
> >>>> [e-mail]
> >>>> 
> >>> 
> >> 
> > 

-- 
---
[e-mail]