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
