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="February"/>
<date year="2025"/> <!-- month="March" is no longer necessary <!-- [rfced] Please insert any keywords (beyond those that appear in
note also, day="30" is optional --> the title) for use on https://www.rfc-editor.org/search. -->
<!-- WARNING: If the month and year are the current ones, xml2rfc will fill
in the day for
you. If only the year is specified, xml2rfc will fill in the current da
y and month
irrespective of the day. This silliness should be fixed in v1.31. -->
<!-- Meta-data Declarations --> <keyword>example</keyword>
<!-- Notice the use of &amp; as an escape for & which would otherwise <abstract>
start an entity declaration, whereas we want a literal &. --> <t>This document describes an alternative experimental approach for the ap
plication of
the Alternate-Marking Method to Segment Routing for IPv6 (SRv6).
It uses an experimental TLV in the Segment Routing Header (SRH);
thus, participation in this experiment should be between coordina
ting parties in a controlled domain.
This approach has potential scaling and simplification benefits o
ver the technique
described in RFC 9343, and the scope of the experiment is to dete
rmine whether
those are significant and attractive to the community.</t>
<t>This protocol extension has been developed outside the IETF as an
alternative to the IETF's Standards Track specification RFC 9343
and
it does not have IETF consensus. It is published here to guide
experimental implementation and ensure interoperability among imp
lementations
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>
<area></area> <!-- [rfced] Please consider the following with regard to the text below.
<!-- WG name at the upperleft corner of the doc, A) How may we update the instances below to clarify the RFC Editor's role in the
IETF fine for individual submissions. You can also submission process? We believe the text should refer to the Independent Submis
omit this element in which case in defaults to "Network Working Group" sions Editor instead.
-
a hangover from the ancient history of the IETF! -->
<workgroup></workgroup> B) Is the goal to describe the results in an Internet-Draft for discussion or fo r consideration for publication as an RFC, or both? Note that Independent Submi ssions also get posted as Internet-Drafts.
<!-- The DTD allows multiple area and workgroup elements but only the first C) May we update "to help forward" to "to help progress" or perhaps "to evolve"?
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> Original:
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>This document describes an alternative experimental approach for the ...
application of
the Alternate-Marking Method to SRv6. It uses an experimental TLV
in the Segment Routing Header,
and thus participation in this experiment should be between coord
inating parties in a controlled domain.
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
those are significant and attractive to the community.</t>
<t>This protocol extension has been developed outside the IETF as an The results of this experiment will be collected and shared with the
alternative to the IETF&apos;s standards track specification RFC RFC Editor for consideration as independent submission or with the
9343 and IETF SPRING working group as Internet-Draft, to help forward the
it does not have IETF consensus. It is published here to guide discussions that will determine the correct development of Alternate
experimental implementation, ensure interoperability among implem Marking Method solutions in SRv6 networks.
entations
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> Perhaps:
Researchers are invited to submit their evaluations of this work to
the Independent Submissions Editor or to the IETF SPRING Working Group
as Internet-Drafts.
</front> ...
<middle> The results of this experiment will be collected and shared with the
Independent Submissions Editor or with the IETF SPRING Working Group
as Internet-Drafts to help progress the
discussions that will determine the correct development of Alternate-
Marking Method solutions in SRv6 networks.
-->
<section title="Introduction"> </front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<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>
<!-- [rfced] We are having trouble parsing "the mechanism to carry." Does the m
echanism carry the headers? Perhaps this refers to the ability to carry Alterna
te-Marking data? Please clarify.
<t>The Alternate Marking Method requires a marking field so that packet f Original (sentence prior provided for context):
lows [RFC9343] defines the
can be distinguished and identified. <xref target="RFC9343"/> defines the standard for how the marking field can be encoded in a new TLV in
standard for how either Hop-by-hop or Destination Options Headers of IPv6 packets in
the marking field can be encoded in a new TLV in either Hop-by-hop or order to achieve Alternate Marking. The mechanism to carry is
Destination Options Headers equally applicable to Segment Routing for IPv6 (SRv6) networks
of IPv6 packets in order to achieve Alternate Marking. The mechanism t [RFC8402].
o carry is equally -->
applicable to Segment Routing for IPv6 (SRv6) networks <xref target="R
FC8402"/>.</t>
<t>This document describes an alternative experimental approach that e <t>The Alternate-Marking Method requires a marking field so that packet fl
ncodes the ows
marking field in a new TLV carried in the Segment Routing Header (SRH) can be distinguished and identified. <xref target="RFC9343" format="defau
<xref target="RFC8754"/> lt"/> defines the standard for how
the marking field can be encoded in a new TLV in either Hop-by-Hop or
Destination Options Headers
of IPv6 packets in order to achieve Alternate Marking. The mechanism t
o carry is equally
applicable to Segment Routing for IPv6 (SRv6) networks <xref target="R
FC8402" format="default"/>.</t>
<t>This document describes an alternative experimental approach that encod
es the
marking field in a new TLV carried in the Segment Routing Header (SRH)
<xref target="RFC8754" format="default"/>
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>
<!-- [rfced] For clarity, please consider the following update to indicate the p urpose of the experiment.
<t>This protocol extension has been developed outside the IETF as an Original:
alternative to the IETF&apos;s standards track specification <xref tar As
get="RFC9343"/> and also highlighted in [I-D.bonica-gendispatch-exp], when two protocol
it does not have IETF consensus. It is published here to guide experim extensions are proposed to solve a single problem, an experiment can
ental implementation, be initiated and this is the purpose of this document. See Section 5
ensure interoperability among implementations to better determine the for more details about the experimentation.
value of this approach.
As also highlighted in <xref target="I-D.bonica-gendispatch-exp"/>, wh
en two protocol extensions
are proposed to solve a single problem, an experiment can be initiated
and this is the purpose
of this document. See <xref target="experimentation"/> for more detail
s about the experimentation.</t>
<section anchor="observations" title="Observations on RFC 9343"> Perhaps:
As
also highlighted in [IETF-EXPERIMENTS], when two protocol
extensions are proposed to solve a single problem, an experiment can
be initiated to gather operational experience and "determine which,
if either, of the protocols should be progressed to the standards track."
This is the purpose of this document. See Section 5
for more details about the experiment.
-->
<t>This protocol extension has been developed outside the IETF as an
alternative to the IETF's Standards Track specification <xref target="
RFC9343" format="default"/>;
it does not have IETF consensus. It is published here to guide experim
ental implementation and
ensure interoperability among implementations to better determine the
value of this approach.
As also highlighted in <xref target="I-D.bonica-gendispatch-exp" forma
t="default"/>, when two protocol extensions
are proposed to solve a single problem, an experiment can be initiated
, and this is the purpose
of this document. See <xref target="experimentation" format="default"/
> for more details about the experimentation.</t>
<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.</t>
pdated according to the segment list. <t>Both <xref target="RFC9343" format="default"/> and the approach
The SRH TLV provides metadata for segment processing, while processin specified in this document can coexist. Indeed, this document does
g the SID, if the node is locally configured to do so. not change or invalidate any procedures defined in <xref
Both the Destination Options Header before SRH and the SRH TLV are pr target="RFC9343" format="default"/>. However, deployment issues may
ocessed at the node being indicated in the arise, as further discussed below.</t>
destination address field of the IPv6 header.</t> <t>The rest of this document is structured as follows:</t>
<ul>
<li><xref target="SRv6AltMark" format="default"/> covers the applicatio
n of the
Alternate-Marking Method to SRv6,</li>
<li><xref target="AltMarkTLV" format="default"/> specifies the AltMark SR
H TLV to carry the base
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
k TLV,
and</li>
<li><xref target="experimentation" format="default"/> describes the
experiment and the objectives of the experimentation (<xref
target="objective" format="default"/>).</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<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>
<!-- [rfced] May we adjust "it is also allowed" as follows?
<t>The distinction between the alternatives is most notable for SRv6 pac Original:
kets that traverse a network where the paths In addition to the base data fields of [RFC9343], it is also allowed
between sequential segment end points include multiple hops. If the Hop- the insertion of optional extended data fields which are not present
by-Hop Option is used, then every hop along the in [RFC9343].
path will process the AltMark data. If the Destination Option positioned
before the SRH is used, or the SRH AltMark TLV is
used, then only the segment end points will process the AltMark data.</t
>
<t>Both <xref target="RFC9343"/> and the approach specified in this d Perhaps:
ocument can co-exist. Indeed, this document does not change In addition to the base data fields of [RFC9343], the insertion of optional
or invalidate any procedures defined in <xref target="RFC9343"/>. extended data fields that are not present in [RFC9343] are also allowed.
However, deployment issues may arise, as further discussed below.</t> -->
<t>The rest of this document is structured as follows: <xref targ <section anchor="SRv6AltMark" numbered="true" toc="default">
et="SRv6AltMark"/> covers the application of the Alternate Marking to SRv6, <name>Application of the Alternate-Marking Method to SRv6</name>
<xref target="AltMarkTLV"/> specifies the AltMark SRH TLV to carr <t>SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata
y the base data fields (<xref target="base"/>) and the for segment processing, as described in <xref target="RFC8754"
extended data fields (<xref target="extended"/>), <xref target="U format="default"/>. This document defines the SRH AltMark TLV to carry
se"/> discusses the use of the AltMark TLV, and <xref target="experimentation"/> Alternate-Marking data fields for use in SRv6 networks, and it is an
describes the experiment and the objectives of the experimentatio alternative to the method described in <xref target="RFC9343" format="defa
n (<xref target="objective"/>).</t> ult"/>. <xref
target="RFC9343" format="default"/> defines how the Alternate-Marking
Method can be carried in the Option Headers (Hop-by-Hop or Destination)
of an IPv6 packet. The AltMark data fields format defined in <xref
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"
format="default"/>, it is also allowed the insertion of optional
extended data fields that are not present in <xref target="RFC9343"
format="default"/>. These extended data fields can support metadata for
additional telemetry requirements, as further described below.</t>
<section anchor="control" numbered="true" toc="default">
</section> <name>Controlled Domain</name>
<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,
the style of network management, and security requirements. This is also
the case for applying
the Alternate-Marking Method to SRv6.</t>
<!-- [rfced] For clarity, please consider the following update.
<section title="Requirements Language"> Original:
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT Therefore, the experimentation of the Alternate Marking Method to
", SRv6 MUST be deployed only within a controlled domain.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", an
d
"OPTIONAL" in this document are to be interpreted as described in B
CP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh
en,
they appear in all capitals, as shown here.</t>
</section>
</section> Perhaps:
Therefore, the experiment of applying the Alternate-Marking Method to
SRv6 MUST only be deployed within a controlled domain.
-->
<section anchor="SRv6AltMark" title="Application of the Alternate Marking <t>Therefore, the experimentation of the Alternate-Marking Method to
to SRv6"> SRv6 <bcp14>MUST</bcp14> be deployed only within a controlled
domain. For SRv6, the controlled domain corresponds to an SR domain,
as defined in <xref target="RFC8402" format="default"/>. The
Alternate-Marking measurement domain overlaps with the controlled
domain.</t>
<!-- [rfced] Should "of" be updated to "or" in the text below?
<t>SRv6 leverages the IPv6 SRH, that can embed TLVs to provide metadata fo Original:
r segment processing, as described in <xref target="RFC8754"/>. Carefully bounding the domain reduces the risk of the experiment leaking
This document defines the SRH AltMark TLV to carry Alternate Marking data out and clashing with other experiments of causing unforeseen consequences
fields for use in SRv6 networks and it is an alternative in wider deployments.
to <xref target="RFC9343"/>. <xref target="RFC9343"/> defines how the A
lternate Marking Method can be carried in the Option Headers
(Hop-by-hop or Destination) of an IPv6 packet. The AltMark data fields
format defined in <xref target="RFC9343"/> is the basis of the
AltMark SRH TLV introduced in <xref target="AltMarkTLV"/>.</t>
<t>In addition to the base data fields of <xref target="RFC9343"></xref Perhaps:
>, it is also allowed the insertion of optional extended data fields Carefully bounding the domain reduces the risk of the experiment leaking
which are not present in <xref target="RFC9343"></xref>. These extended out and clashing with other experiments or causing unforeseen consequences
data fields can support metadata for additional telemetry requirements, in wider deployments.
as further described below.</t>
<section anchor="control" title="Controlled Domain"> -->
<t><xref target="RFC8799"/> introduces the concept of specific limited d <!-- [rfced] FYI - We have adjusted the title of Figure 1 to avoid multiple
omain solutions and colons. Please review.
notes application of the Alternate Marking Method as an example.</t>
<t>Despite the flexibility of IPv6, when innovative applications are pro Original:
posed they are often
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 case for the application
of the Alternate Marking Method to SRv6.</t>
<t>Therefore, the experimentation of the Alternate Marking Method to SRv Figure 1: AltMark: SRH TLV for alternate marking
6 MUST be deployed only within
a controlled domain. For SRv6, the controlled domain corresponds to an S
R domain, as defined in <xref target="RFC8402"/>.
The Alternate-Marking measurement domain overlaps with the contro
lled domain.</t>
<t>The use of a controlled domain is also appropriate for the dep Current:
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>
</section> Figure 1: The AltMark SRH TLV for Alternate Marking
<section anchor="AltMarkTLV" title="Definition of the SRH AltMark TLV"> -->
<t>The AltMark SRH TLV is defined to carry the data fields associated wi <t>The use of a controlled domain is also appropriate for the
th the Alternate Marking Method. deployment of an experimental protocol extension. Carefully bounding
The TLV has some initial fields that are always present, and further ext the domain reduces the risk of the experiment leaking out and clashing
ension fields that are with other experiments of causing unforeseen consequences in wider
deployments.</t>
</section>
</section>
<section anchor="AltMarkTLV" numbered="true" toc="default">
<name>Definition of the SRH AltMark TLV</name>
<t>The AltMark SRH TLV is defined to carry the data fields associated with
the Alternate-Marking Method.
The TLV has some initial fields that are always present and further exte
nsion 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 <dl spacing="normal" newline="false">
e present as <!-- [rfced] "Experimentation of this document" is a bit awkward. Perhaps one o
described in <xref target="extended"/>.</t> f the suggested updates below is more clear?
<t>NextHeader values of 0xA-0xF are reserved for further usage.< Original:
/t> Experimentation of this document must coordinate
</list> the value used by all implementations participating in the
</t> experiment.
<t>Optional extended data fields may be present according to the set Perhaps A:
ting of the NH field Participants experimenting with applying the Alternate-Marking Method
and as described in <xref target="extended"/>.</t> to SRH must coordinate the value used.
</list> Perhaps B:
</t> Deployment of this document must coordinate
the value used by all implementations participating in the
experiment.
<section anchor="base" title="Base Alternate Marking Data Fields"> Please consider whether this text may be updated in a similar manner.
<t>The base AltMark data fields are: Loss Flag (L), Delay Original:
Flag (D) and Flow Monitoring Identification field (FlowMonID), Experimentation of this document must use a code point chosen from
as in <xref target="RFC9343"></xref>.</t> the Experimental range, as noted in Section 3, and should make it
possible for the operator to configure the value used in a deployment
such that it is possible to conduct multiple non-conflicting
experiments within the same network.
<t>L and D are the marking fields of the Alternate Markin Perhaps:
g Method while FlowMonID is used to identify monitored flows and aids the Experiment participants must use a code point ...
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 -->
e domain entry nodes, there is a <dt>SRH TLV Type:</dt><dd>The 8-bit identifier of the Alternate-Marking
chance of collision even when the values are chosen using a pseudo-r SRH TLV. The value for this field is taken from the range 124-126. It
andom algorithm; therefore it may be is an Experimental code point that indicates a TLV that does not
not be sufficient to uniquely identify a monitored flow. In such cas change en route. Experimentation of this document must coordinate the
es the packets need to be tagged with additional 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 in bytes for Enhanced Alternate Marking. It includes 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>
<!-- [rfced] For readability, please consider the following update.
<section anchor="compatibility" title="Compatibility">
<t>As highlighted in <xref target="observations"/>, the use of the Destina
tion Option to carry the AltMark data preceding the SRH
is equivalent to the SRH AltMark TLV. Therefore, it is important to ana
lyze what happens when both the SRH AltMArk TLV and
the Destination Option are present, and how that would impact processin
g and complexity.</t>
<t>It is worth mentioning that the SRH AltMark TLV and the the Destinat Original:
ion Option carrying AltMark data can coexist without problems. The security requirement of
If both are present, the only issue could be the duplication of informa controlled domain applies to both this document and [RFC9343], and it
tion but this will not affect in any way the device and the network services. also confines this duplication to a single service provider networks.
The security requirement of controlled domain applies to both this docu However, duplication of the same information in different places
ment and <xref target="RFC9343"/>, and it also confines this duplication should be avoided and it is recommended to only analyze the use of
to a single service provider networks. SRH AltMark TLV for the experimentation.
However, duplication of the same information in different places should
be avoided and it is recommended to only analyze the use of SRH AltMark TLV
for the experimentation.</t>
</section> Perhaps:
Both this document and [RFC9343] require a controlled domain for
security purposes, which confines this duplication to a
single service provider network. Duplication of the same
information in different places should be avoided, and analyzing
the use of only the SRH AltMark TLV is recommended as part of
this experiment.
-->
<t>As highlighted in <xref target="observations" format="default"/>,
the use of the Destination Option to carry the AltMark data preceding
the SRH is equivalent to the SRH AltMark TLV. Therefore, it is
important to analyze what happens when both the SRH AltMark TLV and
the Destination Option are present, and how that would impact
processing and complexity.</t>
<t>It is worth mentioning that the SRH AltMark TLV and the
Destination Option carrying AltMark data can coexist without problems.
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
network services. The security requirement of controlled domain
applies to both this document and <xref target="RFC9343"
format="default"/>, and it also confines this duplication to single
service provider networks. However, duplication of the same
information in different places should be avoided, and it is
recommended to only analyze the use of the 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. Experimentation of this document must use a code point chosen from the
Experimentation of this document must use a code point chosen from the Experimental range, 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 RFC Editor for consideration as an Independent Submission or with the IETF
can be supported in the presence of normal SRv6 processing. In particul SPRING Working Group as an Internet-Draft, to help forward the discussions
ar, the experiment needs to verify the ability to support that will determine the correct development of Alternate-Marking Method
SR network programming, SID function control and the support or non-sup 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">
<!-- [rfced] FYI - We have updated "comparing the use of" to "compared to the
<t>The results of this experiment will be collected and shared with the use of" in the text below. Please review.
RFC Editor for consideration as independent submission
or with the IETF SPRING working group as Internet-Draft, to help forwar
d the discussions that will determine the correct development
of Alternate Marking Method solutions in SRv6 networks.
It is expected that a first set of results will be made available withi
n two years of the publication of this document as an RFC.</t>
<section anchor="objective" title="Objective of the Experiment">
<t>Researchers are invited to evaluate the SRH AltMark TLV again
st the existing approach in <xref target="RFC9343"/>.
There are several potential areas of exploration for this experi
mentation that need to be analyzed:<list>
<t>Does the use of the SRH AltMark TLV survive across a network
better or worse than the extension headers usage?</t>
<t>Does the SRH TLV processing represent a performance improvement or Original:
hindrance on the device compared to the Destination Option?</t> Is the forwarding plane performance impacted across different
device architecture types comparing the use of SRH TLV and
Destination Option?
<t>Is the forwarding plane performance impacted across different de Current:
vice architecture types comparing the use of SRH TLV and Destination Option?</t> * Is the forwarding plane performance impacted across different
device architecture types compared to the use of SRH TLV and
Destination Option?
-->
<t>How does the use of the extended data fields, introduced in <xre <li>
f target="extended"/>, compare to other on path telemetry methods <t>Does the use of the SRH AltMark TLV survive across a network
better or worse than the use of an extension header?</t>
</li>
<li>
<t>Does the SRH TLV processing represent a performance improvement o
r hindrance on the device as compared to the Destination Option?</t>
</li>
<li>
<t>Is the forwarding plane performance impacted across different dev
ice architecture types compared to the use of the SRH TLV and Destination Option
?</t>
</li>
<li>
<t>How does use of the extended data fields, introduced in <xref tar
get="extended" format="default"/>, compare to other on-path telemetry methods
from the point of view of the operators?</t> from the point of view of the operators?</t>
</li>
</list></t> </ul>
</section> </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 <contact fullname="Massimo Nilo">
Telecom Italia <organization>Telecom Italia</organization>
Email: massimo.nilo@telecomitalia.it <address>
<email>massimo.nilo@telecomitalia.it</email>
</address>
</contact>
Fabrizio Milan <contact fullname="Fabrizio Milan">
Telecom Italia <organization>Telecom Italia</organization>
Email: fabrizio.milan@telecomitalia.it <address>
<email>fabrizio.milan@telecomitalia.it</email>
</address>
</contact>
]]></artwork>
</figure></t>
</section> </section>
</middle> </back>
</rfc>
<!-- *****BACK MATTER ***** --> <!-- [rfced] Terminology and Abbreviations:
<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'?> a) For consistency with RFC 9343, we have updated instances of "Alternate Markin g Method" to appear as "Alternate-Marking Method" throughout. We have also hyph enated other instances where "Alternate Marking" is acting as an adjective that precedes the nounn. Please let us know any objections.
<?rfc include='reference.RFC.9256'?> b) We have added "Method" to a few instances of "the Alternate Marking" as seen below. Please let us know if any corrections are needed.
<?rfc include='reference.RFC.9098'?> Original:
Section 2 covers the application of the Alternate Marking to SRv6...
<?rfc include='reference.I-D.ietf-6man-eh-limits'?> Application of the Alternate Marking to SRv6
<?rfc include='reference.I-D.ietf-opsawg-ipfix-on-path-telemetry'?> Current:
Section 2 covers the application of the Alternate Marking Method to SRv6...
<?rfc include='reference.I-D.ietf-ippm-on-path-telemetry-yang'?> Application of the Alternate Marking Method to SRv6
<?rfc include='reference.I-D.bonica-gendispatch-exp'?> c) We have expanded the following abbreviation upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review
and let us know any corrections.
</references> Differentiated Services Code Point (DSCP)
-->
</back> <!-- [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> Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
 End of changes. 128 change blocks. 
802 lines changed or deleted 812 lines changed or added

This html diff was produced by rfcdiff 1.48.