<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ietf-idr-bgp-sr-segtypes-ext-08"
     ipr="trust200902"> number="9831" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3" version="3">

  <front>

<!--[rfced] Is the document title redundant (especially if the
     abbreviation is expanded)?  If our suggested title is not
     agreeable, please let us know if a rephrase can be made.  Note
     that we have updated to use "Segment Type Extensions" (with Type
     singular).  Note that any changes to the document title will also
     be reflected in the reference entry pointing to this document in
     RFC-to-be 9830.

Original:
Segment Routing Segment Types Extensions for BGP SR Policy

As it would be expanded:
Segment Routing Segment Types Extensions for BGP Segment Routing Policy

Perhaps:
Segment Type Extensions for BGP Segment Routing (SR) Policy

With a corresponding update to the abbreviated title:

Original:
SR Segment Type Ext for BGP SR Policy

Perhaps:
Segment Type Ext for BGP SR Policy
-->

    <title abbrev="SR Segment Type Ext for BGP SR Policy">Segment Routing
    Segment Types Extensions for BGP SR Policy</title>
    <seriesInfo name="RFC" value="9831"/>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city>Brussels</city>

          <region/>

          <code/>

          <country>BE</country>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>IT</country>
          <country>Italy</country>
        </postal>
        <email>stefano@previdi.net</email>
      </address>
    </author>
    <author fullname="Paul Mattes" initials="P." surname="Mattes">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>pamattes@microsoft.com</email>
      </address>
    </author>
    <author fullname="Dhanendra Jain" initials="D." surname="Jain">
      <organization>Google</organization>
      <address>
        <email>dhanendra.ietf@gmail.com</email>
      </address>
    </author>

    <date/>
    <date month="August" year="2025"/>

    <area>RTG</area>
    <workgroup>idr</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This document specifies the signaling of additional Segment Routing (SR)
      Segment Types for signaling of Segment Routing (SR) SR Policies in BGP
      using the SR Policy Subsequent Address Family Identifier.</t> Identifier (SAFI).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction">
      <t>BGP numbered="true" toc="default">
      <name>Introduction</name>
      <t>The BGP Segment Routing (SR) Policy Subsequent Address Family Identifier
      (SAFI) was introduced by <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/>
      for the advertisement of SR Policy Policies <xref target="RFC8402"/>. target="RFC8402" format="default"/>. <xref
      target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/> introduced the base SR Segment
      Types A and B as specified by the SR Policy Architecture <xref
      target="RFC9256"/>.</t> target="RFC9256" format="default"/>.</t>
      <t>This document specifies the extensions for the advertisement of the
      remaining SR Segment Types defined in <xref target="RFC9256"/> target="RFC9256" format="default"/> in the SR
      Policy SAFI for both SR-MPLS (see <xref target="RFC8660"/> target="RFC8660" format="default"/>) and SRv6 Segment Routing over IPv6 (SRv6) (see <xref
      target="RFC8754"/> target="RFC8754" format="default"/> and <xref target="RFC8986"/>.</t> target="RFC8986" format="default"/>).</t>
      <t>The extensions in this document do not impact the SR Policy
      operations or fault management as specified in <xref
      target="I-D.ietf-idr-sr-policy-safi"/>.</t> target="RFC9830" format="default"/>.</t>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="SEGMENTTLV" title="Segment Type Sub-TLVs"> numbered="true" toc="default">
      <name>Segment Type Sub-TLVs</name>

<!--[rfced] Section 2: Please review and confirm that the switch
     between "Segment List sub-TLV" in the first paragraph and
     "Segment sub-TLV" in the second is intentional.

Original:

The Segment List sub-TLV [I-D.ietf-idr-sr-policy-safi] encodes a....

and

