RFC Editor, See one inline.
> On Jul 3, 2025, at 12:39 PM, Acee Lindem <acee.i...@gmail.com> wrote: > > Hi RFC Editor, > > Thank you for your work on this document. Please see responses inline. > >> On Jul 1, 2025, at 2:19 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] The Abstract and Introduction mention that this document >> provides extensions for use with BGP-LS distribution and the SPF >> algorithm. Would you like to include "extensions" in the document >> title for consistency with the Abstract/Introduction? >> >> Also please consider the short title that appears in the header >> of the PDF file as shown below. >> >> Original: >> BGP Link-State Shortest Path First (SPF) Routing >> >> Option A (although it's not required to add "BGP-LS" into the title): >> BGP - Link State (BGP-LS) Shortest Path First (SPF) Routing >> >> Option B: >> Extensions for BGP Link-State Shortest Path First (SPF) Routing >> >> ... >> Short Title >> Original: >> BGP Link-State SPF Routing >> >> Option At: >> BGP - Link State SPF Routing > > Don't change this - the describes more than just extensions to BGP-LS. > > > >> --> >> >> >> 2) <!--[rfced] May we rephrase "are a matter of implementation detail" to >> "are specific to implementation" or "are specific to the >> implementation process" for clarity? >> >> Original: >> However, the details are a matter of implementation detail >> and out of scope for this document. >> >> Perhaps: >> However, the details are specific to implementation and are >> out of scope for this document. > > Sure - it is more concise. > >> --> >> >> >> 3) <!--[rfced] In the RFC Series, "100s or 1000s" is typically spelled >> out. Would you like to spell it out as shown below for consistency? >> >> Original: >> With standard BGP path-vector routing, a single link >> failure may impact 100s or 1000s of prefixes and result in the >> withdrawal or re-advertisement of the attendant NLRI. >> >> Perhaps: >> With standard BGP path-vector routing, a single link >> failure may impact hundreds or thousands of prefixes >> and result in the withdrawal or re-advertisement of >> the attendant NLRI. >> --> > Sure. > > >> >> >> 4) <!--[rfced] How may we rephrase "and realize all the above advantages" >> for clarity? Is the intended meaning that the BGP SPF topology >> "offers" the above advantages, as shown below? >> >> Original: >> Finally, the BGP SPF topology can be used as an underlay for other >> BGP SAFIs (using the existing model) and realize all the above >> advantages. >> >> Perhaps: >> Finally, the BGP SPF topology can be used as an underlay for other >> BGP SAFIs (using the existing model), and it offers all the above >> advantages. >> --> > > No, use this: > > Finally, the BGP SPF topology can be used as an underlay for other > BGP SAFIs (using the existing model), and obtain all the above > advantages. > >> >> >> 5) <!--[rfced] FYI - We rephrased this sentence as shown below so that >> it's clear Sections 2 and 3 are in this document and not within >> RFCs 4271 and 9552. >> >> Original: >> The document begins with sections defining the precise relationship >> that BGP SPF has with both the base BGP protocol [RFC4271] >> (Section 2) and the BGP Link-State (BGP-LS) extensions [RFC9552] >> (Section 3). >> >> Current: >> This document begins with Section 2 defining the precise relationship >> that BGP SPF has with the base BGP protocol [RFC4271] and Section 3 >> defining the BGP - Link State (BGP-LS) extensions [RFC9552]. >> --> > > Ok - although I didn't see any confusion > > >> >> >> 6) <!--[rfced] Would you like the Requirements Language (Section 1.4) to >> follow the Terminology (Section 1.1)? >> --> > > Sure. > >> >> >> 7) <!--[rfced] May we rephrase this sentence as follows so that it parses >> and is parallel with the third entry in the list? >> >> Original: >> Determining the degree of preference for BGP routes for the SPF >> calculation as described in phase 1 of the base BGP decision >> process is replaced with the mechanisms in Section 6.1. >> >> Perhaps: >> Phase 1 of the base BGP decision process, which determines the >> degree of preference for BGP routes for the SPF calculation, >> is replaced with the mechanisms in Section 6.1. >> --> > > No - the original was unclear: > > Determining the degree of preference for BGP routes > as described in phase 1 of the base BGP decision > process, is replaced with the mechanisms in Section 6.1 for > the SPF calculation. > >> >> >> 8) <!--[rfced] In RFC 4760, the term "Multiprotocol Extensions >> capabilities" is used rather than "Multi-Protocol Extensions >> Capability". We have updated the text below to reflect >> this. Note that there is another instance in Section 5.1. >> Please let us know if these changes are not correct. >> >> Original: >> Once the single-hop BGP session has been established and the >> Multi-Protocol Extensions Capability with the BGP-LS-SPF AFI/SAFI >> has been exchanged [RFC4760] for the corresponding session... >> >> Current: >> Once the single-hop BGP session has been established and the >> Multiprotocol Extensions capabilities have been exchanged with >> the BGP-LS-SPF AFI/SAFI [RFC4760] for the corresponding session... >> --> > > No - it is a single capability representing the BGP-LS_SPF AFI/SAFI. > > >> >> >> 9) <!--[rfced] The following sentence does not parse - are some words >> perhaps missing after "default"? Please let us know how we may >> rephrase for clarity. >> >> Original: >> When required, the default wait indefinitely for the EoR Marker prior >> to advertising the BGP-LS-SPF Link NLRI. Refer to Section 10.4. >> --> > > When required, the default is to wait indefinitely for the EoR Marker prior > to advertising the BGP-LS-SPF Link NLRI. Refer to Section 10.4. > > > >> >> >> 10) <!--[rfced] May we update the title of Section 5 to reflect "Shortest >> Path First (SPF)" instead of "Shortest Path Routing (SPF)" for >> consistency? And may we remove the SPF expansion in the title of >> Section 5.1 since it was expanded in the title of Section 5? >> >> Original: >> 5. BGP Shortest Path Routing (SPF) Protocol Extensions . . . 9 >> 5.1. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . 10 >> >> Perhaps: >> 5. BGP Shortest Path First (SPF) Routing Protocol Extensions . 9 >> 5.1. BGP-LS SPF SAFI . . . . . . . . . . . . . . . . . . . . . 10 >> --> >> > > Yes. > > > > >> >> 11) <!--[rfced] FYI - We updated the following text to match the TLV >> names in RFC 9552. >> >> Original: >> For IPv4 links, the link's local IPv4 (TLV 259) and remote IPv4 >> (TLV 260) addresses are used. For IPv6 links, the local IPv6 >> (TLV 261) and remote IPv6 (TLV 262) addresses are used (Section >> 5.2.2 of [RFC9552]). >> >> Current: >> For IPv4 links, the link's local IPv4 interface address (TLV 259) >> and remote IPv4 neighbor address (TLV 260) are used. For IPv6 >> links, the local IPv6 interface address (TLV 261) and remote IPv6 >> neighbor address (TLV 262) are used (see Section 5.2.2 of [RFC9552]). >> --> >> > > Yes - good catch. > > >> >> 12) <!--[rfced] Section 5.2.2.1. For consistency, should instances of >> "Address Family Link Descriptor" be changed to "Address >> Family Link Descriptor TLV" here, for consistency with usage in >> the rest of the paragraph (which is not pasted below)? >> >> Original: >> For unnumbered links, the address family cannot be ascertained from >> the endpoint link descriptors. Hence, the Address Family (AF) Link >> Descriptor SHOULD be included with the Link Local/Remote Identifiers >> TLV for unnumbered links, so that the link can be used in the >> respective address family SPF. If the Address Family Link Descriptor >> is not present for an unnumbered link, the link will not be used in >> the SPF computation for either address family. If the Address Family >> Link Descriptor is present for a numbered link, the link descriptor >> will be ignored. >> --> > > Yes. > >> >> >> 13) <!--[rfced] We updated the description for BGP status value "1" >> (Section 5.2.3.1) for consistency with IANA's "BGP-LS-SPF Prefix >> NLRI Attribute SPF Status TLV Status" registry >> <https://www.iana.org/assignments/bgp-spf/>, as shown below. >> >> We also placed the information in a table to match the formatting of >> similar text in Section 5.2.2.2. Tables 3 and 4 are both titled >> "BGP Status Values". Would you like to update one of the titles to >> differentiate the tables? >> >> Original: >> BGP Status Values: >> 0 - Reserved >> 1 - Prefix Unreachable with respect to SPF >> 2-254 - Undefined >> 255 - Reserved >> >> Current: >> +=======+============================================+ >> | Value | Description | >> +=======+============================================+ >> | 0 | Reserved | >> + - - - + - - - - - - - - - - - - - - - - - - - - - + >> | 1 | Prefix unreachable with respect to BGP SPF | >> + - - - + - - - - - - - - - - - - - - - - - - - - - -+ >> | 2-254 | Unassigned | >> + - - - + - - - - - - - - - - - - - - - - - - - - - -+ >> | 255 | Reserved | >> + - - - + - - - - - - - - - - - - - - - - - - - - - -+ >> >> Table 4: BGP Status Values >> --> > > Sure - match the IANA registry. For the table names, you can use "Node NLRI > Attribute Status Values", "Link NLRI Attribute Status Values", and "Prefix > NLRI Attribute Status Values". > > >> >> >> 14) <!--[rfced] We note that "SPF Back-Off algorithm" is called the "SPF >> Back-Off Delay algorithm" in RFC 8405. We updated the text below >> for consistency. Please let us know of any objections. >> >> Original: >> The scheduling of the SPF calculation, as described in Section 6.3, is an >> implementation and/or configuration matter. Scheduling MAY be dampened >> consistent with the SPF back-off algorithm specified in [RFC8405]. >> >> Current: >> The scheduling of the SPF calculation, as described in Section 6.3, is an >> implementation and/or configuration matter. Scheduling MAY be dampened >> consistent with the SPF Back-Off Delay algorithm specified in [RFC8405]. >> --> > > Ok - although it seems "Back-Off Delay" seems redundant. I guess I should > talk to the authors 😎 > >> >> >> 15) <!--[rfced] How may we clarify "as more recent" in the following >> text. Have BGP speakers been accepting the self-originated NLRIs >> recently (rather than "always"), as shown below? >> >> Original: >> This is due to the fact that BGP speakers adjacent to the router >> always accept self-originated NLRI from the associated speaker as >> more recent (rule #1). >> >> Perhaps: >> This is due to the fact that BGP speakers adjacent to the router >> have been recently accepting self-originated NLRIs from the >> associated speaker (per rule #1). >> --> > > Leave it as it is. > > >> >> >> 16) <!--[rfced] Please clarify "Prefix versus Node reachability" in the >> last sentence. Does "versus" mean "or" in this context? >> >> Also, we see "BGP-LS-SPF node reachability" in the first sentence. >> Should "node" be "Node" for consistency with "Node reachability" >> (e.g., "BGP-LS-SPF Node reachability")? >> >> Original: >> Local Route Information Base (Local-RIB) - This routing table >> contains reachability information (i.e., next hops) for all >> prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node >> reachability. Implementations may choose to implement this with >> separate RIBs for each address family and/or Prefix versus Node >> reachability. >> >> Perhaps: >> Local Route Information Base (Local-RIB): A routing table that >> contains reachability information (i.e., next hops) for all >> prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF Node >> reachability. Implementations may choose to implement this with >> separate RIBs for each address family and/or Prefix or Node >> reachability. >> --> > > This is what I meant: > > Local Route Information Base (Local-RIB): A routing table that > contains reachability information (i.e., next-hops) for all > prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF Node > reachability. Implementations may choose to implement this with > separate RIBs for each address family and/or separate RIBs for > prefix and node reachability. > > > >> >> >> 17) <!--[rfced] Please clarify what "less than" refers to - is it the >> metric's cost, length, or other? >> >> Original: >> If the Current-Prefix's corresponding prefix is in the Local-RIB >> and the Local-RIB metric is less than the Current-Prefix's metric, >> the Current-Prefix does not contribute to the route and the next >> Prefix NLRI is examined in Step 4. >> --> > > The metric is a quantity similar to a cost. I don't see that this isn't > clear. > > > >> >> >> 18) <!--[rfced] May we update this sentence as shown below for improved >> readability and clarity? >> >> Original: >> If the Current-Prefix's corresponding prefix is not in the >> Local-RIB, the prefix is installed with the Current-Node's >> next-hops installed as the Local-RIB route's next-hops and >> the metric being updated. >> >> Perhaps: >> If the Current-Prefix's corresponding prefix is not in the >> Local-RIB, the prefix is installed with the Current-Node's >> next-hops, which are installed as the next-hops for >> the Local-RIB route and the metric being updated. >> --> > > If the Current-Prefix's corresponding prefix is not in the > Local-RIB, the prefix is installed with the Current-Node's > next-hops installed as the Local-RIB route's next-hops. The > Local-RIB route metric is set to the sum of the cost for > Current-Node and the Current-Prefix's metric. > > > >> >> >> 19) <!--[rfced] The following sentences do not parse, for example, "that >> the BGP-LS-LINK NLRI is advertised with SPF Status". How may we >> rephrase this text for clarity? >> >> Also, should "BGP-LS-LINK NLRI" be updated as "BGP-LS-SPF Link NLRI" >> in the first sentence and "BGP-LS-Prefix NLRI" be updated as >> "BGP-LS-SPF Prefix NLRI" in the second sentence for consistency? >> >> Original: >> The configurable LinkStatusDownAdvertise timer controls the interval >> that the BGP-LS-LINK NLRI is advertised with SPF Status indicating >> the link is down prior to withdrawal. >> >> The configurable PrefixStatusDownAdvertise timer controls the >> interval that the BGP-LS-Prefix NLRI is advertised with SPF >> Status indicating the prefix is unreachable prior to withdrawal. >> >> Perhaps: >> The configurable PrefixStatusDownAdvertise timer controls the >> interval when a BGP-LS-SPF Link NLRI has been advertised with the >> SPF Status TLV and indicates that the prefix is unreachable prior >> to withdrawal. >> >> The configurable PrefixStatusDownAdvertise timer controls the >> interval when a BGP-LS-SPF Prefix NLRI is advertised with the >> SPF Status TLV and indicates that the prefix is unreachable prior >> to withdrawal. >> --> > > No. Leave it as is. > > > >> >> >> 20) <!--[rfced] FYI, we placed the information in Table 5 in ascending >> order to match the "BGP-LS NLRI and Attribute TLVs" registry at >> <https://www.iana.org/assignments/bgp-ls-parameters/> >> --> > > Sure. > > >> >> >> 21) <!--[rfced] Please consider whether the registry names make sense with >> "Status" repeated, i.e., "Status TLV Status"? For example, is the meaning >> intact if the last word is removed? Or, we see examples of registry names >> that end with "TLV Types" or "TLV Values". >> >> Original [not a comprehensive list of instances]: >> the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status" registry >> the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status" registry >> the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status" registry >> >> Perhaps (if removing the last word): >> the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV" registry >> the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV" registry >> the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV" registry >> --> > > I spent way too much time on this and looked at the titles of many IANA > registries. The convention seems to be use "Values" for situation such this > one. > > the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV Values" registry > the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV Values" registry > the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Values" registry > > >> >> >> 22) <!--[rfced] We having trouble parsing this sentence. Does the >> processing of the BGP SPF and BGP-LS-SPF SAFI cause the encoding >> to be inherited from BGP-LS (option A)? Or do BGP-LS-SPF SAFIs >> and processed BGP SPFs inherit the encoding (option B)? Please >> clarify. >> >> Original: >> The BGP SPF processing and the BGP-LS-SPF SAFI inherit the encoding >> from BGP-LS [RFC9552], and consequently, inherit the security >> considerations for BGP-LS associated with encoding. >> >> Perhaps A: >> When BGP SPF and BGP-LS-SPF SAFI are processed, they inherit >> encoding from BGP-LS [RFC9552] and, consequently, inherit the >> security considerations for the BGP-LS associated with encoding. >> >> Perhaps B: >> BGP-LS-SPF SAFIs and processed BGP SPFs inherit the encoding >> from BGP-LS [RFC9552] and, consequently, inherit the security >> considerations for BGP-LS associated with encoding. >> --> > > Use the below, do not attempt to reword. > > The BGP-LS-SPF SAFI and associated BGP SPF processing inherit the > encodings from BGP-LS [RFC9552], and consequently, inherit the security > considerations for BGP-LS associated with these encodings. > > > > >> >> >> 23) <!--[rfced] How may we update this sentence for clarity? >> >> Original: >> Algorithms such as setting the metric inversely to the link speed as >> supported in some IGP implementations MAY be supported. >> >> Perhaps: >> Algorithms that set the metric inversely to the link speed >> in some IGP implementations MAY be supported. >> --> > > Sure. > >> >> >> 24) <!--[rfced] In the first sentence, is "BGP-LS-SPF AFI/SAFI SPF" >> correct or should it perhaps be "BGP-LS-SPF AFI/SAFI"? >> >> In the second sentence, should "BGP SPF Link-State" perhaps be >> "BGP-LS-SPF" for consistency? >> >> Original: >> In common deployment scenarios, the unicast routes installed during >> BGP-LS-SPF AFI/SAFI SPF computation serve as the underlay for other >> BGP AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from >> impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation >> mechanisms such as separate BGP instances or separate BGP sessions >> (e.g., using different addresses for peering) for BGP SPF Link-State >> information distribution SHOULD be used. >> >> Perhaps: >> In common deployment scenarios, the unicast routes installed during >> BGP-LS-SPF AFI/SAFI computation serve as the underlay for other BGP >> AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from >> impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation >> mechanisms such as separate BGP instances or separate BGP sessions >> (e.g., using different addresses for peering) for BGP-LS-SPF >> information distribution SHOULD be used. >> --> > > Sure - added "the " to precede "BGP-LS-SPF...". > > In common deployment scenarios, the unicast routes installed during > the BGP-LS-SPF AFI/SAFI computation serve as the underlay for other BGP > AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from > impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation > mechanisms such as separate BGP instances or separate BGP sessions > (e.g., using different addresses for peering) for BGP-LS-SPF > information distribution SHOULD be used. > > > > >> >> >> 25) <!--[rfced] FYI - To avoid the repetition of "The authors would like >> to thank" in the Acknowledgements, we streamlined the text as >> follows: >> >> Original: >> The authors would like extend thanks Alvaro Retana for >> multiple AD reviews and discussions. >> >> The authors would to thank Ketan Talaulikar for an extensive >> shepherd review. >> >> The authors would like to thank Adrian Farrel, Li Zhang, and Jie Dong >> for WG last call review comments. >> >> The authors would to like to thank Jim Guichard for his AD review >> and discussion. >> >> The authors would to like to thank David Dong for his IANA review. >> >> The authors would to like to thank Joel Halpern for his GENART review. >> >> The authors would to like to thank Erik Kline, Eric Vyncke, Mahesh >> Jethanandani, and Roman Danyliw for IESG review comments. >> >> The authors would to like to thank John Scudder for his detailed >> IESG review and specifically for helping align the document with >> BGP documents. >> >> Current: >> The authors would also like to thank the following people: >> >> * Alvaro Retana for multiple AD reviews and discussions. >> >> * Ketan Talaulikar for an extensive shepherd review. >> >> * Adrian Farrel, Li Zhang, and Jie Dong for WG Last Call review >> comments. >> >> * Jim Guichard for his AD review and discussion. >> >> * David Dong for his IANA review. >> >> * Joel Halpern for his GENART review. >> >> * Erik Kline, Éric Vyncke, Mahesh Jethanandani, and Roman Danyliw >> for IESG review comments. >> >> * John Scudder for his detailed IESG review and specifically for >> helping align the document with BGP documents. >> --> > > Sure. > >> >> >> 26) <!-- [rfced] Some author comments are present in the XML. Please >> confirm that no updates related to these comments are >> outstanding. Note that the comments will be deleted prior to >> publication. >> --> > > We're done - please remove these XML comments. > > > >> >> >> 27) <!-- [rfced] Terminology >> >> a) Throughout the text, the following terminology appears to be used >> inconsistently. Please review these occurrences and let us know >> if/how they may be made consistent. >> >> BGP Router vs. BGP router >> >> BGP SPF Router vs. BGP SPF router > > Use "BGP router" and "BGP SPF router". > > >> >> BGP-LS Attribute vs. BGP-LS attribute >> [Note: uppercase used in RFC 9552] > > Follow RFC 9552. > > >> >> BGP-LS Prefix Attribute vs. BGP-LS Prefix attribute > > Use uppercase "Attribute" since this is a specific attribute. > > >> >> BGP-LS-SPF Link NLRI vs. BGP-LS-SPF NLRI >> [Note: are these terms different or the same?] >> >> BGP-LS-SPF Node NLRI vs. BGP-LS-SPF NLRI >> [Note: are these terms different or the same?] > > > Leave these alone - BPG-LS-SPF NLRI refers generically to all the types. > > > >> >> Decision Process vs. decision process >> [Note: uppercase used in RFC 4271] > > Use uppercase then/ > > >> >> Remote Node NLRI vs. Remote-Node NLRI >> >> UPDATE message vs. Update message vs. update message >> [Note: should this be "UPDATE message" per RFC 7606?] > > Use "UPDATE message" consistent with RFC 4271. > > > >> >> >> b) FYI - We updated the following terms to reflect the forms on the right >> for consistency. Please let us know of any objections. >> >> AS Number (TLV 512) -> Autonomous System (TLV 512) (per RFC 9552) >> back-off algorithm -> Back-Off algorithm (per RFC 8405) >> Error Handling -> error handling >> BGP update -> BGP Update >> BGP SPF Routing Domain -> BGP SPF routing domain >> BGP-SPF -> BGP SPF (2 instances) >> BGP-LS-SPF LINK NLRI -> BGP-LS-SPF Link NLRI >> EoR Marker -> EoR marker (per RFC 4724) >> IGP metric attribute TLV (TLV 1095) -> IGP Metric (TLV 1095) (per RFC 9552) >> link NLRI -> Link NLRI (1) >> local and remote node descriptors -> Local and Remote Node Descriptors >> local node descriptor -> Local Node Descriptor >> NLRI Link -> Link NLRI (1) >> Node identifiers -> Node Identifiers >> phase 1 -> Phase 1 >> Route Reflector -> route reflector (per RFC 4456) >> SAFI BGP-LS-SPF BGP Update -> BGP-LS-SPF SAFI BGP Update >> set 1 -> Step 1 >> Ships-in-the-Night -> ships-in-the-night (per other RFCs) >> Treat-as-withdraw -> treat-as-withdraw (per RFC 7606) >> Unequal Cost Multi-Path -> Unequal-Cost Multipath >> Unicast -> unicast > > Yes. > > >> >> >> c) In this document, we note one occurrence of "BGP-LS-SPF Attribute TLV", >> and it is not used in any other RFCs. Is this correct or does it need an >> update for consistency? > >> >> Original: >> The BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined >> to indicate the status of the link with respect to the BGP SPF >> calculation. > > This should be "BGP-LS Attribute SPF Status TLV" consistent with other > references. > >> >> >> d) In this document, we note one occurrence each of "BGP-LS Node attribute" >> and "BGP-LS Link Attribute". Should these be updated as "BGP-LS Attribute" >> or other for consistency? >> >> Original: >> If the BGP-LS Node attribute includes an SPF Status TLV >> (refer to Section 5.2.1.1) indicating the node is >> unreachable, the Node NLRI is ignored and the next lowest >> cost Node NLRI is selected from the CAN-LIST. > > Yes this should be "BGP-LS Attribute". > > > >> >> Original: >> If BGP-LS-SPF Link NLRI has >> been advertised with the SPF Status TLV and the link becomes >> available in that period, the originator of the BGP-LS-SPF LINK NLRI >> MUST advertise a more recent version of the BGP-LS-SPF Link NLRI >> without the SPF Status TLV in the BGP-LS Link Attributes. > > Use this version: > > > If the BGP-LS-SPF Link NLRI is advertised with the SPF Status TLV > included in the BGP-LS Attribute, and the link becomes available in that > period, > the originator of the BGP-LS-SPF Link NLRI MUST advertise a more recent > version of the BGP-LS-SPF Link NLRI without the SPF Status TLV in the > BGP-LS Link Attribute. > > > > > >> >> >> e) Should one instance of "local/remote link identifiers" perhaps >> be "Link Local/Remote Identifiers" for consistency? >> >> Original: >> For a link to be used in SPF computation for a given address family, >> i.e., IPv4 or IPv6, both routers connecting the link MUST have >> matching addresses (i.e., router interface addresses must be on the >> same subnet for numbered interfaces and the local/remote link >> identifiers (Section 6.3) must match for unnumbered interfaces). >> >> Perhaps: >> For a link to be used in SPF computation for a given address family, >> i.e., IPv4 or IPv6, both routers connecting the link MUST have >> matching addresses (i.e., router interface addresses must be on the >> same subnet for numbered interfaces, and the Link Local/Remote >> Identifiers (Section 6.3) must match for unnumbered interfaces). > > Yes. > > >> >> >> f) We note the following variations - are these terms different or >> the same? Please let us know if any should be updated for consistency. >> >> Link Local/Remote Identifiers (TLV 258) >> Link Remote Identifier >> Link's Remote Identifier >> Remote Link Identifier >> Remote Identifier >> Current or Remote Link's Local Identifier >> Current-Link's Remote Identifier > > These are used in different contexts and should NOT all be the same. For > example, the algorithm description > uses Current-Link to refer to the link being processed. > > > >> >> As one example, how may we update this sentence for consistency? Should >> the reference to TLV 258 be "Link Local/Remote Identifiers" per RFC 9552 >> (option A)? Or should hyphens be added to "Current and Remote Link's" >> (option B)? > > The hyphenated are used in the context of the algorithm description. > Please don't change these. > > > >> >> Original: >> Since the Link's Remote Identifier may not be known, a value of 0 >> is considered a wildcard and will match any Current or Remote >> Link's Local Identifier (see TLV 258 [RFC9552]). >> >> Perhaps A: >> Since the Link Remote Identifier may not be known, a value of 0 >> is considered a wildcard and will match any Link Local/Remote >> Identifiers (see TLV 258 [RFC9552]). >> >> Perhaps B: >> Since the Link Remote Identifier may not be known, a value of 0 >> is considered a wildcard and will match any Current-Link or >> Remote-Link's Local Identifier (see TLV 258 [RFC9552]). >> >> >> g) We note inconsistencies with "next hop". May we update the document >> as shown below for consistency? >> >> Next-Hop vs. Next Hop vs. next-hop vs. next hop >> >> Some instances in the document: >> BGP Next-Hop >> Current-Node's next-hops >> Local-RIB Next-Hop >> Local-RIB route's next-hops >> MP_REACH_NLRI Next-Hop >> The Next Hop in the MP_REACH_NLRI attribute >> (i.e., next hops) >> the next-hop for... >> >> Perhaps: >> BGP Next-Hop (per RFC 9552) >> Local-RIB Next-Hop >> MP_REACH_NLRI Next-Hop >> >> When used in general: lowercase open form or hyphenated >> when preceding a noun (e.g., "The next-hop list is set >> to the internal loopback next hop"). >> --> > > You use the hyphenated form consistent with most references in the document > and RFC 4271. > > > >> >> >> 28) <!-- [rfced] Abbreviations >> >> a) FYI - We have added expansions for the following abbreviations >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Autonomous System (AS) >> Bidirectional Forwarding Detection (BFD) >> Network Layer Reachability Information (NLRI) >> Unequal-Cost Multipath (UCMP) > > Correct. > >> >> b) We note "LSDB" and "LSNDB". Are these different databases or >> should they be updated for consistency? >> >> Link State Database (LSDB) (per RFC 9552) >> Link State NLRI Database (LSNDB) > > These are different LSNDB is specific to BGP SPF and should not be modified. > > > >> >> c) We updated the following expansions to reflect the form on the right >> for consistency with the RFC Series: >> >> BGP Link-State (BGP-LS) -> BGP - Link State (BGP-LS) (per RFC 9552) > > This looks strange but we can go with the RFC 9552 expansion. Actually, I really don't like this. Keep it as: BGP Link State (BGP-LS) We don't need to repeat the same mistake. Thanks, Acee > > >> Equal-Cost Multi-Path (ECMP) -> Equal-Cost Multipath (ECMP) > > Yes. > > >> Internal Gateway Protocols (IGPs) -> Interior Gateway Protocols (IGPs) > > Yes, > > >> Subsequent Address Families Identifiers (SAFIs) -> >> Subsequent Address Family Identifiers (SAFIs) > > Yes. > >> --> >> >> >> 29) <!-- [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. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > None found. > > 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/rfc9815.xml >> https://www.rfc-editor.org/authors/rfc9815.html >> https://www.rfc-editor.org/authors/rfc9815.pdf >> https://www.rfc-editor.org/authors/rfc9815.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9815-diff.html >> https://www.rfc-editor.org/authors/rfc9815-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9815-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9815 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9815 (draft-ietf-lsvr-bgp-spf-51) >> >> Title : BGP Link-State Shortest Path First (SPF) Routing >> Author(s) : K. Patel, A. Lindem, S. Zandi, W. Henderickx >> 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
