<?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" ipr="trust200902" docName="draft-lp-idr-bgp-algorithm-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="Algorithm in BGP"> Advertisement of Algorithm in BGP</title>
<author fullname="Liu Yao" initials="Y." surname="Liu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street/>
<city></city>
<region/>
<code/>
<country></country>
</postal>
<email>liu.yao71@zte.com.cn</email>
</address>
</author>
<author fullname="Peng Shaofu" initials="Shaofu" surname="Peng">
<organization>ZTE Corporation</organization>
<address>
<email>peng.shaofu@zte.com.cn</email>
</address>
</author>
<date year="2025"/>
<area>Routing</area>
<workgroup>IDR Working Group</workgroup>

<keyword>BGP</keyword>
<keyword>Algorithm</keyword>


<abstract>
<t> 
This document proposes extensions to BGP to support algorithm-based end-to-end path establishment.
</t>
</abstract>
</front>

<!--  ***** MIDDLE MATTER *****  -->
<middle>

<section anchor="intro" title="Introduction">
<t>
<xref target="RFC9350"/> proposes a solution that allows IGPs themselves to compute constraint-based paths over the SR network. <xref target="RFC9502"/> allows flex-algo to be deployed in any IP network, even in the absence of SR-MPLS and SRv6.</t>
<t>However, the algorithm-based path can only be used in the IGP domain. In the BGP-based inter-domain scenario, end-to-end path based on algorithms cannot be supported.</t>
<t>This document proposes extensions to BGP to support algorithm-based end-to-end path establishment.</t>

</section>

<section title="Conventions used in this document">

        <section title="Requirements Language">
             <t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", and "OPTIONAL" in this document are to be interpreted as
   described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
   when, and only when, they appear in all capitals, as shown here.
             </t>
          </section>
          

</section>

<section title="Algorithm Extended Community">

<t>This document defines a new transitive BGP Extended Communities Attribute<xref target="RFC4360"/>. This new Extended Community has the following encoding, where:</t>
<t>
<figure align="left" anchor="Algo-EC" title="Algorithm Extended Community">
<artwork>
<![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type=0x03    | Sub-Type=TBA1 |     Flags     |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         Reserved (4 Octets)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
<list>
<t>Type: 1 octet. The value is 0x03. </t>
<t>Sub-Type: 1 octet. TBA1</t>
<t>Flags: 1 octet. Unused, MUST be set to 0 and ingored on receipt. </t>
<t>Algorithm: 1 octet specifying IGP Algorithm Types. Value from 0 to 255.</t>
<t>Reserved: 4 Octets. MUST be set to 0, ignored at reception</t>
</list>
</t>

</section>





<section  title="Algo-based Inter-domain Path">
<t>
<figure align="left" anchor="algo-inter-domain" title="Algo-based Inter-domain Path">
<artwork>
<![CDATA[
+----------------------+             +----------------------+
|         | 2 |        |             |        | 6 |         |
|         +---+        |             |        +---+         |
|                      |             |                      |
|    Flex-algo 128     |             |    Flex-algo 128     |
|                      |             |                      |
|---+                +---+         +---+                +---|
| 1 |----------------| 4 |---------| 5 |----------------| 8 |
|---+                +---+         +---+                +---|
|                      |             |                      |
|    Flex-algo 129     |             |    Flex-algo 129     |
|                      |             |                      |
|         +---+        |             |        +---+         |
|         | 3 |        |             |        | 7 |         |
+----------------------+             +----------------------+
|<-----IGP Domain1---->|             |<-----IGP Domain2---->| 
]]>
</artwork>
</figure>
</t>

<t>As shown in <xref target="algo-inter-domain"/>, node 8 is configured with two loopback addresses, loopback-1 and loopback-2, they belong to the flex-algo 128 plane and the flex-algo 129 plane respectively. In IGP domain 2, the routes to loopback-1 will be generated on the nodes (e.g, node 5,6,8) in the Flex-algo 128 plane and the routes to loopback-2 will be generated on the nodes (e.g, node 5,7,8) in the Flex-algo 129 plane.</t>
<t>Node 5 can advertise prefix loopback-1 and prefix loopback-2 to node 4 through BGP<xref target="RFC2545"/><xref target="RFC4271"/>. Node 4 can import the BGP routes into IGP and continue to advertise the routes to its neighbors in IGP domain1. Or, node 4 directly advertises the routes to node 1 through BGP. </t>
<t>In both cases, the corresponding algorithm information from IGP domain2 is lost during the advertisement. As a result, node 4 does not know which Flex-algo plane to import loopback-1 or loopback-2 into IGP domain 1.</t>
<t>With the Algorithm Extended Community, the algorithm information can be carried in the BGP route of loopbacks advertised from node 5 to node 4.</t>


<t>The administrator can configure algorithms in each IGP domain in the network. A simple configuration method is that algorithms in each IGP domain are consistent.
If the algorithm configurations in each IGP domain are inconsistent, the ASBR needs to know the mapping relationship of the algorithms and carry the converted algorithm information in Algorithm Extended Community when advertising the BGP route.</t>
<t>A BGP speaker can advertise multiple paths for the same address prefix, each path is identified by a Path Identifier in addition to the address prefix <xref target="RFC7911"/>.
By leveraging add-path, multiple loopbacks on the egress node can be avoided. </t>

<t>Same approach is applicable for SRv6 locator which is also advertised via <xref target="RFC2545"/> , SR-MPLS BGP Prefix SID advertisement<xref target="RFC8669"/> and BGP Labeled Unicast(BGP-LU)<xref target="RFC8227"/>. If any Router Reflector existed in the network, it SHOULD support this new Extended Community.</t>

</section>



<section anchor="security-sec" title="Security Considerations">
<t>
TBD
</t>
</section>

<section anchor="iana-sec" title="IANA Considerations">
<t>
IANA is requested to allocate the sub-type TBA1 for "Algorithm Extended Community" under the "BGP Transitive Opaque Extended Community"
</t>
<artwork>
<![CDATA[
     Sub-type Value     Name                            Reference
     ----------------------------------------------------------------
     TBA1                Algorithm Extended Community    This document

]]>
</artwork>
</section>

</middle>
<!--   *****BACK MATTER *****  -->
<back>
<references title="Normative References">
  <?rfc include="reference.RFC.2119"?>
  <?rfc include="reference.RFC.8174"?>
  <?rfc include="reference.RFC.9502"?>
  <?rfc include="reference.RFC.9350"?>
  <?rfc include='reference.RFC.4360'?>
  <?rfc include='reference.RFC.7911'?>
 </references>
 
<references title="Informative References">
  <?rfc include='reference.RFC.8227'?>
  <?rfc include='reference.RFC.8669'?>
  <?rfc include='reference.RFC.2545'?>
  <?rfc include='reference.RFC.4271'?>
  
 </references>
</back>
</rfc>