A Segment sub-TLV describes a single segment in a segment list (i.e.,

-->

      <t>The Segment List sub-TLV <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/>
      encodes a single explicit path towards the endpoint as described in
      section 5.1 of
      <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="5.1"/>. The Segment List sub-TLV
      includes the elements of the paths (i.e., segments).</t>
      <t>A Segment sub-TLV describes a single segment in a segment list (i.e.,
      a single element of the explicit path).</t>

      <t>Section 4 of <xref target="RFC9256"/>
      <t><xref target="RFC9256" sectionFormat="of" section="4"/> defines several Segment Types
      for SR-MPLS and SRv6 that are listed below as a reminder:<figure
          align="center">
          <artwork align="left"><![CDATA[Type  A: SR-MPLS Label
Type  B: SRv6 SID
Type  C: IPv4 reminder:</t>

      <dl spacing="normal" newline="false" indent="10">
	<dt>Type A:</dt><dd>SR-MPLS Label</dd>
	<dt>Type B:</dt><dd>SRv6 SID</dd>
	<dt>Type C:</dt><dd>IPv4 Prefix with optional SR Algorithm
Type  D: IPv6 Algorithm</dd>
	<dt>Type D:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
Type  E: IPv4 SR-MPLS</dd>
	<dt>Type E:</dt><dd>IPv4 Prefix with Local Interface ID
Type  F: IPv4 ID</dd>
	<dt>Type F:</dt><dd>IPv4 Addresses for link endpoints as Local, Remote pair
Type  G: IPv6 pair</dd>
	<dt>Type G:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS
Type  H: IPv6 SR-MPLS</dd>
	<dt>Type H:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS
Type  I: IPv6 SR-MPLS</dd>
	<dt>Type I:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SRv6
Type  J: IPv6 SRv6</dd>
	<dt>Type J:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6
Type  K: IPv6 SRv6</dd>
	<dt>Type K:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for SRv6

Figure 1: SR Segment Types

]]></artwork>
        </figure></t> SRv6</dd>
      </dl>

      <t><xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/> specifies Segment Type
      Sub-TLVs for the segment types Segment Types A and B. The following sub-sections subsections
      specify the sub-TLVs used for encoding each of the other Segment Types
      above.</t>

      <t>As

<!-- [rfced] The following text from Section 2 may require
     clarification:

"As specified in sections Sections 2.4.4 and 2.4.4.2 of <xref
      target="I-D.ietf-idr-sr-policy-safi"/>, [RFC9830],
validation of an explicit path encoded by the Segment List sub-TLV
is beyond the scope of BGP and performed by the Segment Routing
Policy Module (SRPM) as described in
      section Section 5 of [RFC9256]."

The term "Segment Routing Policy Module (SRPM)" doesn't appear in
[RFC9256].

-->

<!--[rfced] The following text led us to believe that the subsection
     titles of Section 2 would match the Type names listed in Section
     2 itself: but they do not.  Please review and let us know if a
     closer 1:1 matchup is desired between these.

Original:
[I-D.ietf-idr-sr-policy-safi] specifies Segment Type Sub-TLVs for the
segment types A and B.  The following sub-sections specify the sub-
TLVs used for encoding each of the other Segment Types above.

-->

      <t>As specified in Sections <xref target="RFC9830" sectionFormat="bare" section="2.4.4"/> and <xref target="RFC9830" sectionFormat="bare" section="2.4.4.2"/> of <xref target="RFC9830" format="default"/>, validation of an explicit path
      encoded by the Segment List sub-TLV is beyond the scope of BGP and
      performed by the Segment Routing Policy Module (SRPM) as described in
      <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="5"/>. As specified in section 5.1 of
      <xref target="RFC9256"/>, target="RFC9256" sectionFormat="of" section="5.1"/>, a mix of SR-MPLS and SRv6 segments make the
      segment-list invalid.</t>
      <section anchor="TYPEC"
               title="Segment numbered="true" toc="default">
        <name>Segment Type C - C: SR-MPLS Prefix SID for IPv4"> IPv4</name>
        <t>The Type C Segment Sub-TLV sub-TLV encodes an IPv4 node address, SR
        Algorithm, and an optional SR-MPLS SID. Segment Identifier (SID). The format is as follows:
        <figure align="center">
        </t>
<figure>
  <name>Type C Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     |  SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Type C Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 3.</t>

            <t>Length: Specifies
]]></artwork>
</figure>

<t>Where:</t>

<dl spacing="normal" newline="false">
  <dt>Type:</dt><dd>3</dd>
  <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
  including Type and Length fields) in terms of octets. The value
            MUST
  <bcp14>MUST</bcp14> be 10 when the SR-MPLS SID is present, else present; else, it MUST
  <bcp14>MUST</bcp14> be 6.</t>

            <t>Flags: 1 6.</dd>
  <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>SR Algorithm: 1-octet
  target="SEGMENTFLAGS" format="default"/>.</dd>
  <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as described in
            section 3.1.1 in
  <xref target="RFC8402"/> target="RFC8402" sectionFormat="of" section="3.1.1"/> when the A-Flag as
  defined in <xref target="SEGMENTFLAGS"/> target="SEGMENTFLAGS" format="default"/> is set. The SR
  Algorithm is used by the SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830"
  format="default"/> as described in
            section 4 in <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of"
  section="4"/>. When the A-Flag is not set, this field MUST <bcp14>MUST</bcp14> be set
  to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>IPv4 receipt.</dd>
  <dt>IPv4 Node Address: a Address:</dt><dd>A 4-octet IPv4 address representing a
            node.</t>

            <t>SR-MPLS SID: optional,
  node.</dd>

  <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label, TC, S Traffic Class (TC), bottom-of-stack (S), and
  TTL as defined for Segment Type A <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t> target="RFC9830"
  format="default"/>.</dd>
