Hi Alice, > On Jul 9, 2025, at 3:19 PM, Alice Russo <aru...@staff.rfc-editor.org> wrote: > > 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/)?
Yes. In addition to thinking the original was a mistake, the whole purpose of the document is the describe SPF Routing using BGP-LS. Please the ill-positioned hyphen confused the intent. > > b) Is it correct that you want the RFC title to remain as is? > > Original: > > BGP Link-State Shortest Path First (SPF) Routing Yes. Thanks, Acee > > > We will wait to hear from you again and from your coauthors > before continuing the publication process. This page shows > the AUTH48 status of your document: > https://www.rfc-editor.org/auth48/rfc9815 > > Thank you. > RFC Editor/ar > >> On Jul 3, 2025, at 9:39 AM, 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. >> >> >>> 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 >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
