rfc9831xml2.original.xml   rfc9831.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?> <!DOCTYPE rfc [
<?rfc compact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc inline="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc subcompact="no"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
<?rfc tocindent="yes"?> tf-idr-bgp-sr-segtypes-ext-08" number="9831" consensus="true" ipr="trust200902"
<?rfc tocompact="yes"?> obsoletes="" updates="" submissionType="IETF" xml:lang="en" sortRefs="true" symR
<rfc category="exp" docName="draft-ietf-idr-bgp-sr-segtypes-ext-08" efs="true" tocInclude="true" tocDepth="3" version="3">
ipr="trust200902">
<front> <front>
<title abbrev="SR Segment Type Ext for BGP SR Policy">Segment Routing
Segment Types Extensions for BGP SR Policy</title>
<author fullname="Ketan Talaulikar" initials="K." role="editor" <!--[rfced] Is the document title redundant (especially if the
surname="Talaulikar"> abbreviation is expanded)? If our suggested title is not
<organization>Cisco Systems</organization> 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.
<address> Original:
<postal> Segment Routing Segment Types Extensions for BGP SR Policy
<street/>
<city/> As it would be expanded:
Segment Routing Segment Types Extensions for BGP Segment Routing Policy
<region/> Perhaps:
Segment Type Extensions for BGP Segment Routing (SR) Policy
<code/> 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="Tal
aulikar">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Brussels</city> <city>Brussels</city>
<country>Belgium</country>
<region/>
<code/>
<country>BE</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <country>Italy</country>
<city/>
<code/>
<country>IT</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Paul Mattes" initials="P." surname="Mattes"> <author fullname="Paul Mattes" initials="P." surname="Mattes">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street>One Microsoft Way</street> <street>One Microsoft Way</street>
<city>Redmond</city> <city>Redmond</city>
<region>WA</region> <region>WA</region>
<code>98052</code> <code>98052</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>pamattes@microsoft.com</email> <email>pamattes@microsoft.com</email>
</address> </address>
</author> </author>
<author fullname="Dhanendra Jain" initials="D." surname="Jain"> <author fullname="Dhanendra Jain" initials="D." surname="Jain">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>dhanendra.ietf@gmail.com</email> <email>dhanendra.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="August" year="2025"/>
<date/> <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> <abstract>
<t>This document specifies the signaling of additional Segment Routing <t>This document specifies the signaling of additional Segment Routing (SR
Segment Types for signaling of Segment Routing (SR) Policies in BGP )
using SR Policy Subsequent Address Family Identifier.</t> Segment Types for SR Policies in BGP
using the SR Policy Subsequent Address Family Identifier (SAFI).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>BGP Segment Routing (SR) Policy Subsequent Address Family Identifier <name>Introduction</name>
(SAFI) was introduced by <xref target="I-D.ietf-idr-sr-policy-safi"/> <t>The BGP Segment Routing (SR) Policy Subsequent Address Family Identifie
for the advertisement of SR Policy <xref target="RFC8402"/>. <xref r
target="I-D.ietf-idr-sr-policy-safi"/> introduced the base SR Segment (SAFI) was introduced by <xref target="RFC9830" format="default"/>
Types A and B as specified by the SR Policy Architecture <xref for the advertisement of SR Policies <xref target="RFC8402" format="defaul
target="RFC9256"/>.</t> t"/>. <xref target="RFC9830" format="default"/> introduced the base SR Segment
Types A and B as specified by the SR Policy Architecture <xref target="RFC
9256" format="default"/>.</t>
<t>This document specifies the extensions for the advertisement of the <t>This document specifies the extensions for the advertisement of the
remaining SR Segment Types defined in <xref target="RFC9256"/> in the SR remaining SR Segment Types defined in <xref target="RFC9256" format="defau
Policy SAFI for both SR-MPLS <xref target="RFC8660"/> and SRv6 <xref lt"/> in the SR
target="RFC8754"/> <xref target="RFC8986"/>.</t> Policy SAFI for both SR-MPLS (see <xref target="RFC8660" format="default"/
>) and Segment Routing over IPv6 (SRv6) (see <xref target="RFC8754" format="defa
ult"/> and <xref target="RFC8986" format="default"/>).</t>
<t>The extensions in this document do not impact the SR Policy <t>The extensions in this document do not impact the SR Policy
operations or fault management as specified in <xref operations or fault management as specified in <xref target="RFC9830" form
target="I-D.ietf-idr-sr-policy-safi"/>.</t> at="default"/>.</t>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="SEGMENTTLV" numbered="true" toc="default">
<name>Segment Type Sub-TLVs</name>
<section anchor="SEGMENTTLV" title="Segment Type Sub-TLVs"> <!--[rfced] Section 2: Please review and confirm that the switch
<t>The Segment List sub-TLV <xref target="I-D.ietf-idr-sr-policy-safi"/> 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="RFC9830" format="default"/>
encodes a single explicit path towards the endpoint as described in encodes a single explicit path towards the endpoint as described in
section 5.1 of <xref target="RFC9256"/>. The Segment List sub-TLV <xref target="RFC9256" sectionFormat="of" section="5.1"/>. The Segment Lis t sub-TLV
includes the elements of the paths (i.e., segments).</t> 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., <t>A Segment sub-TLV describes a single segment in a segment list (i.e.,
a single element of the explicit path).</t> a single element of the explicit path).</t>
<t><xref target="RFC9256" sectionFormat="of" section="4"/> defines several
Segment Types
for SR-MPLS and SRv6 that are listed below as a reminder:</t>
<t>Section 4 of <xref target="RFC9256"/> defines several Segment Types <dl spacing="normal" newline="false" indent="10">
for SR-MPLS and SRv6 that are listed below as a reminder:<figure <dt>Type A:</dt><dd>SR-MPLS Label</dd>
align="center"> <dt>Type B:</dt><dd>SRv6 SID</dd>
<artwork align="left"><![CDATA[Type A: SR-MPLS Label <dt>Type C:</dt><dd>IPv4 Prefix with optional SR Algorithm</dd>
Type B: SRv6 SID <dt>Type D:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SR-
Type C: IPv4 Prefix with optional SR Algorithm MPLS</dd>
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS <dt>Type E:</dt><dd>IPv4 Prefix with Local Interface ID</dd>
Type E: IPv4 Prefix with Local Interface ID <dt>Type F:</dt><dd>IPv4 Addresses for link endpoints as Local, Remote pa
Type F: IPv4 Addresses for link endpoints as Local, Remote pair ir</dd>
Type G: IPv6 Prefix and Interface ID for link endpoints as Local, <dt>Type G:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Lo
Remote pair for SR-MPLS cal, Remote pair for SR-MPLS</dd>
Type H: IPv6 Addresses for link endpoints as Local, Remote pair <dt>Type H:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pa
for SR-MPLS ir for SR-MPLS</dd>
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 <dt>Type I:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SRv
Type J: IPv6 Prefix and Interface ID for link endpoints as Local, 6</dd>
Remote pair for SRv6 <dt>Type J:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Lo
Type K: IPv6 Addresses for link endpoints as Local, Remote pair cal, Remote pair for SRv6</dd>
for SRv6 <dt>Type K:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pa
ir for SRv6</dd>
Figure 1: SR Segment Types </dl>
]]></artwork>
</figure></t>
<t><xref target="I-D.ietf-idr-sr-policy-safi"/> specifies Segment Type <t><xref target="RFC9830" format="default"/> specifies Segment Type
Sub-TLVs for the segment types A and B. The following sub-sections Sub-TLVs for the Segment Types A and B. The following subsections
specify the sub-TLVs used for encoding each of the other Segment Types specify the sub-TLVs used for encoding each of the other Segment Types
above.</t> above.</t>
<t>As specified in sections 2.4.4 and 2.4.4.2 of <xref <!-- [rfced] The following text from Section 2 may require
target="I-D.ietf-idr-sr-policy-safi"/>, validation of an explicit path clarification:
"As specified in Sections 2.4.4 and 2.4.4.2 of [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 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" se
ction="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 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 performed by the Segment Routing Policy Module (SRPM) as described in
section 5 of <xref target="RFC9256"/>. As specified in section 5.1 of <xref target="RFC9256" sectionFormat="of" section="5"/>. As specified in
<xref target="RFC9256"/>, a mix of SR-MPLS and SRv6 segments make the <xref target="RFC9256" sectionFormat="of" section="5.1"/>, a mix of SR-MPL
S and SRv6 segments make the
segment-list invalid.</t> segment-list invalid.</t>
<section anchor="TYPEC" numbered="true" toc="default">
<section anchor="TYPEC" <name>Segment Type C: SR-MPLS Prefix SID for IPv4</name>
title="Segment Type C - SR-MPLS Prefix SID for IPv4"> <t>The Type C Segment sub-TLV encodes an IPv4 node address, SR
<t>The Type C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm, and an optional SR-MPLS Segment Identifier (SID). The format
Algorithm, and an optional SR-MPLS SID. The format is as follows: is as follows:
<figure align="center"> </t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>Type C Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) | | SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 2: Type C Segment sub-TLV <t>Where:</t>
where:]]></artwork>
</figure><list style="symbols">
<t>Type: 3.</t>
<t>Length: Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value
MUST be 10 when the SR-MPLS SID is present, else it MUST be 6.</t>
<t>Flags: 1 octet of flags as defined in <xref
target="SEGMENTFLAGS"/>.</t>
<t>SR Algorithm: 1-octet specifying SR Algorithm as described in <dl spacing="normal" newline="false">
section 3.1.1 in <xref target="RFC8402"/> when A-Flag as defined <dt>Type:</dt><dd>3</dd>
in <xref target="SEGMENTFLAGS"/> is set. SR Algorithm is used by <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> as described in including Type and Length fields) in terms of octets. The value
section 4 in <xref target="RFC9256"/>. When A-Flag is not set, <bcp14>MUST</bcp14> be 10 when the SR-MPLS SID is present; else, it
this field MUST be set to zero on transmission and MUST be ignored <bcp14>MUST</bcp14> be 6.</dd>
on receipt.</t> <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
target="SEGMENTFLAGS" format="default"/>.</dd>
<dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as described in
<xref target="RFC8402" sectionFormat="of" section="3.1.1"/> when the A-Flag as
defined in <xref target="SEGMENTFLAGS" format="default"/> is set. The SR
Algorithm is used by the SRPM <xref target="RFC9830"
format="default"/> as described in <xref target="RFC9256" sectionFormat="of"
section="4"/>. When the A-Flag is not set, this field <bcp14>MUST</bcp14> be s
et
to zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>IPv4 Node Address:</dt><dd>A 4-octet IPv4 address representing a
node.</dd>
<t>IPv4 Node Address: a 4-octet IPv4 address representing a <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label, Traffic
node.</t> Class (TC), bottom-of-stack (S), and
TTL as defined for Segment Type A <xref target="RFC9830"
format="default"/>.</dd>
</dl>
<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S
and TTL as defined for Segment Type A <xref
target="I-D.ietf-idr-sr-policy-safi"/>.</t>
</list></t>
</section> </section>
<section anchor="TYPED" numbered="true" toc="default">
<section anchor="TYPED" <name>Segment Type D: SR-MPLS Prefix SID for IPv6</name>
title="Segment Type D - SR-MPLS Prefix SID for IPv6"> <t>The Type D Segment sub-TLV encodes an IPv6 node address, SR
<t>The Type D Segment Sub-TLV encodes an IPv6 node address, SR
Algorithm, and an optional SR-MPLS SID. The format is as follows: Algorithm, and an optional SR-MPLS SID. The format is as follows:
<figure align="center"> </t>
<artwork align="left"><![CDATA[ 0 1
2 3 <figure>
<name>Type D Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) // // IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) | | SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:</t>
Figure 3: Type D Segment sub-TLV <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>4</dd>
where:]]></artwork> <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
</figure><list style="symbols"> not including Type and Length fields) in terms of octets. The value
<t>Type: 4</t> <bcp14>MUST</bcp14> be 22 when the SR-MPLS SID is present; else, it
<bcp14>MUST</bcp14> be 18.</dd>
<t>Length: Specifies the length of the value field (i.e., not <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
including Type and Length fields) in terms of octets. The value target="SEGMENTFLAGS" format="default"/>.</dd>
MUST be 22 when the SR-MPLS SID is present, else it MUST be <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
18.</t> described in <xref target="RFC8402" sectionFormat="of"
section="3.1.1"/> when the A-Flag as defined in <xref
<t>Flags: 1 octet of flags as defined in <xref target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
target="SEGMENTFLAGS"/>.</t> used by the SRPM <xref target="RFC9830"
format="default"/> as described in <xref target="RFC9256"
<t>SR Algorithm: 1-octet specifying SR Algorithm as described in sectionFormat="of" section="4"/>. When the A-Flag is not set, this fie
section 3.1.1 in <xref target="RFC8402"/> when A-Flag as defined ld
in <xref target="SEGMENTFLAGS"/> is set. SR Algorithm is used by <bcp14>MUST</bcp14> be set to zero on transmission and
SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> as described in <bcp14>MUST</bcp14> be ignored on receipt.</dd>
section 4 in <xref target="RFC9256"/>. When A-Flag is not set, <dt>IPv6 Node Address:</dt><dd>A 16-octet IPv6 address representing
this field MUST be set to zero on transmission and MUST be ignored a node.</dd>
on receipt.</t> <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label
,
<t>IPv6 Node Address: a 16-octet IPv6 address representing a TC, S, and TTL as defined for Segment Type A <xref
node.</t> target="RFC9830" format="default"/>.</dd>
</dl>
<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S
and TTL as defined for Segment Type A <xref
target="I-D.ietf-idr-sr-policy-safi"/>.</t>
</list></t>
</section> </section>
<section anchor="TYPEE" numbered="true" toc="default">
<section anchor="TYPEE" <name>Segment Type E: SR-MPLS Adjacency SID for IPv4 with an Interface I
title="Segment Type E - SR-MPLS Adjacency SID for IPv4 with an In D</name>
terface ID"> <t>The Type E Segment sub-TLV encodes an IPv4 node address, a local
<t>The Type E Segment Sub-TLV encodes an IPv4 node address, a local
interface Identifier (Local Interface ID), and an optional SR-MPLS interface Identifier (Local Interface ID), and an optional SR-MPLS
SID. The format is as follows: <figure align="center"> SID. The format is as follows: </t>
<artwork align="left"><![CDATA[ 0 1
2 3 <figure>
<name>Type E Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) | | SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 4: Type E Segment sub-TLV <t>Where:</t>
where:]]></artwork>
</figure><list style="symbols">
<t>Type: 5.</t>
<t>Length: Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value
MUST be 14 when the SR-MPLS SID is present, else it MUST be
10.</t>
<t>Flags: 1 octet of flags as defined in <xref
target="SEGMENTFLAGS"/>.</t>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dl spacing="normal" newline="false">
zero on transmission and MUST be ignored on receipt.</t> <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
<bcp14>MUST</bcp14> be 14 when the SR-MPLS SID is present; else, it
<bcp14>MUST</bcp14> be 10.</dd>
<dt>Flags:</dt><dd>1 octet of flags as defined in <xref
target="SEGMENTFLAGS" format="default"/>.</dd>
<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field
<bcp14>MUST</bcp14> be set to zero on transmission and <bcp14>MUST</bcp14>
be ignored on receipt.</dd>
<t>Local Interface ID: 4 octets of interface index of local <!--[rfced] Please consider rephrasing the following text (the stacked
interface (refer TLV 258 of <xref target="RFC9552"/>).</t> uses of "of" and repetition of "interface" might benefit from a
change).
<t>IPv4 Node Address: a 4-octet IPv4 address representing a Original:
node.</t> Local Interface ID: 4 octets of interface index of local interface
(refer TLV 258 of [RFC9552]).
<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S -->
and TTL as defined for Segment Type A <xref <dt>Local Interface ID:</dt><dd>4 octets of interface index of local
target="I-D.ietf-idr-sr-policy-safi"/>.</t> interface (refer to TLV 258 of <xref target="RFC9552" format="default"/>).</dd
</list></t> >
<dt>IPv4 Node Address:</dt><dd>A 4-octet IPv4 address representing a
node.</dd>
<dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label, TC, S,
and
TTL as defined for Segment Type A <xref target="RFC9830"
format="default"/>.</dd>
</dl>
</section> </section>
<section anchor="TYPEF" numbered="true" toc="default">
<section anchor="TYPEF" <name>Segment Type F: SR-MPLS Adjacency SID for IPv4 with an Interface A
title="Segment Type F - SR-MPLS Adjacency SID for IPv4 with an In ddress</name>
terface Address"> <t>The Type F Segment sub-TLV encodes an adjacency local address, an
<t>The Type F Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address, and an optional SR-MPLS SID. The format is adjacency remote address, and an optional SR-MPLS SID. The format is
as follows: <figure align="center"> as follows: </t>
<artwork align="left"><![CDATA[ 0 1
2 3 <figure>
<name>Type F Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 Address (4 octets) | | Local IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address (4 octets) | | Remote IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) | | SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 5: Type F Segment sub-TLV <t>Where:</t>
<dl spacing="normal" newline="false">
where:]]></artwork> <dt>Type:</dt><dd>6</dd>
</figure><list style="symbols"> <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
<t>Type: 6.</t> not including Type and Length fields) in terms of octets. The value
<bcp14>MUST</bcp14> be 14 when the SR-MPLS SID is present; else, it
<t>Length: Specifies the length of the value field (i.e., not <bcp14>MUST</bcp14> be 10.</dd>
including Type and Length fields) in terms of octets. The value <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
MUST be 14 when the SR-MPLS SID is present, else it MUST be target="SEGMENTFLAGS" format="default"/>.</dd>
10.</t> <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field
<bcp14>MUST</bcp14> be set to zero on transmission and
<t>Flags: 1 octet of flags as defined in <xref <bcp14>MUST</bcp14> be ignored on receipt.</dd>
target="SEGMENTFLAGS"/>.</t> <dt>Local IPv4 Address:</dt><dd>A 4-octet IPv4 address representing
the local link address of the node.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dt>Remote IPv4 Address:</dt><dd>A 4-octet IPv4 address representing
zero on transmission and MUST be ignored on receipt.</t> the link address of the neighbor node.</dd>
<dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label,
<t>Local IPv4 Address: a 4-octet IPv4 address representing the TC, S, and TTL as defined for Segment Type A <xref
local link address of the node.</t> target="RFC9830" format="default"/>.</dd>
</dl>
<t>Remote IPv4 Address: a 4-octet IPv4 address representing the
link address of the neighbor node.</t>
<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S
and TTL as defined for Segment Type A <xref
target="I-D.ietf-idr-sr-policy-safi"/>.</t>
</list></t>
</section> </section>
<section anchor="TYPEG" numbered="true" toc="default">
<section anchor="TYPEG" <name>Segment Type G: SR-MPLS Adjacency SID for IPv6 with an Interface I
title="Segment Type G - SR-MPLS Adjacency SID for IPv6 with an In D</name>
terface ID"> <t>The Type G Segment sub-TLV encodes an IPv6 link-local adjacency
<t>The Type G Segment Sub-TLV encodes an IPv6 link-local adjacency with an IPv6 local node address, a local interface identifier (Local
with IPv6 local node address, a local interface identifier (Local Interface ID), an IPv6 remote node address, a remote interface identifie
Interface ID), IPv6 remote node address, a remote interface identifier r
(Remote Interface ID), and an optional SR-MPLS SID. The format is as (Remote Interface ID), and an optional SR-MPLS SID. The format is as
follows: <figure align="center"> follows: </t>
<artwork align="left"><![CDATA[ 0 1
2 3 <figure>
<name>Type G Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) // // IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) | | Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) // // IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) | | SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Figure 6: Type G Segment sub-TLV </figure>
<t>Where:</t>
where:]]></artwork> <dl spacing="normal" newline="false">
</figure><list style="symbols"> <dt>Type:</dt><dd>7</dd>
<t>Type: 7</t> <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
<t>Length: Specifies the length of the value field (i.e., not <bcp14>MUST</bcp14> be 46 when the SR-MPLS SID is present; else, it
including Type and Length fields) in terms of octets. The value <bcp14>MUST</bcp14> be 42.</dd>
MUST be 46 when the SR-MPLS SID is present, else it MUST be <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
42.</t> target="SEGMENTFLAGS" format="default"/>.</dd>
<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field
<t>Flags: 1 octet of flags as defined in <xref <bcp14>MUST</bcp14> be set to zero on transmission and
target="SEGMENTFLAGS"/>.</t> <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Local Interface ID:</dt><dd>4 octets of interface index of local
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to interface (refer to TLV 258 of <xref target="RFC9552"
zero on transmission and MUST be ignored on receipt.</t> format="default"/>).</dd>
<dt>IPv6 Local Node Address:</dt><dd>A 16-octet IPv6 address
<t>Local Interface ID: 4 octets of interface index of local representing the node.</dd>
interface (refer TLV 258 of <xref target="RFC9552"/>).</t> <dt>Remote Interface ID:</dt><dd>4 octets of interface index of
remote interface (refer to TLV 258 of <xref target="RFC9552"
<t>IPv6 Local Node Address: a 16-octet IPv6 address representing format="default"/>). The value <bcp14>MAY</bcp14> be set to zero
the node.</t> when the local node address and interface identifiers are sufficient
to describe the link.</dd>
<t>Remote Interface ID: 4 octets of interface index of remote <dt>IPv6 Remote Node Address:</dt><dd>A 16-octet IPv6 address. The
interface (refer TLV 258 of <xref target="RFC9552"/>). The value value <bcp14>MAY</bcp14> be set to zero when the local node address
MAY be set to zero when the local node address and interface and interface identifiers are sufficient to describe the link.</dd>
identifiers are sufficient to describe the link.</t> <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label,
TC, S, and TTL as defined for Segment Type A <xref
<t>IPv6 Remote Node Address: a 16-octet IPv6 address. The value target="RFC9830" format="default"/>.</dd>
MAY be set to zero when the local node address and interface </dl>
identifiers are sufficient to describe the link.</t>
<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S
and TTL as defined for Segment Type A <xref
target="I-D.ietf-idr-sr-policy-safi"/>.</t>
</list></t>
</section> </section>
<section anchor="TYPEH" numbered="true" toc="default">
<section anchor="TYPEH" <name>Segment Type H: SR-MPLS Adjacency SID for IPv6 with an Interface A
title="Segment Type H - SR-MPLS Adjacency SID for IPv6 with an In ddress</name>
terface Address"> <t>The Type H Segment sub-TLV encodes an adjacency local address, an
<t>The Type H Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address, and an optional SR-MPLS SID. The format is adjacency remote address, and an optional SR-MPLS SID. The format is
as follows: <figure align="center"> as follows: </t>
<artwork align="left"><![CDATA[ 0 1
2 3 <figure>
<name>Type H Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) // // Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) // // Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) | | SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Figure 7: Type H Segment sub-TLV </figure>
<t>Where:</t>
where:]]></artwork> <dl spacing="normal" newline="false">
</figure><list style="symbols"> <dt>Type:</dt><dd>8</dd>
<t>Type: 8</t> <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
<t>Length: Specifies the length of the value field (i.e., not <bcp14>MUST</bcp14> be 38 when the SR-MPLS SID is present; else, it
including Type and Length fields) in terms of octets. The value <bcp14>MUST</bcp14> be 34.</dd>
MUST be 38 when the SR-MPLS SID is present, else it MUST be <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
34.</t> target="SEGMENTFLAGS" format="default"/>.</dd>
<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field
<t>Flags: 1 octet of flags as defined in <xref <bcp14>MUST</bcp14> be set to zero on transmission and
target="SEGMENTFLAGS"/>.</t> <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Local IPv6 Address:</dt><dd>A 16-octet IPv6 address
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to representing the local link address of the node.</dd>
zero on transmission and MUST be ignored on receipt.</t> <dt>Remote IPv6 Address:</dt><dd>A 16-octet IPv6 address
representing the link address of the neighbor node.</dd>
<t>Local IPv6 Address: a 16-octet IPv6 address representing the <dt>SR-MPLS SID:</dt><dd>Optional. A 4-octet field containing a label,
local link address of the node.</t> TC, S, and TTL as defined for Segment Type A <xref
target="RFC9830" format="default"/>.</dd>
<t>Remote IPv6 Address: a 16-octet IPv6 address representing the </dl>
link address of the neighbor node.</t>
<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S
and TTL as defined for Segment Type A <xref
target="I-D.ietf-idr-sr-policy-safi"/>.</t>
</list></t>
</section> </section>
<section anchor="TYPEI" numbered="true" toc="default">
<name>Segment Type I: SRv6 END SID as IPv6 Node Address</name>
<t>The Type I Segment sub-TLV encodes an IPv6 node address, an SR
Algorithm, and an optional SRv6 SID. The format is as follows: </t>
<section anchor="TYPEI" <figure>
title="Segment Type I - SRv6 END SID as IPv6 Node Address"> <name>Type I Segment Sub-TLV</name>
<t>The Type I Segment Sub-TLV encodes an IPv6 node address, SR <artwork align="left" name="" type="" alt=""><![CDATA[
Algorithm, and an optional SRv6 SID. The format is as follows: <figure 0 1 2 3
align="center">
<artwork align="left"><![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 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 | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) // // IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 16 octets) // // SRv6 SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure // // SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) // // (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:</t>
Figure 8: Type I Segment sub-TLV <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>14</dd>
where:]]></artwork> <dt>Length:</dt><dd><t>Specifies the length of the value field (i.e.,
</figure><list style="symbols"> not including Type and Length fields) in terms of octets. The value
<t>Type: 14</t> <bcp14>MUST</bcp14> be one of the following:</t>
<ul spacing="compact">
<t>Length: Specifies the length of the value field (i.e., not <li>42 when both SRv6 SID and SRv6
including Type and Length fields) in terms of octets. The value Endpoint Behavior and SID Structure are present,</li>
MUST be one of: 42 when both SRv6 SID and SRv6 Endpoint Behavior <li>34 when only SRv6
&amp; SID Structure are present, 34 when only SRv6 SID is present, SID is present, or</li>
or 18 when the SRv6 SID is not present.</t> <li>18 when the SRv6 SID is not present.</li>
</ul>
<t>Flags: 1 octet of flags as defined in <xref </dd>
target="SEGMENTFLAGS"/>.</t> <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
target="SEGMENTFLAGS" format="default"/>.</dd>
<t>SR Algorithm: 1 octet specifying SR Algorithm as described in <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
section 3.1.1 in <xref target="RFC8402"/> when A-Flag as defined described in <xref target="RFC8402" sectionFormat="of"
in <xref target="SEGMENTFLAGS"/> is set. SR Algorithm is used by section="3.1.1"/> when the A-Flag as defined in <xref
SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> as described in target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
section 4 in <xref target="RFC9256"/>. When A-Flag is not set, used by the SRPM <xref target="RFC9830"
this field MUST be set to zero on transmission and MUST be ignored format="default"/> as described in <xref target="RFC9256"
on receipt.</t> sectionFormat="of" section="4"/>. When the A-Flag is not set, this fie
ld
<t>IPv6 Node Address: a 16-octet IPv6 address representing the <bcp14>MUST</bcp14> be set to zero on transmission and
node.</t> <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>IPv6 Node Address:</dt><dd>A 16-octet IPv6 address representing
<t>SRv6 SID: optional, a 16-octet IPv6 address. The value 0 MAY be the node.</dd>
used when the controller wants to indicate the desired SRv6 <dt>SRv6 SID:</dt><dd>Optional. A 16-octet IPv6 address. The value 0
Endpoint Behavior or SID Structure without specifying the SID.</t> <bcp14>MAY</bcp14> be used when the controller wants to indicate the
desired SRv6 Endpoint Behavior or SID Structure without specifying
<t>SRv6 Endpoint Behavior and SID Structure: Optional, as defined the SID.</dd>
in section 2.4.4.2.4 of <xref <dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional, as
target="I-D.ietf-idr-sr-policy-safi"/>. The SRv6 Endpoint Behavior defined in <xref target="RFC9830"
and SID Structure MUST NOT be included when the SRv6 SID has not sectionFormat="of" section="2.4.4.2.4"/>. The SRv6 Endpoint Behavior
been included.</t> and SID Structure <bcp14>MUST NOT</bcp14> be included when the SRv6
</list></t> SID has not been included.</dd>
</dl>
<t>The TLV 10 defined for the advertisement of Segment Type I in the <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"/> early draft versions of <xref target="RFC9830" format="default"/>
has been deprecated to avoid backward compatibility issues.</t> has been deprecated to avoid backward-compatibility issues.</t>
</section> </section>
<section anchor="TYPEJ" numbered="true" toc="default">
<section anchor="TYPEJ" <name>Segment Type J: SRv6 END.X SID as an Interface ID</name>
title="Segment Type J - SRv6 END.X SID as an Interface ID"> <t>The Type J Segment sub-TLV encodes an IPv6 link-local adjacency
<t>The Type J Segment Sub-TLV encodes an IPv6 link-local adjacency with a local node address, a local interface identifier (Local Interface
with local node address, a local interface identifier (Local Interface ID), a remote IPv6 node address, a remote interface identifier (Remote
ID), remote IPv6 node address, a remote interface identifier (Remote
Interface ID), and an optional SRv6 SID. The format is as follows: Interface ID), and an optional SRv6 SID. The format is as follows:
<figure align="center"> </t>
<artwork align="left"><![CDATA[ 0 1 <figure>
2 3 <name>Type J Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) // // IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) | | Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) // // IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 16 octets) // // SRv6 SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure // // SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) // // (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 9: Type J Segment sub-TLV <t>Where:</t>
<dl spacing="normal" newline="false">
where:]]></artwork> <dt>Type:</dt><dd>15</dd>
</figure><list style="symbols"> <dt>Length:</dt><dd><t>Specifies the length of the value field (i.e.,
<t>Type: 15</t> not including Type and Length fields) in terms of octets. The value
<bcp14>MUST</bcp14> be one of the following:</t>
<t>Length: Specifies the length of the value field (i.e., not <ul spacing="compact">
including Type and Length fields) in terms of octets. The value <li>66 when both SRv6 SID and SRv6
MUST be one of: 66 when both SRv6 SID and SRv6 Endpoint Behavior Endpoint Behavior and SID Structure are present,</li>
&amp; SID Structure are present, 58 when only SRv6 SID is present, <li>58 when only SRv6 SID is present, or</li>
or 42 when the SRv6 SID is not present.</t> <li>42 when the SRv6 SID is not present.</li>
</ul>
<t>Flags: 1 octet of flags as defined in <xref </dd>
target="SEGMENTFLAGS"/>.</t> <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
target="SEGMENTFLAGS" format="default"/>.</dd>
<t>SR Algorithm: 1-octet specifying SR Algorithm as described in <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
section 3.1.1 in <xref target="RFC8402"/> when A-Flag as defined described in <xref target="RFC8402" sectionFormat="of"
in <xref target="SEGMENTFLAGS"/> is set. SR Algorithm is used by section="3.1.1"/> when the A-Flag as defined in <xref
SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> as described in target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
section 4 in <xref target="RFC9256"/>. When A-Flag is not set, used by the SRPM <xref target="RFC9830"
this field MUST be set to zero on transmission and MUST be ignored format="default"/> as described in <xref target="RFC9256"
on receipt.</t> sectionFormat="of" section="4"/>. When the A-Flag is not set, this fie
ld
<t>Local Interface ID: 4 octets of interface index of local <bcp14>MUST</bcp14> be set to zero on transmission and
interface (refer TLV 258 of <xref target="RFC9552"/>).</t> <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Local Interface ID:</dt><dd>4 octets of interface index of local
<t>IPv6 Local Node Address: a 16-octet IPv6 address representing interface (refer to TLV 258 of <xref target="RFC9552"
the node.</t> format="default"/>).</dd>
<dt>IPv6 Local Node Address:</dt><dd>A 16-octet IPv6 address
<t>Remote Interface ID: 4 octets of interface index of remote representing the node.</dd>
interface (refer TLV 258 of <xref target="RFC9552"/>). The value <dt>Remote Interface ID:</dt><dd>4 octets of interface index of
MAY be set to zero when the local node address and interface remote interface (refer to TLV 258 of <xref target="RFC9552"
identifiers are sufficient to describe the link.</t> format="default"/>). The value <bcp14>MAY</bcp14> be set to zero
when the local node address and interface identifiers are sufficient
<t>IPv6 Remote Node Address: a 16-octet IPv6 address. The value to describe the link.</dd>
MAY be set to zero when the local node address and interface <dt>IPv6 Remote Node Address:</dt><dd>A 16-octet IPv6 address. The
identifiers are sufficient to describe the link.</t> value <bcp14>MAY</bcp14> be set to zero when the local node address
and interface identifiers are sufficient to describe the link.</dd>
<t>SRv6 SID: optional, a 16-octet IPv6 address. The value 0 MAY be <dt>SRv6 SID:</dt><dd>Optional. A 16-octet IPv6 address. The value 0
used when the controller wants to indicate the desired SRv6 <bcp14>MAY</bcp14> be used when the controller wants to indicate the
Endpoint Behavior or SID Structure without specifying the SID.</t> desired SRv6 Endpoint Behavior or SID Structure without specifying
the SID.</dd>
<t>SRv6 Endpoint Behavior and SID Structure: Optional, as defined
in section 2.4.4.2.4 of <xref
target="I-D.ietf-idr-sr-policy-safi"/>. The SRv6 Endpoint Behavior
and SID Structure MUST NOT be included when the SRv6 SID has not
been included.</t>
</list></t>
<t>The TLV 11 defined for the advertisement of Segment Type J in the <!-- [rfced] We note that Section 2.4.4.2.4 of [RFC9830] uses the term
early draft versions of <xref target="I-D.ietf-idr-sr-policy-safi"/> "SRv6 SID Endpoint Behavior and Structure" rather than "SRv6
has been deprecated to avoid backward compatibility issues.</t> Endpoint Behavior and SID Structure". Please let us know if/how
these uses may be made consistent.
-->
<dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional, as
defined in <xref target="RFC9830"
sectionFormat="of" section="2.4.4.2.4"/>. The SRv6 Endpoint Behavior
and SID Structure <bcp14>MUST NOT</bcp14> be included when the SRv6
SID has not been included.</dd>
</dl>
<t>TLV 11 defined for the advertisement of Segment Type J in the
early draft versions of <xref target="RFC9830" format="default"/>
has been deprecated to avoid backward-compatibility issues.</t>
</section> </section>
<section anchor="TYPEK" numbered="true" toc="default">
<section anchor="TYPEK" <name>Segment Type K: SRv6 END.X SID as an Interface Address</name>
title="Segment Type K - SRv6 END.X SID as an Interface Address"> <t>The Type K Segment sub-TLV encodes an adjacency local address, an
<t>The Type K Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address, and an optional SRv6 SID. The format is as adjacency remote address, and an optional SRv6 SID. The format is as
follows: <figure align="center"> follows: </t>
<artwork align="left"><![CDATA[ 0 1
2 3 <figure>
<name>Type K Segment Sub-TLV</name>
<artwork 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 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 | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) // // Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) // // Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 16 octets) // // SRv6 SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure // // SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) // // (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Figure 10: Type K Segment sub-TLV </figure>
<t>Where:</t>
where:]]></artwork> <dl spacing="normal" newline="false">
</figure><list style="symbols"> <dt>Type:</dt><dd>16</dd>
<t>Type: 16</t> <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
<t>Length: Specifies the length of the value field (i.e., not <bcp14>MUST</bcp14> be one of the following:</t>
including Type and Length fields) in terms of octets. The value <ul spacing="compact">
MUST be one of: 58 when both SRv6 SID and SRv6 Endpoint Behavior <li>58 when both SRv6 SID and SRv6
&amp; SID Structure are present, 50 when only SRv6 SID is present, Endpoint Behavior and SID Structure are present,</li>
or 34 when the SRv6 SID is not present.</t> <li>50 when only SRv6
SID is present, or</li>
<t>Flags: 1 octet of flags as defined in <xref <li>34 when the SRv6 SID is not present.</li>
target="SEGMENTFLAGS"/>.</t> </ul>
</dd>
<t>SR Algorithm: 1-octet specifying SR Algorithm as described in <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
section 3.1.1 in <xref target="RFC8402"/> when A-Flag as defined target="SEGMENTFLAGS" format="default"/>.</dd>
in <xref target="SEGMENTFLAGS"/> is set. SR Algorithm is used by <dt>SR Algorithm:</dt><dd>1 octet specifying the SR Algorithm as
SRPM <xref target="I-D.ietf-idr-sr-policy-safi"/> as described in described in <xref target="RFC8402" sectionFormat="of"
section 4 in <xref target="RFC9256"/>. When A-Flag is not set, section="3.1.1"/> when the A-Flag as defined in <xref
this field MUST be set to zero on transmission and MUST be ignored target="SEGMENTFLAGS" format="default"/> is set. The SR Algorithm is
on receipt.</t> used by the SRPM <xref target="RFC9830"
format="default"/> as described in <xref target="RFC9256"
<t>Local IPv6 Address: a 16-octet IPv6 address representing the sectionFormat="of" section="4"/>. When the A-Flag is not set, this fie
local link address of the node.</t> ld
<bcp14>MUST</bcp14> be set to zero on transmission and
<t>Remote IPv6 Address: a 16-octet IPv6 address representing the <bcp14>MUST</bcp14> be ignored on receipt.</dd>
link address of the neighbor node.</t> <dt>Local IPv6 Address:</dt><dd>A 16-octet IPv6 address representing
the local link address of the node.</dd>
<t>SRv6 SID: optional, a 16-octet IPv6 address. The value 0 MAY be <dt>Remote IPv6 Address:</dt><dd>A 16-octet IPv6 address
used when the controller wants to indicate the desired SRv6 representing the link address of the neighbor node.</dd>
Endpoint Behavior or SID Structure without specifying the SID.</t> <dt>SRv6 SID:</dt><dd>Optional. A 16-octet IPv6 address. The value 0
<bcp14>MAY</bcp14> be used when the controller wants to indicate the
<t>SRv6 Endpoint Behavior and SID Structure: Optional, as defined desired SRv6 Endpoint Behavior or SID Structure without specifying
in section 2.4.4.2.4 of <xref the SID.</dd>
target="I-D.ietf-idr-sr-policy-safi"/>. The SRv6 Endpoint Behavior <dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional, as
and SID Structure MUST NOT be included when the SRv6 SID has not defined in <xref target="RFC9830"
been included.</t> sectionFormat="of" section="2.4.4.2.4"/>. The SRv6 Endpoint Behavior
</list></t> and SID Structure <bcp14>MUST NOT</bcp14> be included when the SRv6
SID has not been included.</dd>
<t>The TLV 12 defined for the advertisement of Segment Type K in the </dl>
early draft versions of <xref target="I-D.ietf-idr-sr-policy-safi"/> <t>TLV 12 defined for the advertisement of Segment Type K in the
has been deprecated to avoid backward compatibility issues.</t> early draft versions of <xref target="RFC9830" format="default"/>
has been deprecated to avoid backward-compatibility issues.</t>
</section> </section>
<section anchor="SEGMENTFLAGS" numbered="true" toc="default">
<name>SR Policy Segment Flags</name>
<t>The Segment Type sub-TLVs described above may contain the
following SR Policy Segment Flags <xref target="RFC9830" format="default
"/> in their Flags field (see also
<xref target="IANASIDFLAGS" format="default"/>). This document introduce
s
additional flags below:</t>
<section anchor="SEGMENTFLAGS" title="SR Policy Segment Flags"> <figure>
<t>The Segment Types sub-TLVs described above may contain the <name>SR Policy Segment Flags</name>
following SR Policy Segment Flags <xref <artwork align="left" name="" type="" alt=""><![CDATA[
target="I-D.ietf-idr-sr-policy-safi"/> in their "Flags" field. Also
refer to <xref target="IANASIDFLAGS"/>. This document introduces
additional flags as below:<figure align="center">
<artwork align="left"><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|A|S|B| | |V|A|S|B| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 11: SR Policy Segment Flags
]]></artwork> ]]></artwork>
</figure> where:<list> </figure>
<t>V-Flag: existing flag as defined in <xref <t>Where:</t>
target="I-D.ietf-idr-sr-policy-safi"/>.</t> <dl spacing="normal" newline="false">
<dt>V-Flag:</dt><dd>This is an existing flag as defined in <xref
<t>A-Flag: This flag, when set, indicates the presence of SR target="RFC9830" format="default"/>.</dd>
Algorithm id in the "SR Algorithm" field applicable to various <dt>A-Flag:</dt><dd>When set, this flag indicates the presence of
Segment Types. SR Algorithm is used by SRPM <xref the SR Algorithm id in the SR Algorithm field applicable to various
target="I-D.ietf-idr-sr-policy-safi"/> as described in section 4 Segment Types. The SR Algorithm is used by the SRPM <xref
of <xref target="RFC9256"/>.</t> target="RFC9830" format="default"/> as described
in <xref target="RFC9256" sectionFormat="of" section="4"/>.</dd>
<t>S-Flag: This flag, when set, indicates the presence of the <dt>S-Flag:</dt><dd>When set, this flag indicates the presence of
SR-MPLS or SRv6 SID depending on the segment type.</t> the SR-MPLS or SRv6 SID depending on the segment type.</dd>
<dt>B-Flag:</dt><dd>This is an existing flag as defined in <xref
<t>B-Flag: existing flag as defined in <xref target="RFC9830" format="default"/>.</dd>
target="I-D.ietf-idr-sr-policy-safi"/>.</t> </dl>
</list></t> <t>The following applies to the Segment Flags:</t>
<ul spacing="normal">
<t>The following applies to the Segment Flags:<list style="symbols"> <li>
<t>V-Flag applies to all Segment Types including the ones <t>The V-Flag applies to all Segment Types including those
introduced by this document.</t> introduced by this document.</t>
</li>
<t>A-Flag applies to Segment Types C, D, I, J, and K. The value of <li>
A-Flag MUST be ignored for Segment Types A, B, E, F, G, and H.</t> <t>The A-Flag applies to Segment Types C, D, I, J, and K. The value
of
<t>S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K. the A-Flag <bcp14>MUST</bcp14> be ignored for Segment Types A, B, E,
The value of S-Flag MUST be ignored for Segment Types A and B.</t> F, G, and H.</t>
</li>
<t>B-Flag applies to Segment Types B, I, J, and K. The value of <li>
B-Flag MUST be ignored for Segment Types A, C, D, E, F, G, and <t>The S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K
.
The value of the S-Flag <bcp14>MUST</bcp14> be ignored for Segment T
ypes A and B.</t>
</li>
<li>
<t>The B-Flag applies to Segment Types B, I, J, and K. The value of
the B-Flag <bcp14>MUST</bcp14> be ignored for Segment Types A, C, D,
E, F, G, and
H.</t> H.</t>
</list></t> </li>
</ul>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANASIDLIST" numbered="true" toc="default">
<t>This section covers the IANA considerations for this document.</t>
<section anchor="IANASIDLIST" title="SR Policy Segment List Sub-TLVs"> <!--[rfced] Please review the entries in Table 1 in light of this response regar
<t>This document requests the allocation of the following code points ding the names of sub-TLVs from Ketan when we discussed this topic for RFC-to-be
from the "SR Policy Segment List Sub-TLVs" registry <xref 9830:
target="I-D.ietf-idr-sr-policy-safi"/> under the "BGP Tunnel
Encapsulation" registry group.</t>
<t><figure align="center"> Ketan:
<artwork align="center"><![CDATA[Value Description "The names of the segments (titles) are to be "Segment Type X" while the name of
Reference the sub-TLVs are to be "Type X Segment sub-TLV" (I've seen both sub-TLV and Sub
3 Segment Type C sub-TLV This document -TLV - either is OK but we should have been consistent). The "Type-1" is actuall
4 Segment Type D sub-TLV This document y "Type A Segment sub-TLV"."
5 Segment Type E sub-TLV This document
6 Segment Type F sub-TLV This document
7 Segment Type G sub-TLV This document
8 Segment Type H sub-TLV This document
14 Segment Type I sub-TLV This document
15 Segment Type J sub-TLV This document
16 Segment Type K sub-TLV This document
Table 1: SR Policy Segment List Code Points If updates are necessary to the corresponding IANA registry, we will
communicate them on your behalf once AUTH48 concludes.
]]></artwork> -->
</figure></t>
</section>
<section anchor="IANASIDFLAGS" title="SR Policy Segment Flags"> <name>SR Policy Segment List Sub-TLVs</name>
<t>This document requests the allocation of code points from the "SR <t>IANA has allocated the following code points
Policy Segment Flags" registry <xref from the "SR Policy Segment List Sub-TLVs" registry <xref
target="I-D.ietf-idr-sr-policy-safi"/> under the "BGP Tunnel target="RFC9830" format="default"/> under the "Border Gateway Protocol (
BGP)
Tunnel Encapsulation" registry group.</t>
<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</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>4</td>
<td>Segment Type D sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>5</td>
<td>Segment Type E sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>6</td>
<td>Segment Type F sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>7</td>
<td>Segment Type G sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>8</td>
<td>Segment Type H sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>14</td>
<td>Segment Type I sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>15</td>
<td>Segment Type J sub-TLV</td>
<td>RFC 9831</td>
</tr>
<tr>
<td>16</td>
<td>Segment Type K sub-TLV</td>
<td>RFC 9831</td>
</tr>
</tbody>
</table>
</section>
<section anchor="IANASIDFLAGS" numbered="true" toc="default">
<name>SR Policy Segment Flags</name>
<t>IANA has allocated code points from the "SR
Policy Segment Flags" registry <xref target="RFC9830" format="default"/>
under the "Border Gateway Protocol (BGP) Tunnel
Encapsulation" registry group.</t> Encapsulation" registry group.</t>
<t><figure align="center"> <table>
<artwork align="center"><![CDATA[ Bit Description <name>SR Policy Segment Flags</name>
Reference <thead>
1 SR Algorithm Flag (A-Flag) This document <tr>
2 SID Specified Flag (S-Flag) This document <th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>SR Algorithm Flag (A-Flag)</td>
<td>This document</td>
</tr>
<tr>
<td>2</td>
<td>SID Specified Flag (S-Flag)</td>
<td>This document</td>
</tr>
</tbody>
</table>
Table 2: SR Policy Segment Flags
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations in <xref <t>The security considerations in <xref target="RFC9830" format="default"/
target="I-D.ietf-idr-sr-policy-safi"/> apply to the segment types > apply to the Segment Types
defined in this document. No additional security considerations are defined in this document. No additional security considerations are
introduced in this document.</t> introduced.</t>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>The operations and manageability considerations in <xref <t>The operations and manageability considerations in <xref target="RFC983
target="I-D.ietf-idr-sr-policy-safi"/> apply to the segment types 0" format="default"/> apply to the
Segment Types
defined in this document. No additional operations and manageability defined in this document. No additional operations and manageability
considerations are introduced in this document.</t> considerations are introduced.</t>
</section>
<section title="Acknowledgments">
<t>The authors of this document would like to Dan Romascanu, Stig
Venaas, and Russ Housley for their comments and review of this document.
The authors would like to thank Susan Hares for her detailed shepherd
review that helped in improving the document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.8174"?> <references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<?rfc include="reference.I-D.ietf-idr-sr-policy-safi"?> <!-- [RFC9830]
draft-ietf-idr-sr-policy-safi-13 companion doc RFC 9830.
-->
<?rfc include="reference.RFC.8402"?> <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" rol
e="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>
<?rfc include="reference.RFC.8660"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
</references>
<?rfc include="reference.RFC.9552"?> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to <contact fullname="Dan Romascanu"/>, <contact
fullname="Stig
Venaas"/>, and <contact fullname="Russ Housley"/> for their comments and r
eview.
The authors would like to thank <contact fullname="Susan Hares"/> for her
detailed shepherd
review that helped in improving the document.</t>
</section>
<?rfc include="reference.RFC.8754"?> <!-- [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.
-->
<?rfc include="reference.RFC.9256"?> <!-- [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.
<?rfc include="reference.RFC.8986"?> Note that our script did not flag any words in particular, but this
</references> should still be reviewed as a best practice.
-->
<references title="Informational References"/>
</back> </back>
</rfc> </rfc>
 End of changes. 113 change blocks. 
596 lines changed or deleted 793 lines changed or added

This html diff was produced by rfcdiff 1.48.