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/rfc9815.html https://www.rfc-editor.org/authors/rfc9815.txt https://www.rfc-editor.org/authors/rfc9815.pdf https://www.rfc-editor.org/authors/rfc9815.xml
This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9815-diff.html https://www.rfc-editor.org/authors/rfc9815-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9815-auth48diff.html https://www.rfc-editor.org/authors/rfc9815-auth48rfcdiff.html (side by side) Re: #19 (Section 6.5.1), per your reply, no change has been made. There is one instance of "BGP-LS-LINK NLRI" in the document -- should it be changed to "BGP-LS-SPF Link NLRI" or otherwise? Re: #28 (Abbreviations, specifically BGP-LS) >> 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. In RFC-to-be 9816, we note your decision to use "BGP Link State (BGP-LS)" in the abstract and introduction. a) In light of that, would you like instances of 'BGP - Link State (BGP-LS)' in this document to be changed to "BGP Link State (BGP-LS)", even though it doesn't exactly match RFC 9552 or the IANA registry (https://www.iana.org/assignments/bgp-ls-parameters/)? b) Is it correct that you want the RFC title to remain as is? Original: BGP Link-State Shortest Path First (SPF) Routing 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/rfc9815 Thank you. RFC Editor/ar > On Jul 3, 2025, at 9:39 AM, Acee Lindem <[email protected]> wrote: > > Hi RFC Editor, > > Thank you for your work on this document. Please see responses inline. > >> On Jul 1, 2025, at 2:19 AM, [email protected] 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: [email protected] > > Thanks, > Acee > > > > > > >> >> >> Thank you. >> >> RFC Editor/kc/ar >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