</dl>

      </section>
      <section anchor="TYPED"
               title="Segment numbered="true" toc="default">
        <name>Segment Type D - D: SR-MPLS Prefix SID for IPv6"> IPv6</name>
        <t>The Type D Segment Sub-TLV sub-TLV encodes an IPv6 node address, SR
        Algorithm, and an optional SR-MPLS SID. The format is as follows:
        <figure align="center">
        </t>

<figure>
  <name>Type D Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     |  SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Node Address (16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Type D Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 4</t>

            <t>Length: Specifies
]]></artwork>
</figure>
	<t>Where:</t>

	<dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>4</dd>
          <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be 22 when the SR-MPLS SID is present, else present; else, it MUST
          <bcp14>MUST</bcp14> be
            18.</t>

            <t>Flags: 1 18.</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>SR Algorithm: 1-octet
          target="SEGMENTFLAGS" format="default"/>.</dd>
          <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
          described in
            section 3.1.1 in <xref target="RFC8402"/> target="RFC8402" sectionFormat="of"
          section="3.1.1"/> when the A-Flag as defined in <xref target="SEGMENTFLAGS"/>
          target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
          used by the SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830"
          format="default"/> as described in
            section 4 in <xref target="RFC9256"/>. target="RFC9256"
          sectionFormat="of" section="4"/>. When the A-Flag is not set, this field MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>IPv6 receipt.</dd>
          <dt>IPv6 Node Address: a Address:</dt><dd>A 16-octet IPv6 address representing
          a
            node.</t>

            <t>SR-MPLS SID: optional, node.</dd>
          <dt>SR-MPLS SID:</dt><dd>Optional.  A 4-octet field containing a label,
          TC, S S, and TTL as defined for Segment Type A <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t>
          target="RFC9830" format="default"/>.</dd>
        </dl>
      </section>
      <section anchor="TYPEE"
               title="Segment numbered="true" toc="default">
        <name>Segment Type E - E: SR-MPLS Adjacency SID for IPv4 with an Interface ID"> ID</name>
        <t>The Type E Segment Sub-TLV sub-TLV encodes an IPv4 node address, a local
        interface Identifier (Local Interface ID), and an optional SR-MPLS
        SID. The format is as follows: <figure align="center"> </t>

<figure>
  <name>Type E Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Interface ID (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Type E Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 5.</t>

            <t>Length: Specifies
]]></artwork>
</figure>

<t>Where:</t>

<dl spacing="normal" newline="false">
  <dt>Type:</dt><dd>5</dd>
  <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
  including Type and Length fields) in terms of octets. The value
            MUST
  <bcp14>MUST</bcp14> be 14 when the SR-MPLS SID is present, else present; else, it MUST
  <bcp14>MUST</bcp14> be
            10.</t>

            <t>Flags: 1 10.</dd>
  <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>RESERVED: 1
  target="SEGMENTFLAGS" format="default"/>.</dd>
  <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST
  <bcp14>MUST</bcp14> be set to zero on transmission and MUST <bcp14>MUST</bcp14>
  be ignored on receipt.</t>

            <t>Local receipt.</dd>

<!--[rfced] Please consider rephrasing the following text (the stacked
     uses of "of" and repetition of "interface" might benefit from a
     change).

Original:
   Local Interface ID:  4 octets of interface index of local interface
      (refer TLV 258 of [RFC9552]).

-->
  <dt>Local Interface ID:</dt><dd>4 octets of interface index of local
  interface (refer to TLV 258 of <xref target="RFC9552"/>).</t>

            <t>IPv4 target="RFC9552" format="default"/>).</dd>
  <dt>IPv4 Node Address: a Address:</dt><dd>A 4-octet IPv4 address representing a
            node.</t>

            <t>SR-MPLS SID: optional,
  node.</dd>
  <dt>SR-MPLS SID:</dt><dd>Optional.  A 4-octet field containing a label, TC, S S, and
  TTL as defined for Segment Type A <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t> target="RFC9830"
  format="default"/>.</dd>
</dl>
      </section>
      <section anchor="TYPEF"
               title="Segment numbered="true" toc="default">
        <name>Segment Type F - F: SR-MPLS Adjacency SID for IPv4 with an Interface Address"> Address</name>
        <t>The Type F Segment Sub-TLV sub-TLV encodes an adjacency local address, an
        adjacency remote address, and an optional SR-MPLS SID. The format is
        as follows: <figure align="center"> </t>

<figure>
  <name>Type F Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Local IPv4 Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Remote IPv4 Address  (4 octets)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Type F Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 6.</t>

            <t>Length: Specifies
]]></artwork>
</figure>

