Looks good to me. Best Regards, Keyur
> On Jul 11, 2025, at 1:07 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#table1> >>>>>> 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-4Q9l2USxIAe6P8O4Zc >>>>>> >>>>>> * The archive itself: >>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>> >>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>> If needed, please add a note at the top of the message that you >>>>>> have dropped the address. When the discussion is concluded, >>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>> its addition will be noted at the top of the message. >>>>>> >>>>>> You may submit your changes in one of two ways: >>>>>> >>>>>> An update to the provided XML file >>>>>> — OR — >>>>>> An explicit list of changes in this format >>>>>> >>>>>> Section # (or indicate Global) >>>>>> >>>>>> OLD: >>>>>> old text >>>>>> >>>>>> NEW: >>>>>> new text >>>>>> >>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>> list of changes, as either form is sufficient. >>>>>> >>>>>> We will ask a stream manager to review and approve any changes that seem >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>>> and technical changes. Information about stream managers can be found in >>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>> manager. >>>>>> >>>>>> >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> >>>>>> To approve your RFC for publication, please reply to this email stating >>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>> as all the parties CCed on this message need to see your approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> https://www.rfc-editor.org/authors/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 >>>>> >>>> >>> >> > > [EXTERNAL] -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
