Hi Alice, This document looks great as well. I only have a few suggested editorial changes. See the attached RFC diff.
Thanks, Acee
<<< text/html; x-unix-mode=0644; name="rfc9816.orig.diff.html": Unrecognized >>>
> On Jul 11, 2025, at 5:37 PM, Alice Russo <aru...@staff.rfc-editor.org> wrote: > > 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#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 >>>>>> >>>>> >>>> >>> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