<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>6</dd>
          <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be 14 when the SR-MPLS SID is present, else present; else, it MUST
          <bcp14>MUST</bcp14> be
            10.</t>

            <t>Flags: 1 10.</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>RESERVED: 1
          target="SEGMENTFLAGS" format="default"/>.</dd>
          <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Local receipt.</dd>
          <dt>Local IPv4 Address: a Address:</dt><dd>A 4-octet IPv4 address representing
          the local link address of the node.</t>

            <t>Remote node.</dd>
          <dt>Remote IPv4 Address: a Address:</dt><dd>A 4-octet IPv4 address representing
          the link address of the neighbor node.</t>

            <t>SR-MPLS SID: optional, node.</dd>
          <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label,
          TC, S S, and TTL as defined for Segment Type A <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t>
          target="RFC9830" format="default"/>.</dd>
        </dl>
      </section>
      <section anchor="TYPEG"
               title="Segment numbered="true" toc="default">
        <name>Segment Type G - G: SR-MPLS Adjacency SID for IPv6 with an Interface ID"> ID</name>
        <t>The Type G Segment Sub-TLV sub-TLV encodes an IPv6 link-local adjacency
        with an IPv6 local node address, a local interface identifier (Local
        Interface ID), an IPv6 remote node address, a remote interface identifier
        (Remote Interface ID), and an optional SR-MPLS SID. The format is as
        follows: <figure align="center"> </t>

<figure>
  <name>Type G Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Interface ID (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Local Node Address (16 octets)          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Remote Interface ID (4 octets)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Remote Node Address (16 octets)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Type G Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 7</t>

            <t>Length: Specifies
]]></artwork>
</figure>
<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>7</dd>
          <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be 46 when the SR-MPLS SID is present, else present; else, it MUST
          <bcp14>MUST</bcp14> be
            42.</t>

            <t>Flags: 1 42.</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>RESERVED: 1
          target="SEGMENTFLAGS" format="default"/>.</dd>
          <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Local receipt.</dd>
          <dt>Local Interface ID: 4 ID:</dt><dd>4 octets of interface index of local
          interface (refer to TLV 258 of <xref target="RFC9552"/>).</t>

            <t>IPv6 target="RFC9552"
          format="default"/>).</dd>
          <dt>IPv6 Local Node Address: a Address:</dt><dd>A 16-octet IPv6 address
          representing the node.</t>

            <t>Remote node.</dd>
          <dt>Remote Interface ID: 4 ID:</dt><dd>4 octets of interface index of
          remote interface (refer to TLV 258 of <xref target="RFC9552"/>). target="RFC9552"
          format="default"/>). The value
            MAY <bcp14>MAY</bcp14> be set to zero
          when the local node address and interface identifiers are sufficient
          to describe the link.</t>

            <t>IPv6 link.</dd>
          <dt>IPv6 Remote Node Address: a Address:</dt><dd>A 16-octet IPv6 address. The
          value
            MAY <bcp14>MAY</bcp14> be set to zero when the local node address
          and interface identifiers are sufficient to describe the link.</t>

            <t>SR-MPLS SID: optional, link.</dd>
          <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label,
          TC, S S, and TTL as defined for Segment Type A <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t>
          target="RFC9830" format="default"/>.</dd>
        </dl>
      </section>
      <section anchor="TYPEH"
               title="Segment numbered="true" toc="default">
        <name>Segment Type H - H: SR-MPLS Adjacency SID for IPv6 with an Interface Address"> Address</name>
        <t>The Type H Segment Sub-TLV sub-TLV encodes an adjacency local address, an
        adjacency remote address, and an optional SR-MPLS SID. The format is
        as follows: <figure align="center"> </t>

<figure>
  <name>Type H Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Local IPv6 Address (16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Remote IPv6 Address  (16 octets)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Type H Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 8</t>

            <t>Length: Specifies
]]></artwork>
</figure>
<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>8</dd>
          <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be 38 when the SR-MPLS SID is present, else present; else, it MUST
          <bcp14>MUST</bcp14> be
            34.</t>

            <t>Flags: 1 34.</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>RESERVED: 1
          target="SEGMENTFLAGS" format="default"/>.</dd>
	  <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field MUST
	  <bcp14>MUST</bcp14> be set to zero on transmission and MUST
	  <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Local receipt.</dd>
          <dt>Local IPv6 Address: a Address:</dt><dd>A 16-octet IPv6 address
          representing the local link address of the node.</t>

            <t>Remote node.</dd>
          <dt>Remote IPv6 Address: a Address:</dt><dd>A 16-octet IPv6 address
          representing the link address of the neighbor node.</t>

            <t>SR-MPLS SID: optional, node.</dd>
          <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label,
          TC, S S, and TTL as defined for Segment Type A <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t>
          target="RFC9830" format="default"/>.</dd>
        </dl>
      </section>
      <section anchor="TYPEI"
               title="Segment numbered="true" toc="default">
        <name>Segment Type I - I: SRv6 END SID as IPv6 Node Address"> Address</name>
        <t>The Type I Segment Sub-TLV sub-TLV encodes an IPv6 node address, an SR
        Algorithm, and an optional SRv6 SID. The format is as follows: <figure
            align="center"> </t>

