Application of the Alternate-Marking Method to the Segment Routing Header

Application of the Alternate-Marking Method to the Segment Routing Header Huawei

Viale Martesana, 12 Vimodrone (Milan) 20055 Italy giuseppe.fioccola@huawei.com

Huawei

156 Beiqing Rd. Beijing 100095 China zhoutianran@huawei.com

Verizon Inc.

gyan.s.mishra@verizon.com

Ruijie

wangxuewei1@ruijie.com.cn

China Mobile

zhanggeng@chinamobile.com

mauro.cociglio@outlook.com

SRH TLV Extension Header Option Performance Measurement Monitoring Passive Hybrid Loss Delay Delay Variation Multipoint Cluster Closed-Loop This document describes an alternative experimental approach for the application 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 coordinating parties in a controlled domain. This approach has potential scaling and simplification benefits over the technique described in RFC 9343, and the scope of the experiment is to determine whether those are significant and attractive to the community. 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 implementations to better determine the value of this approach. 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.

Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

. Introduction
- . Observations on RFC 9343
- . Requirements Language
. Application of the Alternate-Marking Method to SRv6
- . Controlled Domain
. Definition of the SRH AltMark TLV
- . Base Alternate-Marking Data Fields
- . Optional Extended Data Fields for Enhanced Alternate Marking
. Use of the SRH AltMark TLV
- . Compatibility
. Experimentation Overview
- . Objective of the Experiment
. Security Considerations
. IANA Considerations
. References
- . Normative References
- . Informative References
Acknowledgements
Contributors
Authors' Addresses

Introduction and describe a passive performance measurement method, which can be used to measure packet loss, latency, and jitter on live traffic. Since this method is based on marking consecutive batches of packets, the method is often referred as the "Alternate-Marking Method". The Alternate-Marking Method requires a marking field so that packet flows can be distinguished and identified. 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. This mechanism is equally applicable to Segment Routing for IPv6 (SRv6) networks . This document describes an alternative experimental approach that encodes the marking field in a new TLV carried in the Segment Routing Header (SRH) of an SRv6 packet. This approach is applicable only to SRv6 deployments. It is intended to capitalize on the assumption that Segment Routing (SR) nodes are supposed to support fast parsing and processing of the SRH, while the SR nodes may not properly handle Destination Options, as discussed in and . The experiment is to determine whether or not there are significant and attractive advantages to the community: if there are, the work may be brought back for IETF consideration. This protocol extension has been developed outside the IETF as an alternative to the IETF's Standards Track specification ; it does not have IETF consensus. It is published here to guide experimental implementation and ensure interoperability among implementations to better determine the value of this approach. As also highlighted in , 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 for more details about the experiment.

Observations on RFC 9343 Like any other IPv6 use case, Hop-by-Hop and Destination Options can also be used when the SRH is present. As specified in , 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 Destination Options Header is used to carry optional information that needs to be examined only by the packet's destination node(s). 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 , 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. The distinction between the alternatives is most notable for SRv6 packets that traverse a network where the paths between sequential segment endpoints include multiple hops. If the Hop-by-Hop Option is used, then every hop along the 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 endpoints will process the AltMark data, unless the intermediate node has a different priority rule. Both and the approach specified in this document can coexist. Indeed, this document does not change or invalidate any procedures defined in . However, deployment issues may arise, as further discussed below. The rest of this document is structured as follows:

covers the application of the Alternate-Marking Method to SRv6,
specifies the AltMark SRH TLV to carry the base data fields () and the extended data fields (),
discusses the use of the AltMark TLV, and
describes the experiment and the objectives of the experimentation ().

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Application of the Alternate-Marking Method to SRv6 SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata for segment processing, as described in . This document defines the SRH AltMark TLV to carry Alternate-Marking data fields for use in SRv6 networks, and it is an alternative to the method described in . 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 is the basis of the AltMark SRH TLV introduced in . In addition to the base data fields of , the insertion of optional extended data fields that are not present in is also allowed. These extended data fields can support metadata for additional telemetry requirements, as further described below.

Controlled Domain introduces the concept of specific limited domain solutions and notes the application of the Alternate-Marking Method as an example. Despite the flexibility of IPv6, when innovative applications are proposed, they are often applied within controlled domains to help constrain the domain-wide policies, options supported, the style of network management, and security requirements. This is also the case for applying the Alternate-Marking Method to SRv6. Therefore, the experiment of applying the Alternate-Marking Method to SRv6 MUST only be deployed within a controlled domain. For SRv6, the controlled domain corresponds to an SR domain, as defined in . The Alternate-Marking measurement domain overlaps with the controlled domain. 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.

Definition of the SRH AltMark TLV 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 extension fields that are present when Enhanced Alternate Marking is in use. shows the format of the AltMark TLV.

