rfc9947xml2.original.xml   rfc9947.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc
category="exp"
submissionType="independent"
ipr="trust200902"
docName="draft-fz-spring-srv6-alt-mark-17" >
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?> <!-- Controls display of <cref> elements -->
<?rfc inline="no" ?> <!-- When no, put comments at end in comments sectio
n,
otherwise, put inline -->
<?rfc editing="no" ?> <!-- When yes, insert editing marks: editing marks c
onsist of a
string such as <29> printed in the blank line a
t the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists
on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <!-- If "yes" eliminates blank lines before main sect
ion entries. -->
<?rfc tocdepth="3"?> <!-- Sets the number of levels of sections/subsection
s... in ToC -->
<!-- Choose the options for the references. <!DOCTYPE rfc [
Some like symbolic tags in the references (and citations) and others pr <!ENTITY nbsp "&#160;">
efer <!ENTITY zwsp "&#8203;">
numbers. The RFC Editor always uses symbolic tags. <!ENTITY nbhy "&#8209;">
The tags used are the anchor attributes of the references. --> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes" ?> <!-- If "yes", causes the references to be sorted in
order of tags.
This doesn't have any effect unless symrefs is
"yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by no <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" submissionType="i
t starting each ndependent" ipr="trust200902" docName="draft-fz-spring-srv6-alt-mark-17" number=
main section on a new page but does not omit the blank lines between li "9947" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symR
st items. efs="true" sortRefs="true" version="3">
If subcompact is also "yes" the blank lines between list items are also
omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="SRv6 AMM">Application of the Alternate-Marking Method to the
if the Segment Routing Header</title>
full title is longer than 42 characters --> <seriesInfo name="RFC" value="9947"/>
<title abbrev="SRv6 AMM">Application of the Alternate Marking Method to the
Segment Routing Header</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola"> <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>Viale Martesana, 12</street> <street>Viale Martesana, 12</street>
<city>Vimodrone (Milan)</city> <city>Vimodrone (Milan)</city>
<region></region>
<code>20055</code> <code>20055</code>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>giuseppe.fioccola@huawei.com</email> <email>giuseppe.fioccola@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Tianran Zhou" initials="T." surname="Zhou"> <author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>156 Beiqing Rd.</street> <street>156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region></region>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhoutianran@huawei.com</email> <email>zhoutianran@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Gyan S. Mishra" initials="G." surname="Mishra"> <author fullname="Gyan S. Mishra" initials="G." surname="Mishra">
<organization>Verizon Inc.</organization> <organization>Verizon Inc.</organization>
<address> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>gyan.s.mishra@verizon.com</email> <email>gyan.s.mishra@verizon.com</email>
</address> </address>
</author> </author>
<author fullname="Xuewei Wang" initials="X." surname="Wang"> <author fullname="Xuewei Wang" initials="X." surname="Wang">
<organization>Ruijie</organization> <organization>Ruijie</organization>
<address> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>wangxuewei1@ruijie.com.cn</email> <email>wangxuewei1@ruijie.com.cn</email>
</address> </address>
</author> </author>
<author fullname="Geng Zhang" initials="G." surname="Zhang"> <author fullname="Geng Zhang" initials="G." surname="Zhang">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>zhanggeng@chinamobile.com</email> <email>zhanggeng@chinamobile.com</email>
</address> </address>
</author> </author>
<author fullname="Mauro Cociglio" initials="M." surname="Cociglio"> <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
<organization></organization> <organization/>
<address> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>mauro.cociglio@outlook.com</email> <email>mauro.cociglio@outlook.com</email>
</address> </address>
</author> </author>
<date year="2026" month="March"/>
<date year="2025"/> <!-- month="March" is no longer necessary <keyword>SRH</keyword>
note also, day="30" is optional --> <keyword>TLV</keyword>
<!-- WARNING: If the month and year are the current ones, xml2rfc will fill <keyword>Extension</keyword>
in the day for <keyword>Header</keyword>
you. If only the year is specified, xml2rfc will fill in the current da <keyword>Option</keyword>
y and month <keyword>Performance</keyword>
irrespective of the day. This silliness should be fixed in v1.31. --> <keyword>Measurement</keyword>
<keyword>Monitoring</keyword>
<!-- Meta-data Declarations --> <keyword>Passive</keyword>
<keyword>Hybrid</keyword>
<!-- Notice the use of &amp; as an escape for & which would otherwise <keyword>Loss</keyword>
start an entity declaration, whereas we want a literal &. --> <keyword>Delay</keyword>
<keyword>Delay Variation</keyword>
<area></area> <keyword>Multipoint</keyword>
<keyword>Cluster</keyword>
<!-- WG name at the upperleft corner of the doc, <keyword>Closed-Loop</keyword>
IETF fine for individual submissions. You can also
omit this element in which case in defaults to "Network Working Group"
-
a hangover from the ancient history of the IETF! -->
<workgroup></workgroup>
<!-- The DTD allows multiple area and workgroup elements but only the first
one has any
effect on output. -->
<!-- You can add <keyword/> elements here. They will be incorporated into H
TML output
files in a meta tag but they have no effect on text or nroff output. --
>
<abstract> <abstract>
<t>This document describes an alternative experimental approach for the ap
<t>This document describes an alternative experimental approach for the plication of
application of the Alternate-Marking Method to Segment Routing for IPv6 (SRv6).
the Alternate-Marking Method to SRv6. It uses an experimental TLV It uses an experimental TLV in the Segment Routing Header (SRH);
in the Segment Routing Header, thus, participation in this experiment should be between coordina
and thus participation in this experiment should be between coord ting parties in a controlled domain.
inating parties in a controlled domain.
This approach has potential scaling and simplification benefits o ver the technique This approach has potential scaling and simplification benefits o ver the technique
described in RFC 9343 and the scope of the experiment is to deter mine whether described in RFC 9343, and the scope of the experiment is to dete rmine whether
those are significant and attractive to the community.</t> those are significant and attractive to the community.</t>
<t>This protocol extension has been developed outside the IETF as an
<t>This protocol extension has been developed outside the IETF as an alternative to the IETF's Standards Track specification RFC 9343 and it
alternative to the IETF&apos;s standards track specification RFC does not have IETF consensus. It is published here to guide experimental
9343 and implementation and ensure interoperability among implementations to
it does not have IETF consensus. It is published here to guide better determine the value of this approach. Researchers are invited to
experimental implementation, ensure interoperability among implem submit their evaluations of this work to the Independent Submissions
entations Editor or to the IETF SPRING Working Group as Internet-Drafts.</t>
to better determine the value of this approach.
Researchers are invited to submit their evaluations of this work
to the RFC Editor for consideration as independent submissions or
to the IETF SPRING working group as Internet-Drafts.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<name>Introduction</name>
<section title="Introduction">
<t><xref target="RFC9341"></xref> and <xref target="RFC9342"></xref> <t><xref target="RFC9341" format="default"/> and <xref target="RFC9342" fo rmat="default"/>
describe a passive performance measurement method, which can be used to m easure packet loss, describe a passive performance measurement method, which can be used to m easure packet loss,
latency and jitter on live traffic. Since this method is based on marking latency, and jitter on live traffic. Since this method is based on markin
consecutive g consecutive
batches of packets, the method is often referred as the Alternate Marking batches of packets, the method is often referred as the "Alternate-Markin
Method.</t> g Method".</t>
<t>The Alternate-Marking Method requires a marking field so that packet fl
<t>The Alternate Marking Method requires a marking field so that packet f ows
lows can be distinguished and identified. <xref target="RFC9343" format="defau
can be distinguished and identified. <xref target="RFC9343"/> defines the lt"/> defines the standard for how
standard for how the marking field can be encoded in a new TLV in either Hop-by-Hop or
the marking field can be encoded in a new TLV in either Hop-by-hop or Destination Options Headers
Destination Options Headers of IPv6 packets in order to achieve Alternate Marking. This mechanism
of IPv6 packets in order to achieve Alternate Marking. The mechanism t is equally
o carry is equally applicable to Segment Routing for IPv6 (SRv6) networks <xref target="R
applicable to Segment Routing for IPv6 (SRv6) networks <xref target="R FC8402" format="default"/>.</t>
FC8402"/>.</t> <t>This document describes an alternative experimental approach that encod
es the
<t>This document describes an alternative experimental approach that e marking field in a new TLV carried in the Segment Routing Header (SRH)
ncodes the <xref target="RFC8754" format="default"/>
marking field in a new TLV carried in the Segment Routing Header (SRH)
<xref target="RFC8754"/>
of an SRv6 packet. This approach is applicable only to SRv6 deployment s. It is intended to capitalize on the of an SRv6 packet. This approach is applicable only to SRv6 deployment s. It is intended to capitalize on the
assumption that Segment Routing (SR) nodes are supposed to support fas t parsing and processing assumption that Segment Routing (SR) nodes are supposed to support fas t parsing and processing
of the SRH, while the SR nodes may not handle properly Destination Opt of the SRH, while the SR nodes may not properly handle Destination Opt
ions, as discussed in ions, as discussed in
<xref target="RFC9098"/>, <xref target="I-D.ietf-6man-eh-limits"/>. <xref target="RFC9098" format="default"/> and <xref target="I-D.ietf-6
man-eh-limits" format="default"/>.
The experiment is to determine whether or not there are significant an d attractive advantages The experiment is to determine whether or not there are significant an d attractive advantages
to the community: if there are, the work may be brought back for IETF consideration.</t> to the community: if there are, the work may be brought back for IETF consideration.</t>
<t>This protocol extension has been developed outside the IETF as an <t>This protocol extension has been developed outside the IETF as an
alternative to the IETF&apos;s standards track specification <xref tar alternative to the IETF's Standards Track specification <xref
get="RFC9343"/> and target="RFC9343" format="default"/>; it does not have IETF consensus. It
it does not have IETF consensus. It is published here to guide experim is published here to guide experimental implementation and ensure
ental implementation, interoperability among implementations to better determine the value of
ensure interoperability among implementations to better determine the this approach. As also highlighted in <xref
value of this approach. target="I-D.bonica-gendispatch-exp" format="default"/>, when two
As also highlighted in <xref target="I-D.bonica-gendispatch-exp"/>, wh protocol extensions are proposed to solve a single problem, an
en two protocol extensions experiment can be initiated to gather operational experience and
are proposed to solve a single problem, an experiment can be initiated "determine which, if either, of the protocols should be progressed to
and this is the purpose the standards track." This is the purpose of this document. See <xref
of this document. See <xref target="experimentation"/> for more detail target="experimentation" format="default"/> for more details about the
s about the experimentation.</t> experiment.</t>
<section anchor="observations" title="Observations on RFC 9343">
<section anchor="observations" numbered="true" toc="default">
<name>Observations on RFC 9343</name>
<t>Like any other IPv6 use case, Hop-by-Hop and Destination Options can also be used when the SRH is present. <t>Like any other IPv6 use case, Hop-by-Hop and Destination Options can also be used when the SRH is present.
As specified in <xref target="RFC8200"/>, the Hop-by-Hop Options Head er is used to carry optional information As specified in <xref target="RFC8200" format="default"/>, the Hop-by -Hop Options Header is used to carry optional information
that needs to be examined at every hop along the path, while the Dest ination Options Header is used to carry optional information that needs to be examined at every hop along the path, while the Dest ination Options Header is used to carry optional information
that needs to be examined only by the packet's destination node(s).</ t> that needs to be examined only by the packet's destination node(s).</ t>
<t>When a Routing Header exists, because the SRH is a Routing Header,
Destination Options present in the IPv6 packet before the SRH header
are processed by the destination indicated in the SRH's route list. As
specified in <xref target="RFC8754" format="default"/>, SR segment
endpoint nodes process the local Segment Identifier (SID)
corresponding to the packet destination address. Then, the destination
address is updated according to the segment list. The SRH TLV
provides metadata for segment processing, while processing the SID, if
the node is locally configured to do so. Both the Destination Options
Header before the SRH and the SRH TLV are processed at the node being
indicated in the destination address field of the IPv6 header.</t>
<t>When a Routing Header exists, because the SRH is a Routing Header, <t>The distinction between the alternatives is most notable for SRv6
Destination Options present in the IPv6 packets that traverse a network where the paths between sequential
packet before the SRH header are processed by destination indicat segment endpoints include multiple hops. If the Hop-by-Hop Option is
ed in the SRH&apos;s route list. used, then every hop along the path will process the AltMark data. If
As specified in <xref target="RFC8754"/>, SR segment endpoint nodes p the Destination Option positioned before the SRH is used, or the SRH
rocess the local SID corresponding AltMark TLV is used, then only the segment endpoints will process the
to the packet destination address. Then, the destination address is u AltMark data, unless the intermediate node has a different priority rule
pdated according to the segment list. .</t>
The SRH TLV provides metadata for segment processing, while processin <t>Both <xref target="RFC9343" format="default"/> and the approach
g the SID, if the node is locally configured to do so. specified in this document can coexist. Indeed, this document does
Both the Destination Options Header before SRH and the SRH TLV are pr not change or invalidate any procedures defined in <xref
ocessed at the node being indicated in the target="RFC9343" format="default"/>. However, deployment issues may
destination address field of the IPv6 header.</t> arise, as further discussed below.</t>
<t>The rest of this document is structured as follows:</t>
<t>The distinction between the alternatives is most notable for SRv6 pac <ul>
kets that traverse a network where the paths <li><xref target="SRv6AltMark" format="default"/> covers the applicatio
between sequential segment end points include multiple hops. If the Hop- n of the
by-Hop Option is used, then every hop along the Alternate-Marking Method to SRv6,</li>
path will process the AltMark data. If the Destination Option positioned <li><xref target="AltMarkTLV" format="default"/> specifies the AltMark SR
before the SRH is used, or the SRH AltMark TLV is H TLV to carry the base
used, then only the segment end points will process the AltMark data.</t data fields (<xref target="base" format="default"/>) and the extended
> data fields (<xref target="extended" format="default"/>),</li>
<li><xref target="Use" format="default"/> discusses the use of the AltMar
<t>Both <xref target="RFC9343"/> and the approach specified in this d k TLV,
ocument can co-exist. Indeed, this document does not change and</li>
or invalidate any procedures defined in <xref target="RFC9343"/>. <li><xref target="experimentation" format="default"/> describes the
However, deployment issues may arise, as further discussed below.</t> experiment and the objectives of the experimentation (<xref
target="objective" format="default"/>).</li>
<t>The rest of this document is structured as follows: <xref targ </ul>
et="SRv6AltMark"/> covers the application of the Alternate Marking to SRv6, </section>
<xref target="AltMarkTLV"/> specifies the AltMark SRH TLV to carr <section numbered="true" toc="default">
y the base data fields (<xref target="base"/>) and the <name>Requirements Language</name>
extended data fields (<xref target="extended"/>), <xref target="U <t>
se"/> discusses the use of the AltMark TLV, and <xref target="experimentation"/> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
describes the experiment and the objectives of the experimentatio "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
n (<xref target="objective"/>).</t> ",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</section> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<section title="Requirements Language"> be
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
", target="RFC8174"/> when, and only when, they appear in all capitals, as
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", an shown here.
d </t>
"OPTIONAL" in this document are to be interpreted as described in B </section>
CP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh
en,
they appear in all capitals, as shown here.</t>
</section>
</section> </section>
<section anchor="SRv6AltMark" title="Application of the Alternate Marking <section anchor="SRv6AltMark" numbered="true" toc="default">
to SRv6"> <name>Application of the Alternate-Marking Method to SRv6</name>
<t>SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata
<t>SRv6 leverages the IPv6 SRH, that can embed TLVs to provide metadata fo for segment processing, as described in <xref target="RFC8754"
r segment processing, as described in <xref target="RFC8754"/>. format="default"/>. This document defines the SRH AltMark TLV to carry
This document defines the SRH AltMark TLV to carry Alternate Marking data Alternate-Marking data fields for use in SRv6 networks, and it is an
fields for use in SRv6 networks and it is an alternative alternative to the method described in <xref target="RFC9343" format="defa
to <xref target="RFC9343"/>. <xref target="RFC9343"/> defines how the A ult"/>. <xref
lternate Marking Method can be carried in the Option Headers target="RFC9343" format="default"/> defines how the Alternate-Marking
(Hop-by-hop or Destination) of an IPv6 packet. The AltMark data fields Method can be carried in the Option Headers (Hop-by-Hop or Destination)
format defined in <xref target="RFC9343"/> is the basis of the of an IPv6 packet. The AltMark data fields format defined in <xref
AltMark SRH TLV introduced in <xref target="AltMarkTLV"/>.</t> target="RFC9343" format="default"/> is the basis of the AltMark SRH TLV
introduced in <xref target="AltMarkTLV" format="default"/>.</t>
<t>In addition to the base data fields of <xref target="RFC9343"></xref <t>In addition to the base data fields of <xref target="RFC9343"
>, it is also allowed the insertion of optional extended data fields format="default"/>, the insertion of optional
which are not present in <xref target="RFC9343"></xref>. These extended extended data fields that are not present in <xref target="RFC9343"/> is also
data fields can support metadata for additional telemetry requirements, allowed.
as further described below.</t> These extended data fields can support metadata for
additional telemetry requirements, as further described below.</t>
<section anchor="control" title="Controlled Domain"> <section anchor="control" numbered="true" toc="default">
<t><xref target="RFC8799"/> introduces the concept of specific limited d
omain solutions and
notes application of the Alternate Marking Method as an example.</t>
<t>Despite the flexibility of IPv6, when innovative applications are pro <name>Controlled Domain</name>
posed they are often <t><xref target="RFC8799" format="default"/> introduces the concept of s
pecific limited domain solutions and
notes the application of the Alternate-Marking Method as an example.</t>
<t>Despite the flexibility of IPv6, when innovative applications are pro
posed, they are often
applied within controlled domains to help constrain the domain-wide poli cies, options supported, applied within controlled domains to help constrain the domain-wide poli cies, options supported,
the style of network management, and security requirements. This is also the style of network management, and security requirements. This is also
the case for the application the case for applying
of the Alternate Marking Method to SRv6.</t> the Alternate-Marking Method to SRv6.</t>
<t>Therefore, the experiment of applying the Alternate-Marking Method
<t>Therefore, the experimentation of the Alternate Marking Method to SRv to SRv6 <bcp14>MUST</bcp14> only be deployed within a controlled
6 MUST be deployed only within domain. For SRv6, the controlled domain corresponds to an SR domain,
a controlled domain. For SRv6, the controlled domain corresponds to an S as defined in <xref target="RFC8402" format="default"/>. The
R domain, as defined in <xref target="RFC8402"/>. Alternate-Marking measurement domain overlaps with the controlled
The Alternate-Marking measurement domain overlaps with the contro domain.</t>
lled domain.</t>
<t>The use of a controlled domain is also appropriate for the dep
loyment of an experimental protocol extension.
Carefully bounding the domain reduces the risk of the experiment
leaking out and clashing with other
experiments of causing unforeseen consequences in wider deploymen
ts.</t>
</section>
<t>The use of a controlled domain is also appropriate for the
deployment of an experimental protocol extension. Carefully bounding
the domain reduces the risk of the experiment leaking out and clashing
with other experiments or causing unforeseen consequences in wider
deployments.</t>
</section>
</section> </section>
<section anchor="AltMarkTLV" numbered="true" toc="default">
<section anchor="AltMarkTLV" title="Definition of the SRH AltMark TLV"> <name>Definition of the SRH AltMark TLV</name>
<t>The AltMark SRH TLV is defined to carry the data fields associated with
<t>The AltMark SRH TLV is defined to carry the data fields associated wi the Alternate-Marking Method.
th the Alternate Marking Method. The TLV has some initial fields that are always present and further exte
The TLV has some initial fields that are always present, and further ext nsion fields that are
ension fields that are
present when Enhanced Alternate Marking is in use.</t> present when Enhanced Alternate Marking is in use.</t>
<t><xref target="AltMarkFig" format="default"/> shows the format of the Al
<t><xref target="AltMarkFig"/> shows the format of the AltMark TLV.</t> tMark TLV.</t>
<figure anchor="AltMarkFig">
<figure anchor="AltMarkFig"> <name>The AltMark SRH TLV for Alternate Marking</name>
<name>AltMark: SRH TLV for alternate marking</name> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
<![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRH TLV Type | SRH TLV Len | Reserved | | SRH TLV Type | SRH TLV Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowMonID |L|D| Reserved | NH | | FlowMonID |L|D| Reserved | NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional extended data fields (variable) ~ ~ Optional extended data fields (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]> </figure>
</artwork> <t>The fields of this TLV are as follows:</t>
</figure>
<t>The fields of this TLV are as follows:
<list style="symbols">
<t>SRH TLV Type: 8 bit identifier of the Alternate Marking SRH TLV.
The
value for this field is taken from the range 124-126. It is an
Experimental code point that indicates a TLV that does no
t change en
route. Experimentation of this document must coordinate the value
used by all implementations participating in the experime
nt.
Therefore, experiments should carefully consider any othe
r implementations
running in the controlled domain to avoid clashes with ot
her SRH TLVs.</t>
<t>SRH TLV Len: The length of the Data Fields of this TLV in bytes.
This
is set to 6 when Enhanced Alternate Marking is not in use.</t>
<t>Reserved: Reserved for future use. These bits MUST be set to zero
on transmission and ignored on receipt.</t>
<t>FlowMonID: Flow Monitoring Identification field, 20 bits unsigned
integer. It is defined in <xref target="RFC9343"/>.</t>
<t>L: Loss flag, as defined in <xref target="RFC9343"/>.</t>
<t>D: Delay flag, as defined in <xref target="RFC9343"/>.</t>
<t>NH: The NH (NextHeader) field is used to indicate extended data f
ields are present to
support Enhanced Alternate Marking as follows:
<list>
<t>NextHeader value of 0x0 means that there is no extended data
field attached.</t>
<t>NextHeader values of 0x1-0x8 are reserved for further usage.<
/t>
<t>NextHeader value of 0x9 indicates the extended data fields ar
e present as
described in <xref target="extended"/>.</t>
<t>NextHeader values of 0xA-0xF are reserved for further usage.<
/t>
</list>
</t>
<t>Optional extended data fields may be present according to the set
ting of the NH field
and as described in <xref target="extended"/>.</t>
</list>
</t>
<section anchor="base" title="Base Alternate Marking Data Fields">
<t>The base AltMark data fields are: Loss Flag (L), Delay
Flag (D) and Flow Monitoring Identification field (FlowMonID),
as in <xref target="RFC9343"></xref>.</t>
<t>L and D are the marking fields of the Alternate Markin
g Method while FlowMonID is used to identify monitored flows and aids the
optimization of implementation and scaling of the Alterna
te Marking Method. Note that, as already highlighted in <xref target="RFC9343"><
/xref>,
the FlowMonID is used to identify the monitored flow beca
use it is not possible to utilize the Flow Label field of the IPv6 Header.</t>
<t>It is important to note that if the 20 bit FlowMonID is set by th <dl spacing="normal" newline="false">
e domain entry nodes, there is a <dt>SRH TLV Type:</dt><dd>The 8-bit identifier of the
chance of collision even when the values are chosen using a pseudo-r Alternate-Marking SRH TLV. The value for this field is taken from the
andom algorithm; therefore it may be range 124-126. It is an Experimental code point that indicates a TLV
not be sufficient to uniquely identify a monitored flow. In such cas that does not change en route. Deployment of this document must
es the packets need to be tagged with additional coordinate the value used by all implementations participating in the
experiment. Therefore, experiments should carefully consider any
other implementations running in the controlled domain to avoid
clashes with other SRH TLVs.</dd>
<dt>SRH TLV Len:</dt><dd>The length of the Data Fields of this TLV in
bytes. This is set to 6 when Enhanced Alternate Marking is not in
use.</dd>
<dt>Reserved:</dt><dd>Reserved for future use. These bits
<bcp14>MUST</bcp14> be set to zero on transmission and ignored on
receipt.</dd>
<dt>FlowMonID:</dt><dd>The Flow Monitoring Identification field. It is a
20-bit
unsigned integer as defined in <xref target="RFC9343"
format="default"/>.</dd>
<dt>L:</dt><dd>The Loss flag, as defined in <xref target="RFC9343"
format="default"/>.</dd>
<dt>D:</dt><dd>The Delay flag, as defined in <xref target="RFC9343"
format="default"/>.</dd>
<dt>NH:</dt><dd><t>The NextHeader field. It is used to indicate extended
data fields are present to support Enhanced Alternate Marking as
follows:</t>
<ul spacing="normal">
<li>
<t>NextHeader value of 0x0 means that there is no extended data fi
eld attached.</t>
</li>
<li>
<t>NextHeader values of 0x1-0x8 are reserved for further usage.</t
>
</li>
<li>
<t>NextHeader value of 0x9 indicates the extended data fields are
present as
described in <xref target="extended" format="default"/>.</t>
</li>
<li>
<t>NextHeader values of 0xA-0xF are reserved for further usage.</t
>
</li>
</ul>
</dd></dl>
<t>Optional extended data fields may be present according to the setti
ng of the NH field
and as described in <xref target="extended" format="default"/>.</t>
<section anchor="base" numbered="true" toc="default">
<name>Base Alternate-Marking Data Fields</name>
<t>The base AltMark data fields are: the Loss (L) flag, the Delay (D) fl
ag, and the
Flow Monitoring Identification (FlowMonID) field, as in <xref
target="RFC9343" format="default"/>.</t>
<t>L and D are the marking fields of the Alternate-Marking Method,
while FlowMonID is used to identify monitored flows and aids the
optimization of implementation and scaling of the Alternate-Marking
Method. Note that, as already highlighted in <xref target="RFC9343"
format="default"/>, the FlowMonID is used to identify the monitored
flow because it is not possible to utilize the Flow Label field of the
IPv6 Header.</t>
<t>It is important to note that if the 20-bit FlowMonID is set by the do
main entry nodes, there is a
chance of collision even when the values are chosen using a pseudora
ndom algorithm; therefore, it may not be
sufficient to uniquely identify a monitored flow. In such cases, the
packets need to be tagged with additional
flow information to allow disambiguation. Such additional tagging ca n be carried in the extended data fields flow information to allow disambiguation. Such additional tagging ca n be carried in the extended data fields
described in <xref target="extended"/>.</t> described in <xref target="extended" format="default"/>.</t>
</section> </section>
<section anchor="extended" numbered="true" toc="default">
<section anchor="extended" title="Optional Extended Data Fields for Enha <name>Optional Extended Data Fields for Enhanced Alternate Marking</name
nced Alternate Marking"> >
<t>The optional extended data fields to support Enhanced Alternate Marki
<t>The optional extended data fields to support Enhanced Alternate M ng are illustrated in
arking are illustrated in <xref target="extendedFig" format="default"/>. They are present when
<xref target="extendedFig"/>. They are present when the NH field of the NH field of the AltMark TLV is set to 0x9.</t>
the AltMark TLV is set to 0x9.</t> <figure anchor="extendedFig">
<name>Optional Extended Data Fields for Enhanced Alternate Marking</na
<figure anchor="extendedFig" > me>
<name>Optional Extended Data Fields for Enhanced Alternate Marking <artwork align="center" name="" type="" alt=""><![CDATA[
</name>
<artwork align="center">
<![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowMonID Ext |M|F|W|R| Len | Rsvd | | FlowMonID Ext |M|F|W|R| Len | Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MetaInfo | Optional MetaData ~ | MetaInfo | Optional MetaData ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional MetaData (variable) ~ ~ Optional MetaData (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]> </figure>
</artwork> <t>The extended data fields are as follows:</t>
</figure>
<t>The extended data fields are as follows:
<list style="symbols">
<t>FlowMonID Ext - 20 bits unsigned integer. This is used to exte
nd
the FlowMonID in order to reduce the conflict when random allocat
ion
is applied. The disambiguation of the FlowMonID field is discusse
d in
<xref target="RFC9343">IPv6 AltMark Option</xref>.</t>
<t>Four bit-flags indicate special-purpose usage.
<list style="hanging">
<t hangText='M bit:'>Measurement mode. If M=0, it indicates t
hat it is
for segment-by-segment monitoring. If M=1, it indicates that
it is for
end-to-end monitoring.</t>
<t hangText='F bit:'>Fragmentation. If F=1, it indicates that
the original packet
is fragmented, therefore it is necessary to only count a sing
le packet,
ignoring all the following fragments with F set to 1.
Note that F is set to 0 for the first fragment
.</t>
<t hangText='W bit:'>Flow direction identification. This flag
is used
if backward direction flow monitoring is requested to be
set up automatically, so that the egress node is instructed t
o setup the
backward flow monitoring. If W=1, it indicates
that the flow direction is
forward. If W=0, it indicates that the flow direction is back
ward.</t>
<t hangText='R bit:'>Reserved. This bit MUST be set to zero a
nd ignored on receipt.</t>
</list>
</t>
<t>Len - Length. Indicates the length of the extended data fields
in bytes for enhanced alternate
marking. It includes all of the fields shown in <xref target="ext
endedFig"/> including any
meta data that is present.</t>
<t>Rsvd - Reserved for further use. These bits MUST be set to zer
o on
transmission and ignored on receipt.</t>
<t>MetaInfo - A 16-bit Bitmap to indicate more meta data attached
in the Optional MetaData field
for enhanced functions. More than one bit may be set, in which ca
se the additional meta data is
present in the order that the bits are set. MetaInfo bits are num
bered from 0 as the most significant bit.
Three bits and associated meta data are defined as follows:
<list style="hanging"> <dl spacing="normal" newline="false">
<t hangText='bit 0:'>If set to 1, it indicates that a 6 byte
Timestamp is present as shown in <xref target="timestampFig"/>.
<figure anchor="timestampFig"> <dt>FlowMonID Ext:</dt><dd>20-bit unsigned integer used to
<name>The Timestamp Extended Data Field</name> extend the FlowMonID in order to reduce the conflict when random
<artwork align="center"> allocation is applied. The disambiguation of the FlowMonID field is
<![CDATA[ discussed in "IPv6 Application of the Alternate-Marking Method" <xref
target="RFC9343" format="default"/>.</dd>
<dt>Four different bit flags indicate special-purpose usage.</dt><dd><
t><br/></t>
<dl newline="false" spacing="normal">
<dt>M bit:</dt><dd>Measurement mode. If M=0, it indicates that
it is for segment-by-segment monitoring. If M=1, it indicates
that it is for end-to-end monitoring.</dd>
<dt>F bit:</dt><dd>Fragmentation. If F=1, it indicates that the
original packet is fragmented; therefore, it is necessary to only
count a single packet, ignoring all the following fragments with
F set to 1. Note that F is set to 0 for the first
fragment.</dd>
<dt>W bit:</dt><dd>Flow direction identification. This flag is
used if backward direction flow monitoring is requested to be
set up automatically, so that the egress node is instructed to
setup the backward flow monitoring. If W=1, it indicates that
the flow direction is forward. If W=0, it indicates that the
flow direction is backward.</dd>
<dt>R bit:</dt><dd>Reserved. This bit <bcp14>MUST</bcp14> be
set to zero and ignored on receipt.</dd>
</dl>
</dd>
<dt>Len:</dt><dd>Length. Indicates the length of the extended data
fields for Enhanced Alternate Marking as a multiple of 4 bytes. It inc
ludes all of
the fields shown in <xref target="extendedFig" format="default"/>
including any metadata that is present.</dd>
<dt>Rsvd:</dt><dd>Reserved for further use. These bits
<bcp14>MUST</bcp14> be set to zero on transmission and ignored on
receipt.</dd>
<dt>MetaInfo:</dt><dd><t>A 16-bit Bitmap to indicate more metadata
attached in the Optional MetaData field for enhanced functions. More
than one bit may be set, in which case the additional metadata is
present in the order that the bits are set. MetaInfo bits are
numbered from 0 as the most significant bit. Three bits and
associated metadata are defined as follows:</t>
<dl newline="false" spacing="normal">
<dt>bit 0:</dt>
<dd><t>If set to 1, it indicates that a 6-byte Timestamp is presen
t
as shown in <xref target="timestampFig" format="default"/>.</t>
<figure anchor="timestampFig">
<name>The Timestamp Extended Data Field</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp(s) | | Timestamp(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp(ns) | | Timestamp(ns) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]> </figure>
</artwork> <t>This Timestamp can be filled by the encapsulation node
</figure> and is taken all the way to the decapsulation node so that all
the intermediate nodes can compare it against their local
This Timestamp can be filled by the encapsulation node, and i time and measure the one-way delay. The Timestamp consists of
s taken two fields:</t>
all the way to the decapsulation node so that all the interme <dl newline="false" spacing="normal">
diate nodes <dt>Timestamp(s):</dt><dd>A 16-bit integer that carries the nu
can compare it against their local time, and measure the one mber of seconds.</dd>
way delay. The <dt>Timestamp(ns):</dt><dd>A 32-bit integer that carries the n
timestamp consists of two fields: umber of nanoseconds.</dd>
<list> </dl>
<t>Timestamp(s) is a 16 bit integer that carries the numb <t>Note that the Timestamp data field enables all the
er of seconds.</t> intermediate nodes to measure the one-way delay. It can be
<t>Timestamp(ns) is a 32 bit integer that carries the num correlated with the implementation of <xref
ber of nanoseconds.</t> target="I-D.ietf-opsawg-ipfix-on-path-telemetry"
</list> format="default"/> and <xref
Note that the timestamp data field enables all target="I-D.ietf-ippm-on-path-telemetry-yang"
the intermediate nodes to measure the one way delay. format="default"/>. <xref
It can be correlated with the implementation o target="I-D.ietf-opsawg-ipfix-on-path-telemetry"
f <xref target="I-D.ietf-opsawg-ipfix-on-path-telemetry"/> and format="default"/> introduces new IP Flow Information Export
<xref target="I-D.ietf-ippm-on-path-telemetry- (IPFIX) information elements to expose the On-Path Telemetry
yang"/>. measured delay. Similarly, <xref
<xref target="I-D.ietf-opsawg-ipfix-on-path-te target="I-D.ietf-ippm-on-path-telemetry-yang"
lemetry"/> introduces new IP Flow Information Export (IPFIX) information element format="default"/> defines a YANG data model for monitoring
s On-Path Telemetry data, including the path delay.</t>
to expose the On-Path Telemetry measured delay </dd>
, similarly, <xref target="I-D.ietf-ippm-on-path-telemetry-yang"/> defines a YAN <dt>bit 1:</dt>
G data model <dd><t>If set to 1, it indicates the control information to set
for monitoring On-Path Telemetry data, includi up the backward direction flow monitoring based on the trigger
ng the path delay. packet presence as shown in <xref target="controlFig"
</t> format="default"/>.</t>
<t hangText='bit 1:'>If set to 1, it indicates the control in
formation to set up
the backward direction flow monitoring based on the trigger p
acket presence
as shown in <xref target="controlFig"/>.
<figure anchor="controlFig"> <figure anchor="controlFig">
<name>Control Information for Backward Direction Flow Mon <name>Control Information for Backward Direction Flow Monitori
itoring</name> ng</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIP Mask | SIP Mask |P|I|O|V|S|T| Period | | DIP Mask | SIP Mask |P|I|O|V|S|T| Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]> </figure>
</artwork> <t>The control information includes several fields and flags
</figure> to match in order to set up the backward direction:</t>
<dl newline="false" spacing="normal">
The control information includes several fields and flags to <dt>DIP Mask:</dt><dd>The length of the destination IP prefix
match in order to set up the used to match the flow.</dd>
backward direction: <dt>SIP Mask:</dt><dd>The length of the source IP prefix used
<list> to match the flow.</dd>
<dt>P bit:</dt><dd>If set to 1, it indicates to match the flow
<t>DIP Mask: The length of the destination IP prefix used using the protocol identifier in the trigger packet.</dd>
to match the flow.</t> <dt>I bit:</dt><dd>If set to 1, it indicates to match the sour
ce port.</dd>
<t>SIP Mask: The length of the source IP prefix used to m <dt>O bit:</dt><dd>If set to 1, it indicates to match the dest
atch the flow.</t> ination port.</dd>
<dt>V bit:</dt><dd>If set to 1, the node will automatically
<t>P bit: If set to 1, it indicates to match the flow usi set up reverse direction monitoring and allocate a
ng the protocol identifier in the trigger packet.</t> FlowMonID.</dd>
<dt>S bit:</dt><dd>If set to 1, it indicates to match the Diff
<t>I bit: If set to 1, it indicates to match the source p erentiated Services Code Point (DSCP).</dd>
ort.</t> <dt>T bit:</dt><dd>Used to control the scope of tunnel
measurement. T=1 means measure between Network-to-Network
<t>O bit: If set to 1, it indicates to match the destinat Interfaces (i.e., NNI to NNI). T=0 means measure between
ion port.</t> User-to-Network Interfaces (i.e., UNI to UNI).</dd>
<dt>Period:</dt><dd>Indicates the Alternate-Marking period cou
<t>V bit: If set to 1, the node will automatically set up nted in seconds.</dd>
reverse direction monitoring, and allocate a FlowMonID.</t> </dl>
</dd>
<t>S bit: If set to 1, it indicates to match the DSCP.</t <dt>bit 2:</dt>
> <dd>
<t>If set to 1, it indicates that a 4-byte Sequence Number is
<t>T bit: Used to control the scope of tunnel measurement present as shown in <xref target="seqnoFig"
. T=1 means measure between Network-to-Network Interfaces (i.e., NNI to NNI). format="default"/>.</t>
T=0 means measure between User-to-Network Interfaces (i.e
., UNI to UNI).</t>
<t>Period: Indicates the alternate marking period counted
in seconds.</t>
</list>
</t>
<t hangText='bit 2:'>If set to 1, it indicates that a 4 byte
sequence number is present as shown in <xref target="seqnoFig"/>.
<figure anchor="seqnoFig"> <figure anchor="seqnoFig">
<name>Sequence Number Data Field</name> <name>Sequence Number Data Field</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]> </figure>
</artwork> <t>The unique Sequence Number can be used to detect the
</figure> out-of-order packets, in addition to enabling packet loss
measurement. Moreover, the Sequence Number can be used
The unique Sequence Number can be used to detect the out-of together with the latency measurement to access per-packet
-order packets, Timestamps.</t>
in addition to enabling packet loss measurement. Moreover, </dd>
the Sequence </dl>
Number can be used together with the latency measurement, t </dd>
o access </dl>
per packet timestamps.</t>
</list>
</t>
</list>
</t>
</section>
</section>
</section> </section>
<section anchor="Use" numbered="true" toc="default">
<section anchor="Use" title="Use of the SRH AltMark TLV"> <name>Use of the SRH AltMark TLV</name>
<t>Since the measurement domain is congruent with the SR-controlled domain
<t>Since the measurement domain is congruent with the SR controlled domain , the procedure
, the procedure
for AltMark data encapsulation in the SRv6 SRH is summarized as follows : for AltMark data encapsulation in the SRv6 SRH is summarized as follows :
<list style="symbols"> </t>
<ul spacing="normal">
<t>Ingress SR Node: As part of the SRH encapsulation, the Ingress SR N <li>
ode of an SR domain or <t>Ingress SR Node: As part of the SRH encapsulation, the Ingress SR
an SR Policy <xref target="RFC9256"/> that supports the mechanisms Node of an SR domain or an SR Policy <xref target="RFC9256"
defined in this document format="default"/> that supports the mechanisms defined in this
and that wishes to perform the Alternate Marking Method adds the Al document and that wishes to perform the Alternate-Marking Method
tMark TLV in the SRH of adds the AltMark TLV in the SRH of the data packets.</t>
the data packets.</t> </li>
<li>
<t>Intermediate SR Node: The Intermediate SR Node is any node receivin <t>Intermediate SR Node: The Intermediate SR Node is any node
g an IPv6 packet receiving an IPv6 packet where the destination address of that
where the destination address of that packet is a local Segment Ide packet is a local Segment Identifier (SID). If an Intermediate SR
ntifier (SID). If an Node is not capable of processing the AltMark TLV, it simply ignores i
Intermediate SR Node is not capable of processing AltMark TLV, it s t
imply ignores it according to according to the processing rules of <xref target="RFC8754"
the processing rules of <xref target="RFC8754"/>. If an Intermediat format="default"/>. If an Intermediate SR Node is capable of
e SR Node processing the AltMark TLV, it checks if the SRH AltMark TLV is presen
is capable of processing AltMark TLV, it checks if SRH AltMark TLV t
is present in the packet in the packet and processes it.</t>
and processes it.</t> </li>
<li>
<t>Egress SR Node: The Egress SR Node is the last node in the segment <t>Egress SR Node: The Egress SR Node is the last node in the
list of the SRH. The processing segment list of the SRH. The processing of AltMark TLV at the Egress
of AltMark TLV at the Egress SR Node is the same as the processing of SR Node is the same as the processing of AltMark TLV at the
AltMark TLV at the Intermediate SR Nodes.</t> Intermediate SR Nodes.</t>
</list> </li>
</t> </ul>
<t>The use of the AltMark TLV may be combined with the network
<t>The use of the AltMark TLV may be combined with the network programmin programming capability of SRv6 <xref target="RFC8986"
g capability of SRv6 (<xref target="RFC8986"/>). format="default"/>. Specifically, the ability for an SRv6 endpoint to
Specifically, the ability for an SRv6 endpoint to determine whether to pr determine whether to process or ignore some specific SRH TLVs (such as
ocess or ignore some specific SRH TLVs (such as the the AltMark TLV) may be based on the SID function associated with the
AltMark TLV) may be based on the SID function associated with the SID adv SID advertised by an Intermediate or Egress SR Node and used in the
ertised by an Intermediate or Egress SR Node and Destination Address field of the SRv6 packet. When a packet is addressed
used in the Destination Address field of the SRv6 packet. When a packet i to a SID that does not support the Alternate-Marking functionality, the
s addressed to a SID which does not support the receiving node does not have to look for or process the SRH AltMark TLV
Alternate Marking functionality, the receiving node does not have to look and can simply ignore it. This also enables collection of Alternate-Markin
for or process the SRH AltMark TLV and can simply g data only from the supporting segment endpoints.</t>
ignore it. This also enables collection of Alternate Marking data only fr <section anchor="compatibility" numbered="true" toc="default">
om the supporting segment endpoints.</t> <name>Compatibility</name>
<t>As highlighted in <xref target="observations" format="default"/>,
<section anchor="compatibility" title="Compatibility"> the use of the Destination Option to carry the AltMark data preceding
the SRH is equivalent to the SRH AltMark TLV. Therefore, it is
<t>As highlighted in <xref target="observations"/>, the use of the Destina important to analyze what happens when both the SRH AltMark TLV and
tion Option to carry the AltMark data preceding the SRH the Destination Option are present, and how that would impact
is equivalent to the SRH AltMark TLV. Therefore, it is important to ana processing and complexity.</t>
lyze what happens when both the SRH AltMArk TLV and <t>It is worth mentioning that the SRH AltMark TLV and the
the Destination Option are present, and how that would impact processin Destination Option carrying AltMark data can coexist without problems.
g and complexity.</t> If both are present, the only issue could be the duplication of
information, but this will not affect in any way the device and the
<t>It is worth mentioning that the SRH AltMark TLV and the the Destinat network services. Both this document and <xref target="RFC9343"/> re
ion Option carrying AltMark data can coexist without problems. quire a controlled domain for
If both are present, the only issue could be the duplication of informa security purposes, which confines this duplication to a
tion but this will not affect in any way the device and the network services. single service provider network. Duplication of the same
The security requirement of controlled domain applies to both this docu information in different places should be avoided, and analyzing
ment and <xref target="RFC9343"/>, and it also confines this duplication the use of only the SRH AltMark TLV is recommended as part of
to a single service provider networks. this experiment.</t>
However, duplication of the same information in different places should </section>
be avoided and it is recommended to only analyze the use of SRH AltMark TLV
for the experimentation.</t>
</section>
</section> </section>
<section anchor="experimentation" numbered="true" toc="default">
<section anchor="experimentation" title="Experimentation Overview"> <name>Experimentation Overview</name>
<t>The protocol extension described in this document is built on existing
<t>The protocol extension, described in this document, is built on exis technology using an Experimental code point.
ting technology using an Experimental code point. Experiment participants must use a code point chosen from the Experimental ra
Experimentation of this document must use a code point chosen from the nge, as noted in <xref target="AltMarkTLV" format="default"/>,
Experimental range, as noted in <xref target="AltMarkTLV"/>,
and should make it possible for the operator to configure the value use d in a deployment such that it is possible to conduct and should make it possible for the operator to configure the value use d in a deployment such that it is possible to conduct
multiple non-conflicting experiments within the same network.</t> multiple non-conflicting experiments within the same network.</t>
<t>This experiment aims to determine whether or not the use of the SRH Alt
<t>This experiment aims to determine whether or not the use of the SRH Mark TLV brings advantages,
AltMark TLV brings advantages, in particular, in consideration of implementations that cannot support
in particular in consideration of implementations that cannot support m multiple IPv6 extension headers in the same packet,
ultiple IPv6 extension headers in the same packet,
or which do not support Destination Options Header processing, or which process the Destination Options Header on the slow path.</t> or which do not support Destination Options Header processing, or which process the Destination Options Header on the slow path.</t>
<t>This experiment also needs to determine whether the proposed protocol
extensions achieve the desired function and can be supported in the
presence of normal SRv6 processing. In particular, the experiment needs
to verify the ability to support SR network programming, SID function
control, and the support or non-support of the AltMark TLV.</t>
<t>It is anticipated that this experiment will be contained within a
single service provider network in keeping with the constraints of an SR
domain, and also in keeping with the limits in sharing performance
monitoring data collected on the path of packets in the network. The
scope of the experimental deployment may depend on the availability of
implementations and the willingness of operators to deploy it on live
networks.</t>
<t>This experiment also needs to determine whether the proposed protoco <t>The results of this experiment will be collected and shared with the
l extensions achieve the desired function and Independent Submissions Editor or with the IETF SPRING Working Group
can be supported in the presence of normal SRv6 processing. In particul as Internet-Drafts to help progress the
ar, the experiment needs to verify the ability to support discussions that will determine the correct development of Alternate-Marking
SR network programming, SID function control and the support or non-sup Method solutions in SRv6 networks. It is expected that initial results
port of the AltMark TLV.</t> will be made available within two years of the publication of this
document as an RFC.</t>
<t>It is anticipated that this experiment will be contained within a si <section anchor="objective" numbered="true" toc="default">
ngle service provider network in keeping with <name>Objective of the Experiment</name>
the constraints of an SR Domain, and also in keeping with the limits in <t>Researchers are invited to evaluate the SRH AltMark TLV against the
sharing performance monitoring data collected existing approach in <xref target="RFC9343" format="default"/>. There
on the path of packets in the network. The scope of the experimental de are several potential areas of exploration for this experimentation
ployment may depend on the availability of implementations and that need to be analyzed:</t>
the willingness of operators to deploy it on live networks.</t> <ul spacing="normal">
<li>
<t>The results of this experiment will be collected and shared with the <t>Does the use of the SRH AltMark TLV survive across a network
RFC Editor for consideration as independent submission better or worse than the use of an extension header?</t>
or with the IETF SPRING working group as Internet-Draft, to help forwar </li>
d the discussions that will determine the correct development <li>
of Alternate Marking Method solutions in SRv6 networks. <t>Does the SRH TLV processing represent a performance improvement o
It is expected that a first set of results will be made available withi r hindrance on the device as compared to the Destination Option?</t>
n two years of the publication of this document as an RFC.</t> </li>
<li>
<section anchor="objective" title="Objective of the Experiment"> <t>Is the forwarding plane performance impacted across different
device architecture types when comparing the use of the SRH TLV
<t>Researchers are invited to evaluate the SRH AltMark TLV again with the use of Destination Option?</t>
st the existing approach in <xref target="RFC9343"/>. </li>
There are several potential areas of exploration for this experi <li>
mentation that need to be analyzed:<list> <t>How does use of the extended data fields, introduced in <xref
target="extended" format="default"/>, compare to other on-path
<t>Does the use of the SRH AltMark TLV survive across a network telemetry methods from the point of view of the operators?</t>
better or worse than the extension headers usage?</t> </li>
</ul>
<t>Does the SRH TLV processing represent a performance improvement or </section>
hindrance on the device compared to the Destination Option?</t>
<t>Is the forwarding plane performance impacted across different de
vice architecture types comparing the use of SRH TLV and Destination Option?</t>
<t>How does the use of the extended data fields, introduced in <xre
f target="extended"/>, compare to other on path telemetry methods
from the point of view of the operators?</t>
</list></t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations of SRv6 are discussed in <xref target="RFC8
<t>The security considerations of SRv6 are discussed in <xref target="RF 754" format="default"/> and <xref target="RFC8986" format="default"/>,
C8754"/> and <xref target="RFC8986"/>,
and the security considerations of Alternate Marking in general and its application to IPv6 and the security considerations of Alternate Marking in general and its application to IPv6
are discussed in <xref target="RFC9341"/> and <xref target="RFC9343"/>.< are discussed in <xref target="RFC9341" format="default"/> and <xref tar
/t> get="RFC9343" format="default"/>.</t>
<t><xref target="RFC9343" format="default"/> analyzes different security c
<t><xref target="RFC9343"/> analyzes different security concerns and rel oncerns and related solutions. These aspects are valid and applicable also
ated solutions. These aspects are valid and applicable also to this document. In particular, the fundamental security requirement is
to this document. In particular the fundamental security requirement is that Alternate Marking
that Alternate Marking <bcp14>MUST</bcp14> only be applied in a limited domain, as also mention
MUST only be applied in a limited domain, as also mentioned in <xref tar ed in <xref target="RFC8799" format="default"/> and <xref target="control" forma
get="RFC8799"/> and <xref target="control"/>.</t> t="default"/>.</t>
<t>Alternate Marking is a feature applied to a trusted domain, where a
<t>Alternate Marking is a feature applied to a trusted domain, where a s single operator decides on leveraging and configuring Alternate Marking
ingle operator decides on according to their needs. Additionally, operators need to properly
leveraging and configuring Alternate Marking according to their n secure the Alternate-Marking domain to avoid malicious configuration and
eeds. Additionally, operators need attacks, which could include injecting malicious packets into a
to properly secure the Alternate Marking domain to avoid malicious confi domain. Therefore, the implementation of Alternate Marking is applied with
guration and attacks, which in a
could include injecting malicious packets into a domain. So the implemen controlled domain where the network nodes are locally administered and
tation of Alternate Marking where packets containing the AltMark TLV are prevented from entering or
is applied within a controlled domain where the network nodes are locall leaving the domain. A limited administrative domain provides the network
y administered and where packets administrator with the means to select, monitor, and control the access
containing the AltMark TLV are prevented from entering or leaving the do to the network.</t>
main. A limited administrative </section>
domain provides the network administrator with the means to select, moni <section anchor="IANA" numbered="true" toc="default">
tor and control the access <name>IANA Considerations</name>
to the network.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> </middle>
<back>
<t>This document makes no requests for IANA actions.</t> <displayreference target="I-D.bonica-gendispatch-exp" to="IETF-EXPERIMENTS"/
>
<displayreference target="I-D.ietf-ippm-on-path-telemetry-yang" to="YANG-TEL
EMETRY"/>
<displayreference target="I-D.ietf-opsawg-ipfix-on-path-telemetry" to="IPFIX
"/>
<displayreference target="I-D.ietf-6man-eh-limits" to="EH-LIMITS"/>
</section> <references>
<name>References</name>
<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"/>
<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.9
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
343.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
00.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.8
799.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.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.9
098.xml"/>
<!-- [I-D.ietf-6man-eh-limits]
draft-ietf-6man-eh-limits-19
IESG State: IESG Evaluation::Revised I-D Needed as of 10/07/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-6man-eh-limits.xml"/>
<!-- [I-D.ietf-opsawg-ipfix-on-path-telemetry]
draft-ietf-opsawg-ipfix-on-path-telemetry-23
IESG State: RFC Ed Queue (AUTH) as of 10/07/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-opsawg-ipfix-on-path-telemetry.xml"/>
<section anchor="Acknowledgements" title="Acknowledgements"> <!-- [I-D.ietf-ippm-on-path-telemetry-yang]
draft-ietf-ippm-on-path-telemetry-yang-01
IESG State: I-D Exists as of 10/07/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-ippm-on-path-telemetry-yang.xml"/>
<t>The authors would like to thank Eliot Lear, Adrian Farrel, Joel M. Ha <!-- [I-D.bonica-gendispatch-exp]
lpern and Haoyu Song draft-bonica-gendispatch-exp-06
for the precious comments and suggestions.</t> IESG State: I-D Exists as of 10/07/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
bonica-gendispatch-exp.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Eliot Lear"/>,
<contact fullname="Adrian Farrel"/>, <contact fullname="Joel
M. Halpern"/>, and <contact fullname="Haoyu Song"/> for the precious
comments and suggestions.</t>
</section> </section>
<section title="Contributors"> <section numbered="false" toc="default">
<name>Contributors</name>
<t>The following people provided relevant contributions to this document:< /t> <t>The following people provided relevant contributions to this document:< /t>
<t><figure> <contact fullname="Fabio Bulgarella">
<artwork><![CDATA[ <organization>Telecom Italia</organization>
Fabio Bulgarella <address>
Telecom Italia <email>fabio.bulgarella@guest.telecomitalia.it</email>
Email: fabio.bulgarella@guest.telecomitalia.it </address>
</contact>
Massimo Nilo
Telecom Italia
Email: massimo.nilo@telecomitalia.it
Fabrizio Milan <contact fullname="Massimo Nilo">
Telecom Italia <organization>FiberCop</organization>
Email: fabrizio.milan@telecomitalia.it <address>
<email>massimo.nilo@fibercop.com</email>
</address>
</contact>
]]></artwork> <contact fullname="Fabrizio Milan">
</figure></t> <organization>FiberCop</organization>
<address>
<email>fabrizio.milan@fibercop.com</email>
</address>
</contact>
</section> </section>
</back>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.8402'?>
<?rfc include='reference.RFC.9341'?>
<?rfc include='reference.RFC.9342'?>
<?rfc include='reference.RFC.9343'?>
</references>
<references title="Informative References">
<!-- A reference written by by an organization not a persoN. -->
<?rfc include='reference.RFC.8200'?>
<?rfc include='reference.RFC.8754'?>
<?rfc include='reference.RFC.8799'?>
<?rfc include='reference.RFC.8986'?>
<?rfc include='reference.RFC.9256'?>
<?rfc include='reference.RFC.9098'?>
<?rfc include='reference.I-D.ietf-6man-eh-limits'?>
<?rfc include='reference.I-D.ietf-opsawg-ipfix-on-path-telemetry'?>
<?rfc include='reference.I-D.ietf-ippm-on-path-telemetry-yang'?>
<?rfc include='reference.I-D.bonica-gendispatch-exp'?>
</references>
</back>
</rfc> </rfc>
 End of changes. 78 change blocks. 
846 lines changed or deleted 659 lines changed or added

This html diff was produced by rfcdiff 1.48.