<figure>
  <name>Type I Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     | SR Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                 IPv6 Node Address (16 octets)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                    SRv6 SID (optional, 16 octets)           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Type I Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 14</t>

            <t>Length: Specifies
]]></artwork>
</figure>
<t>Where:</t>

        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>14</dd>
          <dt>Length:</dt><dd><t>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be one of: 42 of the following:</t>
	  <ul spacing="compact">
	    <li>42 when both SRv6 SID and SRv6
            Endpoint Behavior
            &amp; and SID Structure are present, 34 present,</li>
	    <li>34 when only SRv6
            SID is present,
            or 18 or</li>
	    <li>18 when the SRv6 SID is not present.</t>

            <t>Flags: 1 present.</li>
	  </ul>
	</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>SR Algorithm: 1
          target="SEGMENTFLAGS" format="default"/>.</dd>
          <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
          described in
            section 3.1.1 in <xref target="RFC8402"/> target="RFC8402" sectionFormat="of"
          section="3.1.1"/> when the A-Flag as defined in <xref target="SEGMENTFLAGS"/>
          target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
          used by the SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830"
          format="default"/> as described in
            section 4 in <xref target="RFC9256"/>. target="RFC9256"
          sectionFormat="of" section="4"/>. When the A-Flag is not set, this field MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>IPv6 receipt.</dd>
          <dt>IPv6 Node Address: a Address:</dt><dd>A 16-octet IPv6 address representing
          the
            node.</t>

            <t>SRv6 SID: optional, a node.</dd>
          <dt>SRv6 SID:</dt><dd>Optional.  A 16-octet IPv6 address. The value 0 MAY
          <bcp14>MAY</bcp14> be used when the controller wants to indicate the
          desired SRv6 Endpoint Behavior or SID Structure without specifying
          the SID.</t>

            <t>SRv6 SID.</dd>
          <dt>SRv6 Endpoint Behavior and SID Structure: Optional, Structure:</dt><dd>Optional, as
          defined in section 2.4.4.2.4 of <xref
            target="I-D.ietf-idr-sr-policy-safi"/>. target="RFC9830"
          sectionFormat="of" section="2.4.4.2.4"/>. The SRv6 Endpoint Behavior
          and SID Structure MUST NOT <bcp14>MUST NOT</bcp14> be included when the SRv6
          SID has not been included.</t>
          </list></t>

        <t>The TLV included.</dd>
        </dl>
        <t>TLV 10 defined for the advertisement of Segment Type I in the
        early draft versions of <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/>
        has been deprecated to avoid backward compatibility backward-compatibility issues.</t>
      </section>
      <section anchor="TYPEJ"
               title="Segment numbered="true" toc="default">
        <name>Segment Type J - J: SRv6 END.X SID as an Interface ID"> ID</name>
        <t>The Type J Segment Sub-TLV sub-TLV encodes an IPv6 link-local adjacency
        with a local node address, a local interface identifier (Local Interface
        ID), a remote IPv6 node address, a remote interface identifier (Remote
        Interface ID), and an optional SRv6 SID. The format is as follows:
        <figure align="center">
        </t>
<figure>
  <name>Type J Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     | SR Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Interface ID (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Local Node Address (16 octets)          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Remote Interface ID (4 octets)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Remote Node Address (16 octets)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                SRv6 SID (optional, 16 octets)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Type J Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 15</t>

            <t>Length: Specifies
]]></artwork>
</figure>

	<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>15</dd>
          <dt>Length:</dt><dd><t>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be one of: 66 of the following:</t>
	  <ul spacing="compact">
	    <li>66 when both SRv6 SID and SRv6
            Endpoint Behavior
            &amp; and SID Structure are present, 58 present,</li>
	    <li>58 when only SRv6 SID is present,
            or 42 or</li>
	    <li>42 when the SRv6 SID is not present.</t>

            <t>Flags: 1 present.</li>
	  </ul>
	</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>SR Algorithm: 1-octet
          target="SEGMENTFLAGS" format="default"/>.</dd>
          <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
          described in
            section 3.1.1 in <xref target="RFC8402"/> target="RFC8402" sectionFormat="of"
          section="3.1.1"/> when the A-Flag as defined in <xref target="SEGMENTFLAGS"/>
          target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
          used by the SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830"
          format="default"/> as described in
            section 4 in <xref target="RFC9256"/>. target="RFC9256"
          sectionFormat="of" section="4"/>. When the A-Flag is not set, this field MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Local receipt.</dd>
          <dt>Local Interface ID: 4 ID:</dt><dd>4 octets of interface index of local
          interface (refer to TLV 258 of <xref target="RFC9552"/>).</t>

            <t>IPv6 target="RFC9552"
          format="default"/>).</dd>
          <dt>IPv6 Local Node Address: a Address:</dt><dd>A 16-octet IPv6 address
          representing the node.</t>

            <t>Remote node.</dd>
          <dt>Remote Interface ID: 4 ID:</dt><dd>4 octets of interface index of
          remote interface (refer to TLV 258 of <xref target="RFC9552"/>). target="RFC9552"
          format="default"/>). The value
            MAY <bcp14>MAY</bcp14> be set to zero
          when the local node address and interface identifiers are sufficient
          to describe the link.</t>

            <t>IPv6 link.</dd>
          <dt>IPv6 Remote Node Address: a Address:</dt><dd>A 16-octet IPv6 address. The
          value
            MAY <bcp14>MAY</bcp14> be set to zero when the local node address
          and interface identifiers are sufficient to describe the link.</t>

            <t>SRv6 SID: optional, a link.</dd>
          <dt>SRv6 SID:</dt><dd>Optional.  A 16-octet IPv6 address. The value 0 MAY
          <bcp14>MAY</bcp14> be used when the controller wants to indicate the
          desired SRv6 Endpoint Behavior or SID Structure without specifying
          the SID.</t>

            <t>SRv6 SID.</dd>

