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. > 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
