Approved. Sent from my iPhone > On 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