<!-- [rfced] We note that Section 2.4.4.2.4 of [RFC9830] uses the term
     "SRv6 SID Endpoint Behavior and Structure" rather than "SRv6
     Endpoint Behavior and SID Structure".  Please let us know if/how
     these uses may be made consistent.
-->
          <dt>SRv6 Endpoint Behavior and SID Structure: Optional, Structure:</dt><dd>Optional, as
          defined in section 2.4.4.2.4 of <xref
            target="I-D.ietf-idr-sr-policy-safi"/>. target="RFC9830"
          sectionFormat="of" section="2.4.4.2.4"/>. The SRv6 Endpoint Behavior
          and SID Structure MUST NOT <bcp14>MUST NOT</bcp14> be included when the SRv6
          SID has not been included.</t>
          </list></t>

        <t>The TLV included.</dd>
        </dl>
        <t>TLV 11 defined for the advertisement of Segment Type J in the
        early draft versions of <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/>
        has been deprecated to avoid backward compatibility backward-compatibility issues.</t>
      </section>
      <section anchor="TYPEK"
               title="Segment numbered="true" toc="default">
        <name>Segment Type K - K: SRv6 END.X SID as an Interface Address"> Address</name>
        <t>The Type K Segment Sub-TLV sub-TLV encodes an adjacency local address, an
        adjacency remote address, and an optional SRv6 SID. The format is as
        follows: <figure align="center"> </t>

<figure>
  <name>Type K Segment Sub-TLV</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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      |   Length      |     Flags     | SR Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Local IPv6 Address (16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Remote IPv6 Address  (16 octets)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                SRv6 SID (optional, 16 octets)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Type K Segment sub-TLV

where:]]></artwork>
          </figure><list style="symbols">
            <t>Type: 16</t>

            <t>Length: Specifies
]]></artwork>
</figure>
	<t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>16</dd>
          <dt>Length:</dt><dd><t>Specifies the length of the value field (i.e.,
          not including Type and Length fields) in terms of octets. The value
            MUST
          <bcp14>MUST</bcp14> be one of: 58 of the following:</t>
	  <ul spacing="compact">
	    <li>58 when both SRv6 SID and SRv6
            Endpoint Behavior
            &amp; and SID Structure are present, 50 present,</li>
	    <li>50 when only SRv6
            SID is present,
            or 34 or</li>
	    <li>34 when the SRv6 SID is not present.</t>

            <t>Flags: 1 present.</li>
	  </ul>
	</dd>
          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
            target="SEGMENTFLAGS"/>.</t>

            <t>SR Algorithm: 1-octet
          target="SEGMENTFLAGS" format="default"/>.</dd>
          <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
          described in
            section 3.1.1 in <xref target="RFC8402"/> target="RFC8402" sectionFormat="of"
          section="3.1.1"/> when the A-Flag as defined in <xref target="SEGMENTFLAGS"/>
          target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
          used by the SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830"
          format="default"/> as described in
            section 4 in <xref target="RFC9256"/>. target="RFC9256"
          sectionFormat="of" section="4"/>. When the A-Flag is not set, this field MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Local receipt.</dd>
          <dt>Local IPv6 Address: a Address:</dt><dd>A 16-octet IPv6 address representing
          the local link address of the node.</t>

            <t>Remote node.</dd>
          <dt>Remote IPv6 Address: a Address:</dt><dd>A 16-octet IPv6 address
          representing the link address of the neighbor node.</t>

            <t>SRv6 SID: optional, a node.</dd>
          <dt>SRv6 SID:</dt><dd>Optional.  A 16-octet IPv6 address. The value 0 MAY
          <bcp14>MAY</bcp14> be used when the controller wants to indicate the
          desired SRv6 Endpoint Behavior or SID Structure without specifying
          the SID.</t>

            <t>SRv6 SID.</dd>
          <dt>SRv6 Endpoint Behavior and SID Structure: Optional, Structure:</dt><dd>Optional, as
          defined in section 2.4.4.2.4 of <xref
            target="I-D.ietf-idr-sr-policy-safi"/>. target="RFC9830"
          sectionFormat="of" section="2.4.4.2.4"/>. The SRv6 Endpoint Behavior
          and SID Structure MUST NOT <bcp14>MUST NOT</bcp14> be included when the SRv6
          SID has not been included.</t>
          </list></t>

        <t>The TLV included.</dd>
        </dl>
        <t>TLV 12 defined for the advertisement of Segment Type K in the
        early draft versions of <xref target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/>
        has been deprecated to avoid backward compatibility backward-compatibility issues.</t>
      </section>
      <section anchor="SEGMENTFLAGS" title="SR numbered="true" toc="default">
        <name>SR Policy Segment Flags"> Flags</name>
        <t>The Segment Types Type sub-TLVs described above may contain the
        following SR Policy Segment Flags <xref
        target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/> in their "Flags" field. Also
        refer to Flags field (see also
        <xref target="IANASIDFLAGS"/>. target="IANASIDFLAGS" format="default"/>). This document introduces
        additional flags as below:<figure align="center"> below:</t>

