Skip to main content

1. Introduction

This section preserves the RFC text for the SRH AltMark TLV experiment, including Alternate-Marking Method, SRv6, SRH, FlowMonID, L and D flags, NH, enhanced fields, controlled-domain requirements, security, and IANA considerations.

Original RFC Text​

1.  Introduction

   [RFC9341] and [RFC9342] 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.  [RFC9343] 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 [RFC8402].

   This document describes an alternative experimental approach that
   encodes the marking field in a new TLV carried in the Segment Routing
   Header (SRH) [RFC8754] 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
   [RFC9098] and [EH-LIMITS].  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 [RFC9343]; 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 [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.

1.1.  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 [RFC8200], 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 [RFC8754], 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 [RFC9343] and the approach specified in this document can
   coexist.  Indeed, this document does not change or invalidate any
   procedures defined in [RFC9343].  However, deployment issues may
   arise, as further discussed below.

   The rest of this document is structured as follows:

   *  Section 2 covers the application of the Alternate-Marking Method
      to SRv6,

   *  Section 3 specifies the AltMark SRH TLV to carry the base data
      fields (Section 3.1) and the extended data fields (Section 3.2),

   *  Section 4 discusses the use of the AltMark TLV, and

   *  Section 5 describes the experiment and the objectives of the
      experimentation (Section 5.1).

1.2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
Last updated on