Hi Alice,
Please update Shawn's contact information as well:
Shawn Zandi
Email: [email protected] <mailto:[email protected]>
Thanks,
Acee
> On Jul 10, 2025, at 7:14 AM, Acee Lindem <[email protected]> wrote:
>
> Hi Alice,
>
>> On Jul 9, 2025, at 3:19 PM, Alice Russo <[email protected]> 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 <[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]