<figure>
  <name>SR Policy Segment Flags</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A|S|B|       |
+-+-+-+-+-+-+-+-+

Figure 11: SR Policy Segment Flags
]]></artwork>
</figure> where:<list>
            <t>V-Flag:
        <t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>V-Flag:</dt><dd>This is an existing flag as defined in <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>

            <t>A-Flag: This flag, when
          target="RFC9830" format="default"/>.</dd>
          <dt>A-Flag:</dt><dd>When set, this flag indicates the presence of
          the SR Algorithm id in the "SR Algorithm" SR Algorithm field applicable to various
          Segment Types. The SR Algorithm is used by the SRPM <xref
            target="I-D.ietf-idr-sr-policy-safi"/>
          target="RFC9830" format="default"/> as described
          in section 4
            of <xref target="RFC9256"/>.</t>

            <t>S-Flag: This flag, when target="RFC9256" sectionFormat="of" section="4"/>.</dd>
          <dt>S-Flag:</dt><dd>When set, this flag indicates the presence of
          the SR-MPLS or SRv6 SID depending on the segment type.</t>

            <t>B-Flag: type.</dd>
          <dt>B-Flag:</dt><dd>This is an existing flag as defined in <xref
            target="I-D.ietf-idr-sr-policy-safi"/>.</t>
          </list></t>
          target="RFC9830" format="default"/>.</dd>
        </dl>
        <t>The following applies to the Segment Flags:<list style="symbols">
            <t>V-Flag Flags:</t>
        <ul spacing="normal">
          <li>
            <t>The V-Flag applies to all Segment Types including the ones those
            introduced by this document.</t>

            <t>A-Flag
          </li>
          <li>
            <t>The A-Flag applies to Segment Types C, D, I, J, and K. The value of
            the A-Flag MUST <bcp14>MUST</bcp14> be ignored for Segment Types A, B, E, F, G, and H.</t>

            <t>S-Flag
          </li>
          <li>
            <t>The S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K.
            The value of the S-Flag MUST <bcp14>MUST</bcp14> be ignored for Segment Types A and B.</t>

            <t>B-Flag
          </li>
          <li>
            <t>The B-Flag applies to Segment Types B, I, J, and K. The value of
            the B-Flag MUST <bcp14>MUST</bcp14> be ignored for Segment Types A, C, D, E, F, G, and
            H.</t>
          </list></t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This section covers the IANA considerations for this document.</t> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="IANASIDLIST" title="SR numbered="true" toc="default">

<!--[rfced] Please review the entries in Table 1 in light of this response regarding the names of sub-TLVs from Ketan when we discussed this topic for RFC-to-be 9830:

Ketan:
"The names of the segments (titles) are to be "Segment Type X" while the name of the sub-TLVs are to be "Type X Segment sub-TLV" (I've seen both sub-TLV and Sub-TLV - either is OK but we should have been consistent). The "Type-1" is actually "Type A Segment sub-TLV"."

If updates are necessary to the corresponding IANA registry, we will
communicate them on your behalf once AUTH48 concludes.