The AltMark SRH TLV for Alternate Marking 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRH TLV Type | SRH TLV Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowMonID |L|D| Reserved | NH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional extended data fields (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this TLV are as follows:

SRH TLV Type:

The 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 not change en route. Deployment of this document must 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.

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.

Reserved:

Reserved for future use. These bits MUST be set to zero on transmission and ignored on receipt.

FlowMonID:

The Flow Monitoring Identification field. It is a 20-bit unsigned integer as defined in .

L:

The Loss flag, as defined in .

D:

The Delay flag, as defined in .

NH:

The NextHeader field. It is used to indicate extended data fields are present to support Enhanced Alternate Marking as follows:

NextHeader value of 0x0 means that there is no extended data field attached.
NextHeader values of 0x1-0x8 are reserved for further usage.
NextHeader value of 0x9 indicates the extended data fields are present as described in .
NextHeader values of 0xA-0xF are reserved for further usage.

Optional extended data fields may be present according to the setting of the NH field and as described in .

Base Alternate-Marking Data Fields The base AltMark data fields are: the Loss (L) flag, the Delay (D) flag, and the Flow Monitoring Identification (FlowMonID) field, as in . 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 , the FlowMonID is used to identify the monitored flow because it is not possible to utilize the Flow Label field of the IPv6 Header. It is important to note that if the 20-bit FlowMonID is set by the domain entry nodes, there is a chance of collision even when the values are chosen using a pseudorandom 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 can be carried in the extended data fields described in .

Optional Extended Data Fields for Enhanced Alternate Marking The optional extended data fields to support Enhanced Alternate Marking are illustrated in . They are present when the NH field of the AltMark TLV is set to 0x9.

Optional Extended Data Fields for Enhanced Alternate Marking 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowMonID Ext |M|F|W|R| Len | Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MetaInfo | Optional MetaData ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional MetaData (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The extended data fields are as follows:

FlowMonID Ext:

20-bit unsigned integer used to extend the FlowMonID in order to reduce the conflict when random allocation is applied. The disambiguation of the FlowMonID field is discussed in "IPv6 Application of the Alternate-Marking Method" .

Four different bit flags indicate special-purpose usage.

M bit:: 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.
F bit:: 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.
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 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.
R bit:: Reserved. This bit MUST be set to zero and ignored on receipt.

Len:

Length. Indicates the length of the extended data fields for Enhanced Alternate Marking as a multiple of 4 bytes. It includes all of the fields shown in including any metadata that is present.

Rsvd:

Reserved for further use. These bits MUST be set to zero on transmission and ignored on receipt.

MetaInfo:

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:

bit 0:

If set to 1, it indicates that a 6-byte Timestamp is present as shown in .

The Timestamp Extended Data Field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp(ns) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Timestamp can be filled by the encapsulation node and is taken all the way to the decapsulation node so that all the intermediate nodes can compare it against their local time and measure the one-way delay. The Timestamp consists of two fields:

Timestamp(s):: A 16-bit integer that carries the number of seconds.
Timestamp(ns):: A 32-bit integer that carries the number of nanoseconds.

Note that the Timestamp data field enables all the intermediate nodes to measure the one-way delay. It can be correlated with the implementation of and . introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay. Similarly, defines a YANG data model for monitoring On-Path Telemetry data, including the path delay.

bit 1:

If set to 1, it indicates the control information to set up the backward direction flow monitoring based on the trigger packet presence as shown in .

Control Information for Backward Direction Flow Monitoring 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DIP Mask | SIP Mask |P|I|O|V|S|T| Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The control information includes several fields and flags to match in order to set up the backward direction:

DIP Mask:: The length of the destination IP prefix used to match the flow.
SIP Mask:: The length of the source IP prefix used to match the flow.
P bit:: If set to 1, it indicates to match the flow using the protocol identifier in the trigger packet.
I bit:: If set to 1, it indicates to match the source port.
O bit:: If set to 1, it indicates to match the destination port.
V bit:: If set to 1, the node will automatically set up reverse direction monitoring and allocate a FlowMonID.
S bit:: If set to 1, it indicates to match the Differentiated Services Code Point (DSCP).
T bit:: Used to control the scope of tunnel measurement. T=1 means measure between Network-to-Network Interfaces (i.e., NNI to NNI). T=0 means measure between User-to-Network Interfaces (i.e., UNI to UNI).
Period:: Indicates the Alternate-Marking period counted in seconds.

bit 2:

If set to 1, it indicates that a 4-byte Sequence Number is present as shown in .

Sequence Number Data Field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The unique Sequence Number can be used to detect the out-of-order packets, in addition to enabling packet loss measurement. Moreover, the Sequence Number can be used together with the latency measurement to access per-packet Timestamps.

Use of the SRH AltMark TLV Since the measurement domain is congruent with the SR-controlled domain, the procedure for AltMark data encapsulation in the SRv6 SRH is summarized as follows:

Ingress SR Node: As part of the SRH encapsulation, the Ingress SR Node of an SR domain or an SR Policy that supports the mechanisms defined in this document and that wishes to perform the Alternate-Marking Method adds the AltMark TLV in the SRH of the data packets.
Intermediate SR Node: The Intermediate SR Node is any node receiving an IPv6 packet where the destination address of that packet is a local Segment Identifier (SID). If an Intermediate SR Node is not capable of processing the AltMark TLV, it simply ignores it according to the processing rules of . If an Intermediate SR Node is capable of processing the AltMark TLV, it checks if the SRH AltMark TLV is present in the packet and processes it.
Egress SR Node: The Egress SR Node is the last node in the segment list of the SRH. The processing of AltMark TLV at the Egress SR Node is the same as the processing of AltMark TLV at the Intermediate SR Nodes.

The use of the AltMark TLV may be combined with the network programming capability of SRv6 . Specifically, the ability for an SRv6 endpoint to determine whether to process or ignore some specific SRH TLVs (such as the AltMark TLV) may be based on the SID function associated with the SID advertised by an Intermediate or Egress SR Node and used in the Destination Address field of the SRv6 packet. When a packet is addressed to a SID that does not support the Alternate-Marking functionality, the receiving node does not have to look for or process the SRH AltMark TLV and can simply ignore it. This also enables collection of Alternate-Marking data only from the supporting segment endpoints.

Compatibility As highlighted in , 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. 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. Both this document and 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.

Experimentation Overview The protocol extension described in this document is built on existing technology using an Experimental code point. Experiment participants must use a code point chosen from the Experimental range, as noted in , 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. This experiment aims to determine whether or not the use of the SRH AltMark TLV brings advantages, in particular, in consideration of implementations that cannot support multiple 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. 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. 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. 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. It is expected that initial results will be made available within two years of the publication of this document as an RFC.

Objective of the Experiment Researchers are invited to evaluate the SRH AltMark TLV against the existing approach in . There are several potential areas of exploration for this experimentation that need to be analyzed:

Does the use of the SRH AltMark TLV survive across a network better or worse than the use of an extension header?
Does the SRH TLV processing represent a performance improvement or hindrance on the device as compared to the Destination Option?
Is the forwarding plane performance impacted across different device architecture types when comparing the use of the SRH TLV with the use of Destination Option?
How does use of the extended data fields, introduced in , compare to other on-path telemetry methods from the point of view of the operators?

Security Considerations The security considerations of SRv6 are discussed in and , and the security considerations of Alternate Marking in general and its application to IPv6 are discussed in and . analyzes different security concerns and related solutions. These aspects are valid and applicable also to this document. In particular, the fundamental security requirement is that Alternate Marking MUST only be applied in a limited domain, as also mentioned in and . Alternate Marking is a feature applied to a trusted domain, where a single operator decides on leveraging and configuring Alternate Marking according to their needs. Additionally, operators need to properly secure the Alternate-Marking domain to avoid malicious configuration and attacks, which could include injecting malicious packets into a domain. Therefore, the implementation of Alternate Marking is applied within a controlled domain where the network nodes are locally administered and where packets containing the AltMark TLV are prevented from entering or leaving the domain. A limited administrative domain provides the network administrator with the means to select, monitor, and control the access to the network.

IANA Considerations This document has no IANA actions.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Alternate-Marking Method This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. Clustered Alternate-Marking Method This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC 8889. IPv6 Application of the Alternate-Marking Method This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header. Informative References Limits on Sending and Processing IPv6 Extension Headers This document defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. Limits are pragmatic to facilitate interoperability amongst hosts and routers, thereby increasing the deployability of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. Work in Progress IETF Experiments Hewlett Packard Enterprise Old Dog Consulting This document describes IETF protocol experiments and provides guidelines for the publication of Experimental RFCs. Work in Progress Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) Swisscom Huawei INSA-Lyon This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path delay at each OAM transit and decapsulating nodes. The On-Path delay is defined as the delay between the OAM header encapsulating node and each OAM header transit and OAM header decapsulating nodes. This delay measurement is computed by an On-Path Telemetry protocol and is exported by the IPFIX process. Work in Progress Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. IPv6 Segment Routing Header (SRH) Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Limited Domains and Internet Protocols There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Operational Implications of IPv6 Packets with Extension Headers This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. Segment Routing Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. On-Path Telemetry YANG Data Model Huawei Huawei China Telecom China Telecom Huawei Technologies This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. Work in Progress

Acknowledgements The authors would like to thank , , , and for the precious comments and suggestions.

Contributors The following people provided relevant contributions to this document: Telecom Italia

fabio.bulgarella@guest.telecomitalia.it

FiberCop

massimo.nilo@fibercop.com