<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-dong-lsvr-bgp-spf-selection-03"
     ipr="trust200902">
  <front>
    <title abbrev="BGP-SPF Selection Rules">Proposed Update to BGP Link-State
    SPF NLRI Selection Rules</title>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Jinqiang Chen" initials="J." surname="Chen">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>chenjinqiang@huawei.com</email>
      </address>
    </author>

    <author fullname="Sheng Fang" initials="S." surname="Fang">
      <organization>Individual</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>fang_sheng@163.com</email>
      </address>
    </author>

    <date day="2" month="March" year="2026"/>

    <area>Routing Area</area>

    <workgroup>Link State Vector Routing Working Group</workgroup>

    <abstract>
      <t>For network scenarios such as Massively Scaled Data Centers (MSDCs),
      BGP is extended for Link-State (LS) distribution and the Shortest Path
      First (SPF) algorithm based calculation. BGP-LS-SPF leverages the
      mechanisms of both BGP protocol and BGP-LS protocol extensions, with new
      selection rules defined for BGP-LS-SPF NLRI. This document proposes some
      updates to the BGP-LS-SPF NLRI selection rules, so as to improve the
      route updates and convergence, while consistent SPF computation result
      can still be achieved. This document updates the NLRI selection rules in
      I-D.ietf-lsvr-bgp-spf.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>For network scenarios such as Massively Scaled Data Centers (MSDCs),
      BGP is extended for Link-State (LS) distribution and the Shortest Path
      First (SPF) algorithm based calculation. BGP-LS-SPF leverages the
      mechanisms of both BGP protocol and BGP-LS protocol extensions. For
      BGP-LS-SPF NLRIs, the selection rules for Phase 1 of the BGP Decision
      Process (see Section 9.1.1 of <xref target="RFC4271"/>) no longer apply.
      The selection rules for BGP-LS-SPF NLRI are defined in section 6.1 of
      <xref target="RFC9815"/>.</t>

      <t>In some network scenarios, the selection rules defined in <xref
      target="RFC9815"/> for BGP-LS-SPF NLRI may not be enough to provide
      optimized route advertisement and convergence. This document proposes
      some updates to the BGP-LS-SPF NLRI selection rules, so as to improve
      the route convergence while consistent SPF computation result can still
      be achieved.</t>

      <t>This document firstly describes the network scenarios in which the
      existing NLRI selection rules are considered not enough. Then it
      provides suggested updates to the BGP-LS-SPF NLRI selection rules.</t>
    </section>

    <section title="Network Scenarios Which Triggered This Update">
      <t/>

      <section title="Unnecessary Redundant Advertisement">
        <t>According to the rules in <xref target="RFC9815"/>, for the
        BGP-LS-SPF NLRIs with the same sequence number, the NLRI received from
        the numerically larger BGP ID is preferred. While in some cases, this
        may cause unnecessary redundant advertisement of the same NLRI.</t>

        <t><figure>
            <artwork align="center"
                     name="Figure 2. Example of Duplicated Update"><![CDATA[
  +----+  new  +----+         +----+       +----+
  | R6 +-------+ R1 +---------+ R2 +-------+ R5 |
  +----+       +-+--+         +-+--+       +----+
                 |              |
                 |              |
                 |              |
                 |              |
                 |              |
               +-+--+         +-+--+
               | R3 +---------+ R4 |
               +----+         +----+

]]></artwork>
          </figure></t>

        <t>As shown in the example in Figure 2, a new BGP session is
        established between R1 and R6, and R1 advertise the link NLRI of R1-R6
        to its neighboring nodes (R2 and R3). R2 firstly receives the link
        NLRI R1-R6 from R1 directly, and advertise it further to its neighbors
        (R4 and R5). R4 receives the link NLRI of R1-R6 with the same sequence
        number from both R3 and R2, and according to the NLRI selection rules,
        R4 would prefer the NLRI received from R3 according to the rule of
        numerically larger BGP ID, then R4 advertises this link NLRI of R1-R6
        to R2. R2 would also prefer the NLRI received from R4 according to the
        rule of numerically larger BGP ID, and further advertises this link
        NLRI to R5, which is a redundant advertisement of its previous
        advertisement of the same link NLRI.</t>
      </section>

      <section title="Parallal BGP-LS-SPF Peers">
        <t>In some scenarios, BGP single-hop peering model is used between
        directly connected BGP nodes. When two or more parallel links exists
        between the BGP nodes, multiple BGP sessions are established between
        the peering nodes, and each session will be used for the distribution
        of BGP-LS-SPF NLRIs.</t>

        <t><figure>
            <artwork align="center"
                     name="Figure 3. Example of Parallal BGP Peers"><![CDATA[
               parallel BGP sessions

  +----+       +----+         +----+       +----+
  |    |       |    +---------+    |       |    |
  | R3 +-------+ R1 +---------+ R2 +-------+ R4 |
  +----+       +-+--+         +-+--+       +----+
               
]]></artwork>
          </figure></t>

        <t>As shown in the example of Figure 3, there are two parallel links
        between R1 and R2, and a separate BGP session is established on each
        link. Based on the existing BGP-LS-SPF NLRI selection rules, from R2's
        perspective, for the same NLRI with the same sequence number, either
        the route received from peer R1.1, or the route received from peer
        R1.2 may be selected as the best. No matter what tie-breaking rule is
        used, depending on the order of the routes received from R1, R2 may
        need to advertise duplicated NLRIs to R4.</t>
      </section>
    </section>

    <section title="Update to BGP-LS-SPF Selection Rules">
      <t>As the BGP-LS-SPF NLRIs are used to distribute the link-state
      information, which are then used for the SPF computation, BGP attributes
      which are used in BGP best path selection (e.g. AS_PATH) for BGP address
      families other than BGP-LS are not considered in the computation of
      BGP-LS-SPF. The consistency of BGP-LS-SPF computation result only relies
      on the sequence number associated with the BGP-LS-SPF NLRIs. For network
      scenarios where optimized route convergence is more desirable, route
      updates due to the changes in BGP attributes which are not considered in
      the SPF computation, although may help to achieve deterministic NLRI
      selection, is considered not quite necessary.</t>

      <t>Thus this document proposes to update the selection rules for
      BGP-LS-SPF NLRI by adding the below rule 3 (b) in front of the rule 4 in
      section 6.1 of <xref target="RFC9815"/>:</t>

      <t><list style="empty">
          <t>1. NLRIs self-originated from directly connected BGP SPF peers
          are preferred. This condition can be determined by comparing the BGP
          Identifiers in the received Local Node Descriptor and the BGP OPEN
          message for an active BGP session. This rule assures that a stale
          NLRI is updated even if a BGP SPF router loses its sequence number
          state due to a cold start. Note that once the BGP session goes down,
          the NLRI received is no longer considered as being from a directly
          connected BGP SPF peer.</t>

          <t>2. Consistent with base BGP <xref target="RFC4271"/>, an NLRI
          received from a peer will always replace the same NLRI received from
          that peer. Coupled with rule #1, this will ensure that any stale
          NLRI in the BGP SPF routing domain will be updated.</t>

          <t>3. The NLRI with the most recent Sequence Number TLV, i.e., the
          highest sequence number is selected.</t>

          <t>3 (b). The NLRI received from a BGP-LS-SPF peer with the same
          sequence number as the one of the current selected NLRI SHOULD not
          be selected.</t>

          <t>4.The NLRI received from the BGP speaker with the numerically
          larger BGP Identifier is preferred.</t>
        </list></t>

      <t>The rule 3 (b) can help to solve the duplicated advertisement problem
      as described in section 2.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The mechanism described in this document provide updates to the NLRI
      selection rules for BGP-LS-SPF. It does not introduce any additional
      security considerations than those described in <xref target="RFC4271"/>
      and <xref target="RFC4272"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Haibo Wang, Jun Ge and Li Zhang for
      the valuable discussion and suggestions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.4271'?>

      <?rfc include='reference.RFC.9815'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4272'?>
    </references>
  </back>
</rfc>