-->

        <name>SR Policy Segment List Sub-TLVs">
        <t>This document requests the allocation of Sub-TLVs</name>
        <t>IANA has allocated the following code points
        from the "SR Policy Segment List Sub-TLVs" registry <xref
        target="I-D.ietf-idr-sr-policy-safi"/>
        target="RFC9830" format="default"/> under the "BGP "Border Gateway Protocol (BGP)
        Tunnel Encapsulation" registry group.</t>

        <t><figure align="center">
            <artwork align="center"><![CDATA[Value   Description                     Reference
-----------------------------------------------------
  3

	<table>
	  <name>SR Policy Segment List Code Points</name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Description</th>
              <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>3</td>
	      <td>Segment Type C sub-TLV           This document
  4    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>4</td>
	      <td>Segment Type D sub-TLV           This document
  5    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>5</td>
	      <td>Segment Type E sub-TLV           This document
  6    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>6</td>
	      <td>Segment Type F sub-TLV           This document
  7    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>7</td>
	      <td>Segment Type G sub-TLV           This document
  8    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>8</td>
	      <td>Segment Type H sub-TLV           This document
 14    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>14</td>
	      <td>Segment Type I sub-TLV           This document
 15    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>15</td>
	      <td>Segment Type J sub-TLV           This document
 16    Segment sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	    <tr>
	      <td>16</td>
	      <td>Segment Type K sub-TLV           This document

     Table 1: SR Policy Segment List Code Points

]]></artwork>
          </figure></t> sub-TLV</td>
              <td>RFC 9831</td>
	    </tr>
	  </tbody>
	</table>

      </section>
      <section anchor="IANASIDFLAGS" title="SR numbered="true" toc="default">
        <name>SR Policy Segment Flags">
        <t>This document requests the allocation of Flags</name>
        <t>IANA has allocated code points from the "SR
        Policy Segment Flags" registry <xref
        target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/> under the "BGP "Border Gateway Protocol (BGP) Tunnel
        Encapsulation" registry group.</t>

        <t><figure align="center">
            <artwork align="center"><![CDATA[ Bit     Description                                Reference
------------------------------------------------------------------
   1     SR

<table>
  <name>SR Policy Segment Flags</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>SR Algorithm Flag (A-Flag)                 This document
   2     SID (A-Flag)</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>2</td>
      <td>SID Specified Flag (S-Flag)                This document

     Table 2: SR Policy Segment Flags
                                ]]></artwork>
          </figure></t> (S-Flag)</td>
      <td>This document</td>
    </tr>
  </tbody>
  </table>

      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations in <xref
      target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/> apply to the segment types Segment Types
      defined in this document. No additional security considerations are
      introduced in this document.</t>
      introduced.</t>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>The operations and manageability considerations in <xref
      target="I-D.ietf-idr-sr-policy-safi"/> target="RFC9830" format="default"/> apply to the segment types
      Segment Types
      defined in this document. No additional operations and manageability
      considerations are introduced in this document.</t> introduced.</t>
    </section>
  </middle>
  <back>

      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- [RFC9830]
draft-ietf-idr-sr-policy-safi-13 companion doc RFC 9830.
-->

<reference anchor="RFC9830" target="https://www.rfc-editor.org/info/rfc9830">
  <front>
      <title>Advertising Segment Routing Policies in BGP</title>
      <author initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="P." surname="Mattes" fullname="Paul Mattes">
         <organization>Microsoft</organization>
      </author>
      <author initials="D." surname="Jain" fullname="Dhanendra Jain">
         <organization>Google</organization>
      </author>
    <date month='August' year='2025'/>
  </front>
  <seriesInfo name="RFC" value="9830"/>
  <seriesInfo name="DOI" value="10.17487/RFC9830"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
      </references>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors of this document would like to Dan Romascanu, Stig
      Venaas, and Russ Housley <contact fullname="Dan Romascanu"/>, <contact fullname="Stig
      Venaas"/>, and <contact fullname="Russ Housley"/> for their comments and review of this document. review.
      The authors would like to thank Susan Hares <contact fullname="Susan Hares"/> for her detailed shepherd
      review that helped in improving the document.</t>
    </section>
  </middle>

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

      <?rfc include="reference.RFC.8174"?>

      <?rfc include="reference.I-D.ietf-idr-sr-policy-safi"?>

      <?rfc include="reference.RFC.8402"?>

      <?rfc include="reference.RFC.8660"?>

      <?rfc include="reference.RFC.9552"?>

      <?rfc include="reference.RFC.8754"?>

      <?rfc include="reference.RFC.9256"?>

      <?rfc include="reference.RFC.8986"?>
    </references>

    <references title="Informational References"/>

<!-- [rfced] FYI - We have added expansions for abbreviations upon
     first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
     review each expansion in the document carefully to ensure
     correctness.
-->

<!-- [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.

-->

  </back>
</rfc>