<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-li-idr-bgpls-sr-policy-composite-path-06" category="std">
    <?rfc toc="yes"?>
    <?rfc sortrefs="yes"?>
    <front>
        <title abbrev="SR Policy Composite Path in BGP-LS">
            Signaling Composite Candidate Path of SR Policy using BGP-LS
        </title>

        <author initials="H." surname="Li" fullname="Hao Li">
            <organization>New H3C Technologies</organization>
            <address>
                <email>lihao@h3c.com</email>
            </address>
        </author>

        <author initials="M." surname="Chen" fullname="Mengxiao Chen">
            <organization>New H3C Technologies</organization>
            <address>
                <email>chen.mengxiao@h3c.com</email>
            </address>
        </author>

        <author initials="C." surname="Lin" fullname="Changwang Lin">
            <organization>New H3C Technologies</organization>
            <address>
                <email>linchangwang.04414@h3c.com</email>
            </address>
        </author>

        <author initials="W." surname="Jiang" fullname="Wenying Jiang">
            <organization>China Mobile</organization>
            <address>
                <email>jiangwenying@chinamobile.com</email>
            </address>
        </author>
        
        <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
            <organization>China Mobile</organization>
            <address>
                <email>chengweiqiang@chinamobile.com</email>
            </address>
        </author>

        <date month="February" day="26" year="2024" />

        <area>General</area>
        <workgroup>Network Working Group</workgroup>
        <keyword>Segment Routing</keyword>
        <keyword>SR Policy</keyword>
        <keyword>BGP-LS</keyword>
        <abstract>
            <t>Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy.</t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction" toc="include">
            <t>As described in <xref target="RFC7752"></xref>, BGP Link State (BGP-LS) provides a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol.</t>
            <t>Segment routing (SR) <xref target="RFC8402"></xref> is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in <xref target="RFC9256"></xref>.</t>
            <t>An SR Policy is associated with one or more candidate paths. A composite candidate path acts as a container for grouping of SR Policies. As described in section 2.2 in <xref target="RFC9256"></xref>, the composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for a load-balanced steering of packet flows over its constituent SR Policies.</t>
            <t><xref target="I-D.draft-jiang-spring-parent-sr-policy-use-cases"></xref> describes some use cases for SR policy group composite candidate path.</t>
            <t><xref target="I-D.draft-ietf-idr-bgp-ls-sr-policy"></xref> describes a mechanism to collect the SR policy information that is locally available in a node and advertise it into BGP-LS updates. This document extends it to provide some extra information to carry composite candidate path information in the BGP-LS advertisement.</t>
         </section>

        <section title="Terminology" toc="include">
            <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> <xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t>
        </section>

        <section title="BGP-LS Extensions for Composite Candidate Path" toc="default">
            <t><xref target="RFC7752"></xref> defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI or a Prefix NLRI.  The corresponding BGP-LS attribute is a Node Attribute, a Link Attribute or a Prefix Attribute. <xref target="I-D.draft-ietf-idr-bgp-ls-sr-policy"></xref> describes a mechanism to collect the SR Policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. This section defines a new sub-TLV which is carried in the optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in <xref target="RFC7752"></xref>.</t>

            <section title="Constituent SR Policy TLV" toc="default">
                <t>Segment Routing Policy (SR Policy) architecture is specified in <xref target="RFC9256"></xref>. A SR Policy can comprise of one or more candidate paths, and each candidate path is either dynamic, explicit or composite. A composite candidate path can comprise of one or more constituent SR policies. The endpoints of the constituent SR Policies and the parent SR Policy MUST be identical, and the colors of each of the constituent SR Policies and the parent SR Policy MUST be different.</t>
                <t>The Constituent SR Policy TLV is used to report the constituent SR policy(s) of a composite candidate path. The TLV has following format:</t>
                <figure>
                    <artwork>
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             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            RESERVED                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Color                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Weight                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sub-TLVs (variable)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    </artwork>
                </figure>
                <t>
                    where:
                    <list style="symbols">
                        <t>Type: to be assigned by IANA.</t>
                        <t>Length: the total length of the value field not including Type and Length fields.</t>
                        <t>Reserved: 32 bits reserved and MUST be set to 0 on transmission and MUST be ignored on receipt.</t>
                        <t>Color: 4 octets that indicates the color of the constituent SR Policy.</t>
                        <t>Weight: 4 octet field that indicates the weight associated with the SID-List for weighted load-balancing. Refer Section 2.2 and 2.11 of <xref target="RFC9256"></xref>.</t>
                        <t>Sub-TLVs: no sub-TLV is currently defined.</t>
                    </list>
                </t>
            </section>
        </section>
 
        <section title="Operations" toc="default">
            <t>The document does not bring new operation beyond the description of operations defined in <xref target="RFC7752"></xref> and <xref target="I-D.draft-ietf-idr-bgp-ls-sr-policy"></xref>. The existing operations defined in <xref target="RFC7752"></xref> and <xref target="I-D.draft-ietf-idr-bgp-ls-sr-policy"></xref> can apply to this document directly.</t>
            <t>Typically but not limit to, the BGP-LS messages carring composite candidate path information along with the SR policy are distributed to a controller.</t>
            <t>After configuration, the composite candidate path information will be advertised by BGP update messages. The operation of advertisement is the same as defined in <xref target="RFC7752"></xref> and <xref target="I-D.draft-ietf-idr-bgp-ls-sr-policy"></xref>, as well as the receiption.</t>
        </section>

        <section title="Security Considerations">
            <t>Procedures and protocol extensions defined in this document do not affect the security considerations discussed in <xref target="I-D.draft-ietf-idr-bgp-ls-sr-policy"></xref>.</t>
        </section>

        <section title="IANA Considerations">
            <t>This document defines a new TLV in the BGP-LS Link Descriptor and Attribute TLVs:</t>
            <texttable align="left" style="full">
                <ttcol>Value</ttcol>
                <ttcol>Description</ttcol>
                <ttcol>Reference</ttcol>
                <c>TBA</c>
                <c>Constituent SR Policy TLV</c>
                <c>This document</c>
            </texttable>
        </section>
    </middle>

    <back>
        <references title="Normative References">
			<reference anchor="I-D.draft-ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-03">
			  <front>
				<title>Advertisement of Segment Routing Policies using BGP Link-State</title>
				<author fullname="Stefano Previdi" initials="S." surname="Previdi">
				  <organization>Huawei Technologies</organization>
				</author>
				<author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
				  <organization>Cisco Systems</organization>
				</author>
				<author fullname="Jie Dong" initials="J." surname="Dong">
				  <organization>Huawei Technologies</organization>
				</author>
				<author fullname="Hannes Gredler" initials="H." surname="Gredler">
				  <organization>RtBrick Inc.</organization>
				</author>
				<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
				  <organization>Microsoft</organization>
				</author>
				<date day="5" month="November" year="2023"/>
				<abstract>
				  <t>This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc.</t>
				</abstract>
			  </front>
			  <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-03"/>
			</reference>
            <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
                <front>
                <title>
                Key words for use in RFCs to Indicate Requirement Levels
                </title>
                <author initials="S." surname="Bradner" fullname="S. Bradner">
                <organization/>
                </author>
                <date year="1997" month="March"/>
                <abstract>
                <t>
                In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                </t>
                </abstract>
                </front>
                <seriesInfo name="BCP" value="14"/>
                <seriesInfo name="RFC" value="2119"/>
                <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            </reference>
            <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
                <front>
                <title>
                Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
                </title>
                <author initials="B." surname="Leiba" fullname="B. Leiba">
                <organization/>
                </author>
                <date year="2017" month="May"/>
                <abstract>
                <t>
                RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                </t>
                </abstract>
                </front>
                <seriesInfo name="BCP" value="14"/>
                <seriesInfo name="RFC" value="8174"/>
                <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            </reference>
            <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402">
                <front>
                <title>Segment Routing Architecture</title>
                <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
                <organization/>
                </author>
                <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
                <organization/>
                </author>
                <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
                <organization/>
                </author>
                <author initials="B." surname="Decraene" fullname="B. Decraene">
                <organization/>
                </author>
                <author initials="S." surname="Litkowski" fullname="S. Litkowski">
                <organization/>
                </author>
                <author initials="R." surname="Shakir" fullname="R. Shakir">
                <organization/>
                </author>
                <date year="2018" month="July"/>
                <abstract>
                <t>
                Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
                </t>
                <t>
                SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
                </t>
                <t>
                SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
                </t>
                </abstract>
                </front>
                <seriesInfo name="RFC" value="8402"/>
                <seriesInfo name="DOI" value="10.17487/RFC8402"/>
            </reference>
        </references>
        <references title="Informative References">
             <reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9256">
                <front>
                <title>Segment Routing Policy Architecture</title>
                <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
                <organization/>
                </author>
                <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
                <organization/>
                </author>
                <author initials="D" surname="Voyer" fullname="Daniel Voyer">
                <organization/>
                </author>
                <author initials="A" surname="Bogdanov" fullname="Alex Bogdanov">
                <organization/>
                </author>
                <author initials="P" surname="Mattes" fullname="Paul Mattes">
                <organization/>
                </author>
                <date month="July" year="2022"/>
                <abstract>
                <t>
                Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy.
                </t>
				<t>
				This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.
				</t>
                </abstract>
                </front>
                <seriesInfo name="RFC" value="9256"/>
                <seriesInfo name="DOI" value="10.17487/RFC9256"/>
            </reference>
            <reference anchor="RFC7752" target="https://www.rfc-editor.org/info/rfc7752">
                <front>
                <title>
                North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
                </title>
                <author initials="H." surname="Gredler" fullname="H. Gredler" role="editor">
                <organization/>
                </author>
                <author initials="J." surname="Medved" fullname="J. Medved">
                <organization/>
                </author>
                <author initials="S." surname="Previdi" fullname="S. Previdi">
                <organization/>
                </author>
                <author initials="A." surname="Farrel" fullname="A. Farrel">
                <organization/>
                </author>
                <author initials="S." surname="Ray" fullname="S. Ray">
                <organization/>
                </author>
                <date year="2016" month="March"/>
                <abstract>
                <t>
                In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
                </t>
                <t>
                This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
                </t>
                <t>
                Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).
                </t>
                </abstract>
                </front>
                <seriesInfo name="RFC" value="7752"/>
                <seriesInfo name="DOI" value="10.17487/RFC7752"/>
            </reference>
            <reference anchor="I-D.draft-jiang-spring-parent-sr-policy-use-cases">
                <front>
                <title>Use Cases for Parent SR Policy</title>
                <author initials="W" surname="Jiang" fullname="Wenying Jiang">
                <organization/>
                </author>
                <author initials="W" surname="Cheng" fullname="Weiqiang Cheng">
                <organization/>
                </author>
                <author initials="C" surname="Lin" fullname="Changwang Lin">
                <organization/>
                </author>
                <author initials="Y" surname="Qiu" fullname="Yuanxiang Qiu">
                <organization/>
                </author>
                <date month="January" day="5" year="2024"/>
                <abstract>
                <t>
                Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy.
                </t>
                </abstract>
                </front>
                <seriesInfo name="Internet-Draft" value="draft-jiang-spring-parent-sr-policy-use-cases-03"/>
                <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-jiang-spring-parent-sr-policy-use-cases-03.txt"/>
            </reference>
        </references>

    </back>
</rfc>