Hi Alice, I approve this version of the document.
Thanks, Acee > On Jul 15, 2025, at 2:57 PM, Alice Russo <aru...@staff.rfc-editor.org> wrote: > > 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-instructions#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-4Q9l2USxIAe >>>> 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
