Looks good to me, Thank you! -Shawn
On Tue, Jul 15, 2025 at 6:38 PM Dongjie (Jimmy) <jie.d...@huawei.com> wrote: > Hi Alice, > > I approve this version of the document for publication, thanks. > > Best regards, > Jie > > > -----Original Message----- > > From: Alice Russo <aru...@staff.rfc-editor.org> > > Sent: Wednesday, July 16, 2025 2:58 AM > > To: Acee Lindem <acee.i...@gmail.com>; Dongjie (Jimmy) > > <jie.d...@huawei.com> > > Cc: Ketan Talaulikar <ketant.i...@gmail.com>; Keyur Patel > > <ke...@arrcus.com>; Gaura Dawra <gdawra.i...@gmail.com>; Shawn Zandi > > <shaf...@shafagh.com>; lsvr-...@ietf.org; lsvr-cha...@ietf.org; > > james.n.guichard <james.n.guich...@futurewei.com>; auth48archive > > <auth48archive@rfc-editor.org>; RFC Editor <rfc-edi...@rfc-editor.org> > > Subject: Re: AUTH48: RFC-to-be 9816 <draft-ietf-lsvr-applicability-22> > for > > your review > > > > Acee, Jie, > > > > Thank you for your replies. The revised files are here (please refresh): > > https://www.rfc-editor.org/authors/rfc9816.html > > https://www.rfc-editor.org/authors/rfc9816.txt > > https://www.rfc-editor.org/authors/rfc9816.pdf > > https://www.rfc-editor.org/authors/rfc9816.xml > > > > This diff file shows all changes from the approved I-D: > > https://www.rfc-editor.org/authors/rfc9816-diff.html > > https://www.rfc-editor.org/authors/rfc9816-rfcdiff.html (side by side) > > > > This diff file shows the changes made during AUTH48 thus far: > > https://www.rfc-editor.org/authors/rfc9816-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9816-auth48rfcdiff.html (side by > > side) > > > > This diff file shows only the changes since the last posted version: > > https://www.rfc-editor.org/authors/rfc9816-lastrfcdiff.html > > > > The requested changes have been made, except for this sentence in Section > > 8: > > However, this is no different than if classical BGP routing > > using the IPv4 and IPv6 address families were used. > > > > We did not change 'were' to 'was' here because it's correct use of 'were' > > (subjunctive after 'if'). > > > > We will wait to hear from you again and from your coauthors before > > continuing the publication process. This page shows the AUTH48 status of > > your document: > > https://www.rfc-editor.org/auth48/rfc9816 > > > > Thank you. > > RFC Editor/ar > > > > > On Jul 14, 2025, at 3:49 AM, Acee Lindem <acee.i...@gmail.com> wrote: > > > > > > Good catch Jie... > > > > > > Specifically, that would be: > > > > > > *** rfc9816.orig.txt Sat Jul 12 17:29:45 2025 > > > --- rfc9816.bfd.txt Mon Jul 14 06:46:43 2025 > > > *************** > > > *** 201,207 **** > > > Alternatively, as each and every router in the BGP-SPF domain will > > > have a complete view of the topology, the operator can also choose > to > > > configure BGP sessions in the hop-by-hop peering model described in > > > ! [RFC7938] along with BFD [RFC5580]. In doing so, while the > hop-by- > > > hop peering model lacks the inherent benefits of the > controller-based > > > model, BGP updates need not be serialized by the BGP best-path > > > algorithm in either of these models. This helps overall network > > > --- 201,207 ---- > > > Alternatively, as each and every router in the BGP-SPF domain will > > > have a complete view of the topology, the operator can also choose > to > > > configure BGP sessions in the hop-by-hop peering model described in > > > ! [RFC7938] along with BFD [RFC5880]. In doing so, while the > hop-by- > > > hop peering model lacks the inherent benefits of the > controller-based > > > model, BGP updates need not be serialized by the BGP best-path > > > algorithm in either of these models. This helps overall network > > > *************** > > > *** 251,257 **** > > > > > > 5.2.1. Sparse Peering Model > > > > > > ! Alternately, BFD [RFC5580] can be used to swiftly determine the > > > availability of links, and the BGP peering model can be > significantly > > > sparser than the data center fabric. BGP-SPF sessions only need to > > > be established with enough peers to provide a biconnected graph. > > > If > > > --- 251,257 ---- > > > > > > 5.2.1. Sparse Peering Model > > > > > > ! Alternately, BFD [RFC5880] can be used to swiftly determine the > > > availability of links, and the BGP peering model can be > significantly > > > sparser than the data center fabric. BGP-SPF sessions only need to > > > be established with enough peers to provide a biconnected graph. > > > If > > > *************** > > > *** 534,544 **** > > > [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > > > for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, > > > <https://www.rfc-editor.org/info/rfc5340>. > > > - > > > - [RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., > and > > > - B. Aboba, "Carrying Location Objects in RADIUS and > > > - Diameter", RFC 5580, DOI 10.17487/RFC5580, August > > 2009, > > > - <https://www.rfc-editor.org/info/rfc5580>. > > > > > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding > Detection > > > (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, > > > --- 534,539 ---- > > > > > > Thanks, > > > Acee > > > > > >> On Jul 13, 2025, at 10:55 PM, Dongjie (Jimmy) <jie.d...@huawei.com> > > wrote: > > >> > > >> Hi Alice, > > >> > > >> Thanks a lot for your effort on this document. I've reviewed this > update > > and only find one nit: > > >> > > >> In some places of the document, the reference to BFD points to RFC > 5580 > > by mistake, it should be updated to RFC 5880. And in the informative > > references, the reference to RFC5580 can be removed. > > >> > > >> Other than this nit, this version is good to me and I approve its > > publication. > > >> > > >> Best regards, > > >> Jie > > >> > > >>> -----Original Message----- > > >>> From: Alice Russo <aru...@staff.rfc-editor.org> > > >>> Sent: Saturday, July 12, 2025 5:37 AM > > >>> To: Acee Lindem <acee.i...@gmail.com> > > >>> Cc: Ketan Talaulikar <ketant.i...@gmail.com>; Keyur Patel > > >>> <ke...@arrcus.com>; gdawra.i...@gmail.com; Shawn Zandi > > >>> <shaf...@shafagh.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; > > >>> lsvr-...@ietf.org; lsvr-cha...@ietf.org; james.n.guichard > > >>> <james.n.guich...@futurewei.com>; auth48archive > > >>> <auth48archive@rfc-editor.org>; RFC Editor > > >>> <rfc-edi...@rfc-editor.org> > > >>> Subject: Re: AUTH48: RFC-to-be 9816 > > >>> <draft-ietf-lsvr-applicability-22> for your review > > >>> > > >>> Acee, > > >>> > > >>> Thank you for your reply; the files have been updated accordingly. > > >>> Please refresh the same URLs as below > > >>> (https://www.rfc-editor.org/authors/rfc9816-lastrfcdiff.html shows > > >>> only the most recent changes). > > >>> > > >>> RFC Editor/ar > > >>> > > >>>> On Jul 11, 2025, at 1:06 PM, Acee Lindem <acee.i...@gmail.com> > > wrote: > > >>>> > > >>>> Hi Alice, > > >>>> > > >>>>> On Jul 11, 2025, at 3:48 PM, Alice Russo > > >>>>> <aru...@staff.rfc-editor.org> > > >>> wrote: > > >>>>> > > >>>>> Acee, > > >>>>> > > >>>>> We have updated the authors' contact information as requested. The > > >>> revised files are here (please refresh): > > >>>>> https://www.rfc-editor.org/authors/rfc9816.html > > >>>>> https://www.rfc-editor.org/authors/rfc9816.txt > > >>>>> https://www.rfc-editor.org/authors/rfc9816.pdf > > >>>>> https://www.rfc-editor.org/authors/rfc9816.xml > > >>>>> > > >>>>> This diff file shows all changes from the approved I-D: > > >>>>> https://www.rfc-editor.org/authors/rfc9816-diff.html > > >>>>> https://www.rfc-editor.org/authors/rfc9816-rfcdiff.html (side by > > >>>>> side) > > >>>>> > > >>>>> This diff file shows the changes made during AUTH48 thus far: > > >>>>> https://www.rfc-editor.org/authors/rfc9816-auth48diff.html > > >>>>> https://www.rfc-editor.org/authors/rfc9816-auth48rfcdiff.html > > >>>>> (side by side) > > >>>>> > > >>>>> This diff file shows only the changes since the last posted > version: > > >>>>> https://www.rfc-editor.org/authors/rfc9816-lastrfcdiff.html > > >>>>> > > >>>>> As mentioned in a separate mail re: 9815, we suggest considering > > >>>>> this > > >>> update to the title (remove hyphen and add acronym). > > >>>>> > > >>>>> -- 9816 > > >>>>> Current: Usage and Applicability of BGP Link-State Shortest Path > > >>>>> First (SPF) Routing in Data Centers > > >>>>> Perhaps: Usage and Applicability of BGP Link State (BGP-LS) > > >>>>> Shortest Path First (SPF) Routing in Data Centers > > >>>> > > >>>> Sure, > > >>>> > > >>>> Thanks > > >>>> Acee > > >>>> > > >>>>> > > >>>>> > > >>>>> We will wait to hear from you again and from your coauthors before > > >>>>> continuing the publication process. This page shows the AUTH48 > > >>>>> status of your document: > > >>>>> https://www.rfc-editor.org/auth48/rfc9816 > > >>>>> > > >>>>> Thank you. > > >>>>> RFC Editor/ar > > >>>>> > > >>>>>> On Jul 10, 2025, at 4:17 AM, Acee Lindem <acee.i...@gmail.com> > > wrote: > > >>>>>> > > >>>>>> Hi Alice, > > >>>>>> > > >>>>>>> On Jul 9, 2025, at 3:19 PM, Alice Russo > > >>>>>>> <aru...@staff.rfc-editor.org> > > >>> wrote: > > >>>>>>> > > >>>>>>> Acee, Ketan (as AD), > > >>>>>>> > > >>>>>>> *AD - Please review this change and let us know if you approve > > >>>>>>> (changed > > >>> from "MUST" to "must" per Acee's reply to #5). > > >>>>>>> > > >>>>>>> Original: > > >>>>>>> The Link Local/Remote Identifiers of the peering interfaces MUST > > >>>>>>> be used in the link NLRI as described in section 5.2.2 of > > >>>>>>> [I-D.ietf-lsvr-bgp-spf]. > > >>>>>>> > > >>>>>>> Current: > > >>>>>>> The Link Local/Remote Identifiers of the peering interfaces must > > >>>>>>> be used in the link NLRI as described in Section 5.2.2 of > [RFC9815]. > > >>>>>> > > >>>>>> Sure. This is an "Informational" status document. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Acee, > > >>>>>>> Thank you for your reply. My apologies for the delay. Please see > > >>>>>>> the > > >>> follow-ups below. The revised files are here (please refresh): > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816.html > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816.txt > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816.pdf > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816.xml > > >>>>>>> > > >>>>>>> This diff file shows all changes from the approved I-D: > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816-diff.html > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816-rfcdiff.html (side by > > >>>>>>> side) > > >>>>>>> > > >>>>>>> This diff file shows the changes made during AUTH48 thus far: > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816-auth48diff.html > > >>>>>>> https://www.rfc-editor.org/authors/rfc9816-auth48rfcdiff.html > > >>>>>>> (side by side) > > >>>>>>> > > >>>>>>> > > >>>>>>> Re: #4, we updated to the text you provided except for expanding > > >>>>>>> "SPF", > > >>> as it has already been expanded within the document and is used > > >>> earlier within the same sentence without expansion. If you prefer > > >>> otherwise, please let us know. > > >>>>>>> > > >>>>>>> FYI, in Section 2, this has been updated as follows; please let > > >>>>>>> us know if > > >>> you prefer otherwise. > > >>>>>>> Old: BGP-SPF [RFC9815] > > >>>>>>> New: BGP-LS SPF [RFC9815] > > >>>>>> > > >>>>>> Sure - just not BGP - .... > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Acee > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> We will wait to hear from you again and from your coauthors > > >>>>>>> before continuing the publication process. This page shows the > > >>>>>>> AUTH48 status of your document: > > >>>>>>> https://www.rfc-editor.org/auth48/rfc9816 > > >>>>>>> > > >>>>>>> Thank you. > > >>>>>>> RFC Editor/ar > > >>>>>>> > > >>>>>>>> On Jul 3, 2025, at 4:58 PM, Acee Lindem <acee.i...@gmail.com> > > >>> wrote: > > >>>>>>>> > > >>>>>>>> Hi RFC Editor, > > >>>>>>>> > > >>>>>>>> Thank you for your work on this document. > > >>>>>>>> > > >>>>>>>>> On Jul 1, 2025, at 2:21 AM, rfc-edi...@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] BGP-LS and SPF > > >>>>>>>>> > > >>>>>>>>> a) Would you like to update the title of the document as shown > > >>>>>>>>> below or otherwise, to more closely match how "BGP-LS" and > > "SPF" > > >>>>>>>>> are handled in the title of RFC-to-be 9815? > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> Usage and Applicability of BGP Link-State Shortest Path > > >>>>>>>>> Routing > > >>>>>>>>> (BGP-SPF) in Data Centers > > >>>>>>>>> > > >>>>>>>>> Option A: > > >>>>>>>>> Usage and Applicability of BGP Link-State Shortest Path First > > >>>>>>>>> (SPF) Routing in Data Centers > > >>>>>>>> > > >>>>>>>> Use option A consistent with the base document - "BGP > > >>>>>>>> Link-State > > >>> Shortest Path First (SPF) Routing" in RFC 9815. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Option B: > > >>>>>>>>> Usage and Applicability of BGP - Link State (BGP-LS) Shortest > > >>>>>>>>> Path First (SPF) Routing in Data Centers > > >>>>>>>>> > > >>>>>>>>> b) To match how the companion document expands "BGP-LS" and > > >>>>>>>>> "SPF", may we update the Abstract and Introduction as shown > > >>>>>>>>> below for consistency? > > >>>>>>>>> > > >>>>>>>>> Original (Abstract): > > >>>>>>>>> This document discusses the usage and applicability of BGP > > >>>>>>>>> Link-State Shortest Path First (BGP-SPF) extensions in data > > >>>>>>>>> center networks utilizing Clos or Fat-Tree topologies. > > >>>>>>>>> > > >>>>>>>>> Perhaps: > > >>>>>>>>> This document discusses the usage and applicability of BGP - > > >>>>>>>>> Link State > > >>>>>>>>> (BGP-LS) Shortest Path First (SPF) extensions in data center > > >>>>>>>>> networks utilizing Clos or Fat Tree topologies. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Use; > > >>>>>>>> > > >>>>>>>> This document discusses the usage and applicability of BGP Link > > >>>>>>>> State > > >>>>>>>> (BGP-LS) Shortest Path First (SPF) extensions in data center > > >>>>>>>> networks utilizing Clos or Fat Tree topologies. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> ... > > >>>>>>>>> Original (Introduction): > > >>>>>>>>> This document complements [I-D.ietf-lsvr-bgp-spf] by > > >>>>>>>>> discussing the applicability of the BGP-SPF technology in a > > >>>>>>>>> simple and fairly common deployment scenario, which is > > described in Section 3. > > >>>>>>>>> > > >>>>>>>>> Perhaps: > > >>>>>>>>> This document complements [RFC9815] by discussing the > > >>>>>>>>> applicability of the BGP - Link State (BGP-LS) Shortest Path > > >>>>>>>>> First (SPF) technology in a simple and fairly common > > >>>>>>>>> deployment scenario, which is described in Section 3. > > >>>>>>>> > > >>>>>>>> Use: > > >>>>>>>> > > >>>>>>>> This document complements [RFC9815] by discussing the > > >>>>>>>> applicability of the BGP Link State (BGP-LS) Shortest Path > > >>>>>>>> First > > >>>>>>>> (SPF) technology in a simple and fairly common deployment > > >>>>>>>> scenario, which is described in Section 3. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> c) Throughout the text, we note "BGP-SPF" vs. "BGP SPF". "BGP > > >>>>>>>>> SPF" is used both in the companion document and the IANA > > >>>>>>>>> registry at <https://www.iana.org/assignments/bgp-spf/>. Would > > >>>>>>>>> you like to update each instance of "BGP-SPF" to "BGP SPF" for > > consistency? > > >>>>>>>>> See one example below: > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> The document is intended to provide simplified guidance for > > >>>>>>>>> the deployment of BGP-SPF extensions. > > >>>>>>>>> > > >>>>>>>>> Perhaps: > > >>>>>>>>> The document is intended to provide simplified guidance for > > >>>>>>>>> the deployment of BGP SPF extensions. > > >>>>>>>> > > >>>>>>>> Use "BGP SPF" then. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> --> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 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 updated "RFC 5580" to "RFC 5880" in the > > >>>>>>>>> following sentence, and elsewhere in the document where "BFD" > > >>>>>>>>> is referenced, as "BFD" is defined in RFC 5880 and not > > >>>>>>>>> mentioned in RFC 5580. If this is not correct, please let us > know. > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> This document also assumes knowledge of data center routing > > >>>>>>>>> protocols such as BGP [RFC4271], BGP-SPF > > >>>>>>>>> [I-D.ietf-lsvr-bgp-spf], OSPF [RFC2328] [RFC5340], as well as > > >>>>>>>>> data center Operations, Administration, and Maintenance (OAM) > > >>>>>>>>> protocols like Link Layer Discovery Protocol (LLDP) [RFC4957] > > >>>>>>>>> and Bi- Directional Forwarding Detection (BFD) [RFC5580]. > > >>>>>>>>> > > >>>>>>>>> Current: > > >>>>>>>>> This document also assumes knowledge of data center routing > > >>>>>>>>> protocols such as BGP [RFC4271], BGP-SPF [RFC9815], and OSPF > > >>>>>>>>> [RFC2328] [RFC5340] as well as data center Operations, > > >>>>>>>>> Administration, and Maintenance (OAM) protocols like the Link > > >>>>>>>>> Layer Discovery Protocol (LLDP) [RFC4957] and Bidirectional > > >>>>>>>>> Forwarding Detection (BFD) [RFC5580]. > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> Sure - good catch. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 4) <!--[rfced] "SPF" is not mentioned in RFC 9552. Should a > > >>>>>>>>> different RFC be referenced or was "OSPF" perhaps intended? > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> The BGP-SPF modifications allow BGP to overcome these > > limitations. > > >>>>>>>>> Furthermore, using the BGP-LS Network Layer Reachability > > >>>>>>>>> Information > > >>>>>>>>> (NLRI) format allows the BGP-SPF data to be advertised for > > >>>>>>>>> nodes, links, and prefixes in the BGP routing domain and used > > >>>>>>>>> for Short- Path-First (SPF) computations [RFC9552]. > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> Use: > > >>>>>>>> > > >>>>>>>> The BGP-SPF modifications allow BGP to overcome these > > limitations. > > >>>>>>>> Furthermore, using the BGP-LS Network Layer Reachability > > >>>>>>>> Information > > >>>>>>>> (NLRI) format [RFC9552] allows the BGP-SPF data to be > > >>>>>>>> advertised for nodes, links, and prefixes in the BGP routing > > >>>>>>>> domain and used for Short- Path-First (SPF) computations. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 5) <!-- [rfced] We see that the approved I-D (v22) contains > > >>>>>>>>> one instance of a keyword ("MUST" in Section 5.5.1). Is this > > >>>>>>>>> intentional? If so, we will add the typical paragraph from BCP > > >>>>>>>>> 14 regarding use of keywords after the Introduction and add > > >>>>>>>>> RFCs > > >>>>>>>>> 2119 and 8174 to the Normative References section. Otherwise, > > >>>>>>>>> we will update "MUST" to "must". > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> The Link Local/Remote Identifiers of the peering interfaces > > >>>>>>>>> MUST be used in the link NLRI as described in section 5.2.2 of > > >>>>>>>>> [I-D.ietf-lsvr-bgp-spf]. > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> Please change to "must" for BCP. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 6) <!--[rfced] Is "BGP-LS SPF Topology" correct or should it > > >>>>>>>>> perhaps be "BGP-LS-SPF Topology" for consistency? > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> 5.5.2 BGP-LS SPF Topology Visibility for Management > > >>>>>>>>> > > >>>>>>>>> Perhaps: > > >>>>>>>>> 5.5.2 BGP-LS-SPF Topology Visibility for Management > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> Ok. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 7) <!--[rfced] Would repeating "Non" make this section title > > >>>>>>>>> more > > >>> clear? > > >>>>>>>>> The meaning seems to be applicability to topologies that are > > >>>>>>>>> neither Clos nor Fat Tree topologies. > > >>>>>>>>> > > >>>>>>>>> Original: > > >>>>>>>>> 6. Non-CLOS/FAT Tree Topology Applicability > > >>>>>>>>> > > >>>>>>>>> Current: > > >>>>>>>>> 6. Non-Clos / Fat Tree Topology Applicability > > >>>>>>>>> > > >>>>>>>>> Perhaps: > > >>>>>>>>> 6. Non-Clos / Non-Fat-Tree Topology Applicability > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> Leave as: > > >>>>>>>> 6. Non-Clos / Fat Tree Topology Applicability > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 8) <!-- [rfced] FYI - We updated the following terms for > > >>>>>>>>> consistency. Please let us know of any objections. > > >>>>>>>>> > > >>>>>>>>> BGP-LS Node NLRI Attribute SPF Status TLV -> BGP-LS-SPF Node > > >>>>>>>>> NLRI Attribute SPF Status TLV (per the companion doc) BGP-LS > > >>>>>>>>> SPF SAFI > > >>>>>>>>> -> BGP-LS-SPF SAFI (per the companion doc) Clos Topologies -> > > >>>>>>>>> Clos topologies Fat-Tree -> Fat Tree (per use in the RFC > > >>>>>>>>> Series) link NLRI -> Link NLRI (per RFC 9552) Route > > >>>>>>>>> Controllers -> route controllers (per companion document) > > >>>>>>>>> Route Reflectors -> route reflectors (per companion document) > > >>>>>>>>> Spine Nodes -> spine nodes Unicast -> unicast > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> Ok. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 9) <!-- [rfced] FYI - We have updated the expansions for the > > >>>>>>>>> following abbreviations to reflect the form on the right for > > >>>>>>>>> consistency with the companion document and/or RFC Series. > > >>>>>>>>> > > >>>>>>>>> Bi-Directional Forwarding Detection (BFD) -> Bidirectional > > >>>>>>>>> Forwarding Detection (BFD) > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Ok. > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Equal-Cost Multi-Path (ECMP) -> Equal-Cost Multipath (ECMP) > > >>>>>>>> > > >>>>>>>> Ok. > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Top-Of-Rack (ToR) -> Top-of-Rack (ToR) > > >>>>>>>> > > >>>>>>>> Ok. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> --> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 10) <!-- [rfced] Please review the "Inclusive Language" > > >>>>>>>>> portion of the > > >>> online > > >>>>>>>>> Style Guide > > >>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > >>>>>>>>> and let us know if any changes are needed. Updates of this > > >>>>>>>>> nature > > >>> typically > > >>>>>>>>> result in more precise language, which is helpful for readers. > > >>>>>>>>> > > >>>>>>>>> For example, please consider whether the following should be > > >>> updated: > > >>>>>>>>> - blackhole > > >>>>>>>> > > >>>>>>>> Replace "blackhole" with "routes to unreachable destinations". > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> In addition, please consider whether "traditional" should be > > >>>>>>>>> updated for clarity. While the NIST website > > >>>>>>>>> > > >>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/ > > >>>>>>>>> > > >>> nist-research-library/nist-technical-series-publications-author-inst > > >>> ructions#ta > > >>> ble1> > > >>>>>>>>> indicates that this term is potentially biased, it is also > ambiguous. > > >>>>>>>>> "Tradition" is a subjective term, as it is not the same for > everyone. > > >>>>>>>>> --> > > >>>>>>>> > > >>>>>>>> "usual BGP underlays" and "classical BGP routing". > > >>>>>>>> > > >>>>>>>> Please update my contact information with a new affiliation: > > >>>>>>>> > > >>>>>>>> Acee Lindem > > >>>>>>>> Arrcus, Inc. > > >>>>>>>> 301 Midenhall Way > > >>>>>>>> Cary, NC 27513 > > >>>>>>>> United States of America > > >>>>>>>> Email: acee.i...@gmail.com > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Acee > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thank you. > > >>>>>>>>> > > >>>>>>>>> RFC Editor/kc/ar > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Jun 30, 2025, rfc-edi...@rfc-editor.org wrote: > > >>>>>>>>> > > >>>>>>>>> *****IMPORTANT***** > > >>>>>>>>> > > >>>>>>>>> Updated 2025/06/30 > > >>>>>>>>> > > >>>>>>>>> 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-edi...@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-4Q9l2US > > >>> xIAe > > >>> 6P8O4Zc > > >>>>>>>>> > > >>>>>>>>> * 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/rfc9816.xml > > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9816.html > > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9816.pdf > > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9816.txt > > >>>>>>>>> > > >>>>>>>>> Diff file of the text: > > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9816-diff.html > > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9816-rfcdiff.html (side > > >>>>>>>>> by side) > > >>>>>>>>> > > >>>>>>>>> Diff of the XML: > > >>>>>>>>> https://www.rfc-editor.org/authors/rfc9816-xmldiff1.html > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Tracking progress > > >>>>>>>>> ----------------- > > >>>>>>>>> > > >>>>>>>>> The details of the AUTH48 status of your document are here: > > >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9816 > > >>>>>>>>> > > >>>>>>>>> Please let us know if you have any questions. > > >>>>>>>>> > > >>>>>>>>> Thank you for your cooperation, > > >>>>>>>>> > > >>>>>>>>> RFC Editor > > >>>>>>>>> > > >>>>>>>>> -------------------------------------- > > >>>>>>>>> RFC9816 (draft-ietf-lsvr-applicability-22) > > >>>>>>>>> > > >>>>>>>>> Title : Usage and Applicability of BGP Link-State > > Shortest > > >>> Path Routing (BGP-SPF) in Data Centers > > >>>>>>>>> Author(s) : K. Patel, A. Lindem, S. Zandi, G. Dawra, J. > Dong > > >>>>>>>>> WG Chair(s) : Jie Dong, Acee Lindem > > >>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van > > >>>>>>>>> de Velde > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
