Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-bier-te-arch-13> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Fri, 19 August 2022 19:03 UTC
Return-Path: <lbartholomew@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606B9C1522B7; Fri, 19 Aug 2022 12:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNIlazc2SP6O; Fri, 19 Aug 2022 12:03:26 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C73C1522CD; Fri, 19 Aug 2022 12:03:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id EAF514243EFA; Fri, 19 Aug 2022 12:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgUyH4X_UlBt; Fri, 19 Aug 2022 12:03:04 -0700 (PDT)
Received: from [IPv6:2601:646:8b00:70c0:d4ad:1150:7b4f:7888] (unknown [IPv6:2601:646:8b00:70c0:d4ad:1150:7b4f:7888]) by c8a.amsl.com (Postfix) with ESMTPSA id 94C6D4243EF8; Fri, 19 Aug 2022 12:03:04 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <Yv/W/wL+FGe4GV9f@faui48e.informatik.uni-erlangen.de>
Date: Fri, 19 Aug 2022 12:03:03 -0700
Cc: tte+ietf@cs.fau.de, menth@uni-tuebingen.de, gregory@koevoo.tech, bier-ads@ietf.org, bier-chairs@ietf.org, gengxuesong@huawei.com, Alvaro Retana <aretana.ietf@gmail.com>, RFC System <rfc-editor@rfc-editor.org>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <60291600-93A6-4EB8-B554-4F073C8D171B@amsl.com>
References: <20220712014723.4296D4C0A9@rfcpa.amsl.com> <62FF65F9-A0C7-41A7-B686-BBD8A54A5347@amsl.com> <YtscEGHCZKabUWRw@faui48e.informatik.uni-erlangen.de> <8C930C50-64B7-4512-9460-3D19676DFE5D@amsl.com> <555B245B-9529-4588-B3C6-E9D1A44B2AA9@amsl.com> <095DF8DB-6BE8-4990-A387-0BEF0490686E@amsl.com> <FCEEAF23-888E-4B6D-A439-600578B19384@amsl.com> <Yv/W/wL+FGe4GV9f@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/KvxU0Oe_OO-U51jvaLrLxxZyvSE>
Subject: Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-bier-te-arch-13> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 19:03:31 -0000
Hi, Toerless. Thank you for the update. Would prefer to think of these emails as nudges instead of kicks, though! Best, RFC Editor/lb > On Aug 19, 2022, at 11:31 AM, Toerless Eckert <tte@cs.fau.de> wrote: > > 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 <lbartholomew@amsl.com> 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 <lbartholomew@amsl.com> 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 <lbartholomew@amsl.com> 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 <tte@cs.fau.de> 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, rfc-editor@rfc-editor.org 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, rfc-editor@rfc-editor.org 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 >>>>>>>> >>>>>>>> * rfc-editor@rfc-editor.org (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). >>>>>>>> >>>>>>>> * auth48archive@rfc-editor.org, 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, >>>>>>>> auth48archive@rfc-editor.org 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> --- >>>>>> tte@cs.fau.de >>>>>> >>>>> >>>> >>> > > -- > --- > tte@cs.fau.de >
- [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-bier-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Alvaro Retana
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Alvaro Retana
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Grégory CAUCHIE
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Michael Menth
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Michael Menth
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Michael Menth
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Gregory CAUCHIE
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Toerless Eckert
- Re: [auth48] AUTH48: RFC-to-be 9262 <draft-ietf-b… Lynne Bartholomew