Independent Submission G. Fioccola
Request for Comments: 9947 T. Zhou
Category: Experimental Huawei
ISSN: 2070-1721 G. Mishra
Verizon Inc.
X. Wang
Ruijie
G. Zhang
China Mobile
M. Cociglio
March 2026
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.
この文書では、IPv6 (SRv6) のセグメント ルーティングに代替マーキング方式を適用するための代替の実験的アプローチについて説明します。セグメント ルーティング ヘッダー (SRH) で実験的な TLV を使用します。したがって、この実験への参加は、制御されたドメイン内の調整当事者間で行う必要があります。このアプローチには、RFC 9343 で説明されている手法に比べてスケーリングと簡素化の潜在的な利点があり、実験の範囲は、それらがコミュニティにとって重要で魅力的かどうかを判断することです。
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.
このプロトコル拡張は、IETF の標準トラック仕様 RFC 9343 の代替として IETF の外部で開発されたものであり、IETF のコンセンサスはありません。ここでは、実験的な実装をガイドし、実装間の相互運用性を確保して、このアプローチの価値をより適切に判断するために公開されています。研究者は、この研究の評価を Independent Submissions Editor または IETF SPRING Working Group にインターネット ドラフトとして提出するよう招待されています。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書は Internet Standards Track 仕様ではありません。試験、実験実装、評価のために公開されています。
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.
この文書は、インターネット コミュニティ向けの実験プロトコルを定義します。これは、他の RFC ストリームとは独立した、RFC シリーズへの貢献です。RFC 編集者は独自の裁量でこの文書を公開することを選択しており、実装または展開におけるこの文書の価値については何も述べていません。RFC 編集者によって出版が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9947.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9947 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。
1. Introduction
1.1. Observations on RFC 9343
1.2. Requirements Language
2. Application of the Alternate-Marking Method to SRv6
2.1. Controlled Domain
3. Definition of the SRH AltMark TLV
3.1. Base Alternate-Marking Data Fields
3.2. Optional Extended Data Fields for Enhanced Alternate
Marking
4. Use of the SRH AltMark TLV
4.1. Compatibility
5. Experimentation Overview
5.1. Objective of the Experiment
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
[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".
[RFC9341] および [RFC9342] は、ライブ トラフィック上のパケット損失、レイテンシー、およびジッターの測定に使用できるパッシブ パフォーマンス測定方法について説明しています。この方法は、連続するパケットのバッチをマークすることに基づいているため、この方法は「代替マーキング方法」と呼ばれることがよくあります。
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].
代替マーキング方式では、パケット フローを区別して識別できるようにマーキング フィールドが必要です。[RFC9343] は、代替マーキングを実現するために、IPv6 パケットのホップバイホップまたは宛先オプションヘッダーのいずれかの新しい TLV でマーキングフィールドをエンコードする方法の標準を定義しています。このメカニズムは、IPv6 (SRv6) ネットワークのセグメント ルーティング [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.
この文書では、SRv6 パケットのセグメント ルーティング ヘッダー (SRH) [RFC8754] で伝送される新しい TLV 内のマーキング フィールドをエンコードする代替の実験的アプローチについて説明します。このアプローチは、SRv6 導入にのみ適用できます。[RFC9098] および [EH-LIMITS] で説明されているように、セグメント ルーティング (SR) ノードは SRH の高速解析と処理をサポートするはずであるが、SR ノードは宛先オプションを適切に処理できない可能性があるという前提を利用することを目的としています。この実験は、コミュニティにとって重要で魅力的な利点があるかどうかを判断することです。もしある場合、研究は IETF の検討のために持ち戻される可能性があります。
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.
このプロトコル拡張は、IETF の Standards Track 仕様 [RFC9343] の代替として IETF の外で開発されました。IETF のコンセンサスはありません。ここでは、実験的な実装をガイドし、実装間の相互運用性を確保して、このアプローチの価値をより適切に判断するために公開されています。[IETF-EXPERIMENTS] でも強調されているように、1 つの問題を解決するために 2 つのプロトコル拡張が提案されている場合、運用経験を収集し、「どちらかのプロトコルを標準化トラックに進める必要があるかどうかを決定する」ために実験を開始できます。これがこの文書の目的です。実験の詳細については、セクション 5 を参照してください。
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).
他の IPv6 の使用例と同様に、SRH が存在する場合は、ホップバイホップおよび宛先オプションも使用できます。[RFC8200] で規定されているように、ホップバイホップ オプション ヘッダーは、パスに沿ったすべてのホップで検査する必要があるオプション情報を運ぶために使用され、宛先オプション ヘッダーは、パケットの宛先ノードによってのみ検査する必要があるオプション情報を運ぶために使用されます。
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.
ルーティング ヘッダーが存在する場合、SRH はルーティング ヘッダーであるため、SRH ヘッダーの前に IPv6 パケットに存在する宛先オプションは、SRH のルート リストに示されている宛先によって処理されます。[RFC8754] で規定されているように、SR セグメント エンドポイント ノードは、パケットの宛先アドレスに対応するローカル セグメント識別子 (SID) を処理します。そして、セグメントリストに従って宛先アドレスが更新される。SRH TLV は、ノードがローカルでそのように構成されている場合、SID の処理中にセグメント処理用のメタデータを提供します。SRH の前の宛先オプション ヘッダーと SRH TLV は両方とも、IPv6 ヘッダーの宛先アドレス フィールドで示されているノードで処理されます。
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.
代替間の違いは、連続するセグメント エンドポイント間のパスに複数のホップが含まれるネットワークを通過する SRv6 パケットで最も顕著です。ホップバイホップ オプションを使用すると、パスに沿ったすべてのホップで AltMark データが処理されます。SRH の前に配置された宛先オプションが使用されている場合、または SRH AltMark TLV が使用されている場合、中間ノードに異なる優先順位ルールがある場合を除き、セグメント エンドポイントのみが AltMark データを処理します。
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.
[RFC9343] とこの文書で指定されているアプローチは両方とも共存できます。実際、この文書は [RFC9343] で定義されている手順を変更したり無効にしたりするものではありません。ただし、以下でさらに説明するように、展開上の問題が発生する可能性があります。
The rest of this document is structured as follows:
このドキュメントの残りの部分は次のように構成されています。
* Section 2 covers the application of the Alternate-Marking Method to SRv6,
* セクション 2 では、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),
* セクション 3 では、基本データ フィールド (セクション 3.1) と拡張データ フィールド (セクション 3.2) を伝送する AltMark SRH TLV を指定します。
* Section 4 discusses the use of the AltMark TLV, and
* セクション 4 では、AltMark TLV の使用方法について説明します。
* Section 5 describes the experiment and the objectives of the experimentation (Section 5.1).
* セクション 5 では、実験と実験の目的について説明します (セクション 5.1)。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata for segment processing, as described in [RFC8754]. 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 [RFC9343]. [RFC9343] 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 [RFC9343] is the basis of the AltMark SRH TLV introduced in Section 3.
SRv6 は、[RFC8754] で説明されているように、TLV を埋め込んでセグメント処理用のメタデータを提供できる IPv6 SRH を利用します。この文書は、SRv6 ネットワークで使用する代替マーキング データ フィールドを伝送するための SRH AltMark TLV を定義しており、[RFC9343] で説明されている方法の代替となります。[RFC9343] は、IPv6 パケットのオプション ヘッダー (ホップバイホップまたは宛先) で代替マーキング方式を伝送する方法を定義しています。[RFC9343] で定義されている AltMark データ フィールド形式は、セクション 3 で紹介されている AltMark SRH TLV の基礎です。
In addition to the base data fields of [RFC9343], the insertion of optional extended data fields that are not present in [RFC9343] is also allowed. These extended data fields can support metadata for additional telemetry requirements, as further described below.
[RFC9343] の基本データフィールドに加えて、[RFC9343] に存在しないオプションの拡張データフィールドの挿入も許可されます。これらの拡張データ フィールドは、以下でさらに説明するように、追加のテレメトリ要件のメタデータをサポートできます。
[RFC8799] introduces the concept of specific limited domain solutions and notes the application of the Alternate-Marking Method as an example.
[RFC8799] は、特定の限定されたドメイン ソリューションの概念を導入し、例として代替マーキング法の適用について言及しています。
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.
IPv6 の柔軟性にもかかわらず、革新的なアプリケーションが提案されると、ドメイン全体のポリシー、サポートされるオプション、ネットワーク管理のスタイル、およびセキュリティ要件を制限するために、それらは制御されたドメイン内で適用されることがよくあります。これは、代替マーキング方式を 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 [RFC8402]. The Alternate-Marking measurement domain overlaps with the controlled domain.
したがって、代替マーキング方式を SRv6 に適用する実験は、制御されたドメイン内でのみ展開しなければなりません (MUST)。SRv6 の場合、制御ドメインは [RFC8402] で定義されている SR ドメインに対応します。Alternate-Marking の測定ドメインは制御ドメインと重複します。
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.
制御されたドメインの使用は、実験的なプロトコル拡張の展開にも適しています。ドメインを慎重に境界付けると、実験が漏洩して他の実験と衝突したり、より広範な展開で予期せぬ結果を引き起こしたりするリスクが軽減されます。
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.
AltMark SRH TLV は、Alternate-Marking Method に関連付けられたデータ フィールドを伝送するように定義されています。TLV には、常に存在するいくつかの初期フィールドと、拡張代替マーキングの使用時に存在する追加の拡張フィールドがあります。
Figure 1 shows the format of the AltMark TLV.
図 1 は、AltMark TLV のフォーマットを示しています。
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The AltMark SRH TLV for Alternate Marking
図 1: 代替マーキング用の AltMark SRH TLV
The fields of this TLV are as follows:
この TLV のフィールドは次のとおりです。
SRH TLV Type:
SRH TLV タイプ:
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 の 8 ビット識別子。このフィールドの値は 124 ～ 126 の範囲から取得されます。これは、途中で変更されない TLV を示す実験的なコード ポイントです。このドキュメントの展開では、実験に参加するすべての実装で使用される値を調整する必要があります。したがって、実験では、他の SRH TLV との衝突を避けるために、制御されたドメインで実行されている他の実装を慎重に検討する必要があります。
SRH TLV Len:
SRH TLV レン:
The length of the Data Fields of this TLV in bytes. This is set to 6 when Enhanced Alternate Marking is not in use.
この TLV のデータ フィールドの長さ (バイト単位)。拡張代替マーキングが使用されていない場合、これは 6 に設定されます。
Reserved:
予約済み：
Reserved for future use. These bits MUST be set to zero on transmission and ignored on receipt.
将来の使用のために予約されています。これらのビットは送信時にゼロに設定され、受信時に無視されなければなりません。
FlowMonID:
フローモンID:
The Flow Monitoring Identification field. It is a 20-bit unsigned integer as defined in [RFC9343].
「フロー監視識別」フィールド。[RFC9343] で定義されている 20 ビットの符号なし整数です。
L:
L:
The Loss flag, as defined in [RFC9343].
[RFC9343] で定義されている損失フラグ。
D:
D:
The Delay flag, as defined in [RFC9343].
[RFC9343] で定義されている遅延フラグ。
NH:
NH:
The NextHeader field. It is used to indicate extended data fields are present to support Enhanced Alternate Marking as follows:
NextHeader フィールド。これは、次のように拡張代替マーキングをサポートするために拡張データ フィールドが存在することを示すために使用されます。
* NextHeader value of 0x0 means that there is no extended data field attached.
* NextHeader 値 0x0 は、拡張データ フィールドが付加されていないことを意味します。
* NextHeader values of 0x1-0x8 are reserved for further usage.
* NextHeader 値 0x1 ～ 0x8 は、今後の使用のために予約されています。
* NextHeader value of 0x9 indicates the extended data fields are present as described in Section 3.2.
* NextHeader 値 0x9 は、セクション 3.2 で説明されているように拡張データ フィールドが存在することを示します。
* NextHeader values of 0xA-0xF are reserved for further usage.
* NextHeader 値 0xA ～ 0xF は、今後の使用のために予約されています。
Optional extended data fields may be present according to the setting of the NH field and as described in Section 3.2.
セクション 3.2 で説明されているように、NH フィールドの設定に従って、オプションの拡張データ フィールドが存在する場合があります。
The base AltMark data fields are: the Loss (L) flag, the Delay (D) flag, and the Flow Monitoring Identification (FlowMonID) field, as in [RFC9343].
基本の AltMark データ フィールドは、[RFC9343] にあるように、損失 (L) フラグ、遅延 (D) フラグ、およびフロー監視識別 (FlowMonID) フィールドです。
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 [RFC9343], the FlowMonID is used to identify the monitored flow because it is not possible to utilize the Flow Label field of the IPv6 Header.
L と D は代替マーキング メソッドのマーキング フィールドであり、FlowMonID は監視対象のフローを識別するために使用され、代替マーキング メソッドの実装とスケーリングの最適化に役立ちます。[RFC9343] ですでに強調されているように、IPv6 ヘッダーのフロー ラベル フィールドを利用することができないため、監視対象フローを識別するために FlowMonID が使用されることに注意してください。
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 Section 3.2.
20 ビット FlowMonID がドメイン エントリ ノードによって設定されている場合、擬似ランダム アルゴリズムを使用して値が選択された場合でも衝突の可能性があることに注意することが重要です。したがって、監視対象のフローを一意に識別するだけでは十分ではない可能性があります。このような場合、曖昧さをなくすために、パケットに追加のフロー情報のタグを付ける必要があります。このような追加のタグ付けは、セクション 3.2 で説明されている拡張データ フィールドで実行できます。
The optional extended data fields to support Enhanced Alternate Marking are illustrated in Figure 2. They are present when the NH field of the AltMark TLV is set to 0x9.
拡張代替マーキングをサポートするためのオプションの拡張データ フィールドを図 2 に示します。これらは、AltMark TLV の NH フィールドが 0x9 に設定されている場合に存在します。
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Optional Extended Data Fields for Enhanced Alternate Marking
図 2: 強化された代替マーキングのためのオプションの拡張データ フィールド
The extended data fields are as follows:
拡張データ フィールドは次のとおりです。
FlowMonID Ext:
FlowMonID 拡張子:
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" [RFC9343].
ランダム割り当てが適用される場合の競合を軽減するために、FlowMonID を拡張するために使用される 20 ビットの符号なし整数。FlowMonID フィールドの曖昧さの解消については、「代替マーキング方式の IPv6 アプリケーション」[RFC9343] で説明されています。
Four different bit flags indicate special-purpose usage.
4 つの異なるビット フラグは、特殊な用途を示します。
M bit:
Mビット:
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.
測定モード。M=0 の場合、セグメント単位の監視であることを示します。M=1 の場合、エンドツーエンド監視であることを示します。
F bit:
Fビット:
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.
断片化。F=1 の場合、元のパケットが断片化されていることを示します。したがって、F が 1 に設定されている後続のフラグメントをすべて無視して、単一のパケットのみをカウントする必要があります。最初のフラグメントでは F が 0 に設定されていることに注意してください。
W bit:
Wビット:
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.
流れ方向の識別。このフラグは、逆方向フロー モニタリングの自動設定が要求された場合に使用され、出口ノードに逆方向フロー モニタリングを設定するように指示されます。W=1 の場合、流れの方向が前方であることを示します。W=0 の場合、流れの方向が逆であることを示します。
R bit:
Rビット:
Reserved. This bit MUST be set to zero and ignored on receipt.
予約済み。このビットはゼロに設定し、受信時に無視する必要があります。
Len:
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 Figure 2 including any metadata that is present.
長さ。拡張代替マーキングの拡張データ フィールドの長さを 4 バイトの倍数で示します。これには、存在するメタデータを含む、図 2 に示すすべてのフィールドが含まれます。
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:
拡張機能のオプションのメタデータ フィールドに添付される追加のメタデータを示す 16 ビット ビットマップ。複数のビットを設定することができ、その場合、追加のメタデータはビットが設定された順序で存在します。MetaInfo ビットには、最上位ビットとして 0 から番号が付けられます。3 ビットと関連するメタデータは次のように定義されます。
bit 0:
ビット0:
If set to 1, it indicates that a 6-byte Timestamp is present as shown in Figure 3.
1 に設定すると、図 3 に示すように 6 バイトのタイムスタンプが存在することを示します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Timestamp Extended Data Field
図 3: タイムスタンプ拡張データ フィールド
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:
このタイムスタンプはカプセル化ノードによって埋められ、カプセル化解除ノードまでずっと取得されるため、すべての中間ノードがローカル時間と比較して一方向遅延を測定できます。タイムスタンプは 2 つのフィールドで構成されます。
Timestamp(s):
タイムスタンプ:
A 16-bit integer that carries the number of seconds.
秒数を表す 16 ビット整数。
Timestamp(ns):
タイムスタンプ(ns):
A 32-bit integer that carries the number of nanoseconds.
ナノ秒数を表す 32 ビット整数。
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 [IPFIX] and [YANG-TELEMETRY]. [IPFIX] introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay. Similarly, [YANG-TELEMETRY] defines a YANG data model for monitoring On-Path Telemetry data, including the path delay.
タイムスタンプ データ フィールドにより、すべての中間ノードが一方向の遅延を測定できることに注意してください。これは、[IPFIX] および [YANG-TELEMETRY] の実装と関連付けることができます。[IPFIX] では、オンパス テレメトリで測定された遅延を公開するための新しい IP フロー情報エクスポート (IPFIX) 情報要素が導入されています。同様に、[YANG-TELEMETRY] は、パス遅延を含むオンパス テレメトリ データを監視するための YANG データ モデルを定義します。
bit 1:
ビット 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 Figure 4.
1 に設定すると、図 4 に示すように、トリガー パケットの存在に基づいて逆方向フロー監視を設定するための制御情報を示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Control Information for Backward Direction Flow Monitoring
図 4: 逆方向フロー監視の制御情報
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.
フローと一致させるために使用される宛先 IP プレフィックスの長さ。
SIP Mask:
SIP マスク:
The length of the source IP prefix used to match the flow.
フローと一致させるために使用される送信元 IP プレフィックスの長さ。
P bit:
Pビット:
If set to 1, it indicates to match the flow using the protocol identifier in the trigger packet.
1 に設定すると、トリガー パケット内のプロトコル識別子を使用してフローを照合することを示します。
I bit:
私は噛みました：
If set to 1, it indicates to match the source port.
1 に設定すると、送信元ポートと一致することを示します。
O bit:
ちょっと:
If set to 1, it indicates to match the destination port.
1 に設定すると、宛先ポートと一致することを示します。
V bit:
Vビット:
If set to 1, the node will automatically set up reverse direction monitoring and allocate a FlowMonID.
1 に設定すると、ノードは自動的に逆方向監視を設定し、FlowMonID を割り当てます。
S bit:
Sビット:
If set to 1, it indicates to match the Differentiated Services Code Point (DSCP).
1 に設定すると、Differentiated Services Code Point (DSCP) と一致することを示します。
T bit:
Tビット:
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).
トンネル測定の範囲を制御するために使用されます。T=1 は、ネットワーク間インターフェイス (つまり、NNI から NNI) 間の測定を意味します。T=0 は、ユーザーとネットワークのインターフェイス間 (つまり、UNI から UNI) の測定を意味します。
Period:
期間：
Indicates the Alternate-Marking period counted in seconds.
代替マーキング期間を秒単位で示します。
bit 2:
ビット 2:
If set to 1, it indicates that a 4-byte Sequence Number is present as shown in Figure 5.
1 に設定すると、図 5 に示すように 4 バイトのシーケンス番号が存在することを示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Sequence Number Data Field
図 5: シーケンス番号データ フィールド
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.
固有のシーケンス番号を使用して、パケット損失の測定を有効にするだけでなく、順序が乱れたパケットを検出することもできます。さらに、シーケンス番号を遅延測定とともに使用して、パケットごとのタイムスタンプにアクセスできます。
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:
測定ドメインは SR 制御ドメインと一致するため、SRv6 SRH での AltMark データのカプセル化手順は次のように要約されます。
* Ingress SR Node: As part of the SRH encapsulation, the Ingress SR Node of an SR domain or an SR Policy [RFC9256] 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.
* イングレス SR ノード: SRH カプセル化の一部として、SR ドメインまたは SR ポリシー [RFC9256] のイングレス SR ノードは、この文書で定義されたメカニズムをサポートし、代替マーキング方法を実行することを希望し、データ パケットの SRH に AltMark TLV を追加します。
* 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 [RFC8754]. 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.
* 中間 SR ノード: 中間 SR ノードは、パケットの宛先アドレスがローカル セグメント識別子 (SID) である IPv6 パケットを受信するノードです。中間 SR ノードが AltMark TLV を処理できない場合、[RFC8754] の処理規則に従って単純に無視します。中間 SR ノードが AltMark TLV を処理できる場合、SRH AltMark TLV がパケット内に存在するかどうかを確認し、それを処理します。
* 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.
* 出力 SR ノード: 出力 SR ノードは、SRH のセグメント リストの最後のノードです。出口 SR ノードでの AltMark TLV の処理は、中間 SR ノードでの AltMark TLV の処理と同じです。
The use of the AltMark TLV may be combined with the network programming capability of SRv6 [RFC8986]. 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.
AltMark TLV の使用は、SRv6 [RFC8986] のネットワーク プログラミング機能と組み合わせることができます。具体的には、SRv6 エンドポイントが一部の特定の SRH TLV (AltMark TLV など) を処理するか無視するかを決定する機能は、中間 SR ノードまたは出力 SR ノードによってアドバタイズされ、SRv6 パケットの宛先アドレス フィールドで使用される SID に関連付けられた SID 関数に基づく場合があります。パケットが Alternate-Marking 機能をサポートしていない SID にアドレス指定されている場合、受信ノードは SRH AltMark TLV を検索または処理する必要がなく、単純に無視できます。これにより、サポートするセグメント エンドポイントからのみ代替マーキング データを収集することも可能になります。
As highlighted in Section 1.1, 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.
セクション 1.1 で強調したように、SRH の前に AltMark データを伝送するための Destination Option の使用は、SRH AltMark TLV と同等です。したがって、SRH AltMark TLV と宛先オプションの両方が存在する場合に何が起こるか、それが処理と複雑さにどのような影響を与えるかを分析することが重要です。
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 [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.
SRH AltMark TLV と AltMark データを運ぶ Destination Option は問題なく共存できることに注意してください。両方が存在する場合、唯一の問題は情報の重複である可能性がありますが、これはデバイスとネットワーク サービスにはまったく影響しません。この文書と [RFC9343] はどちらも、セキュリティ目的で制御されたドメインを必要とし、この重複を単一のサービス プロバイダー ネットワークに制限します。異なる場所で同じ情報が重複することは避けるべきであり、この実験の一環として SRH AltMark TLV のみの使用を分析することが推奨されます。
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 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.
このドキュメントで説明されているプロトコル拡張は、実験用コード ポイントを使用した既存のテクノロジーに基づいて構築されています。実験参加者は、セクション 3 で説明したように、実験範囲から選択されたコード ポイントを使用する必要があり、同じネットワーク内で競合しない複数の実験を実行できるように、展開で使用される値をオペレーターが構成できるようにする必要があります。
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.
この実験は、特に、同じパケット内で複数の IPv6 拡張ヘッダーをサポートできない実装、宛先オプション ヘッダーの処理をサポートしない実装、または低速パスで宛先オプション ヘッダーを処理する実装を考慮して、SRH AltMark TLV の使用が利点をもたらすかどうかを判断することを目的としています。
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.
この実験では、提案されたプロトコル拡張が目的の機能を達成し、通常の SRv6 処理の存在下でサポートできるかどうかを判断する必要もあります。特に、実験では SR ネットワーク プログラミング、SID 機能制御、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.
この実験は、SR ドメインの制約に合わせて、またネットワーク内のパケットのパスで収集されたパフォーマンス監視データの共有の制限にも合わせて、単一のサービス プロバイダー ネットワーク内に含まれることが予想されます。実験的展開の範囲は、実装の可用性と、それをライブネットワーク上に展開するオペレータの意欲に依存する可能性があります。
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.
この実験の結果は収集され、Independent Submissions Editor または IETF SPRING Working Group とインターネット ドラフトとして共有され、SRv6 ネットワークにおける代替マーキング方式ソリューションの適切な開発を決定するための議論を進めるのに役立ちます。最初の結果は、この文書が RFC として公開されてから 2 年以内に利用可能になることが期待されています。
Researchers are invited to evaluate the SRH AltMark TLV against the existing approach in [RFC9343]. There are several potential areas of exploration for this experimentation that need to be analyzed:
研究者は、[RFC9343] の既存のアプローチに対して SRH AltMark TLV を評価するよう招待されます。この実験には、分析する必要がある潜在的な探索領域がいくつかあります。
* Does the use of the SRH AltMark TLV survive across a network better or worse than the use of an extension header?
* SRH AltMark TLV の使用は、拡張ヘッダーの使用よりもネットワーク全体で存続しますか?
* Does the SRH TLV processing represent a performance improvement or hindrance on the device as compared to the Destination Option?
* SRH TLV 処理は、宛先オプションと比較してデバイスのパフォーマンスの向上または障害を表しますか?
* 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?
* SRH TLV の使用と宛先オプションの使用を比較した場合、フォワーディング プレーンのパフォーマンスはさまざまなデバイス アーキテクチャ タイプに影響を受けますか?
* How does use of the extended data fields, introduced in Section 3.2, compare to other on-path telemetry methods from the point of view of the operators?
* セクション 3.2 で導入された拡張データ フィールドの使用は、オペレータの観点から他のオンパス テレメトリ方法とどのように比較されますか?
The security considerations of SRv6 are discussed in [RFC8754] and [RFC8986], and the security considerations of Alternate Marking in general and its application to IPv6 are discussed in [RFC9341] and [RFC9343].
SRv6 のセキュリティに関する考慮事項は [RFC8754] および [RFC8986] で議論され、代替マーキング一般およびその IPv6 への適用のセキュリティに関する考慮事項は [RFC9341] および [RFC9343] で議論されます。
[RFC9343] 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 [RFC8799] and Section 2.1.
[RFC9343] は、さまざまなセキュリティ上の懸念事項と関連する解決策を分析しています。これらの側面は有効であり、この文書にも当てはまります。特に、基本的なセキュリティ要件は、[RFC8799] およびセクション 2.1 にも記載されているように、代替マーキングは限られたドメインにのみ適用されなければならないということです。
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.
代替マーキングは、信頼できるドメインに適用される機能であり、単一のオペレータがニーズに応じて代替マーキングの活用と構成を決定します。さらに、オペレータは、ドメインへの悪意のあるパケットの挿入などの悪意のある構成や攻撃を回避するために、Alternate-Marking ドメインを適切に保護する必要があります。したがって、代替マーキングの実装は、ネットワーク ノードがローカルに管理され、AltMark TLV を含むパケットがドメインに出入りすることが防止される、制御されたドメイン内に適用されます。制限された管理ドメインは、ネットワーク管理者にネットワークへのアクセスを選択、監視、および制御する手段を提供します。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
[EH-LIMITS]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-19, 27 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-19>.
[IETF-EXPERIMENTS]
Bonica, R. and A. Farrel, "IETF Experiments", Work in
Progress, Internet-Draft, draft-bonica-gendispatch-exp-07,
19 January 2026, <https://datatracker.ietf.org/doc/html/
draft-bonica-gendispatch-exp-07>.
[IPFIX] Graf, T., Claise, B., and A. H. Feng, "Export of Delay
Performance Metrics in IP Flow Information eXport
(IPFIX)", Work in Progress, Internet-Draft, draft-ietf-
opsawg-ipfix-on-path-telemetry-23, 30 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
ipfix-on-path-telemetry-23>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[YANG-TELEMETRY]
Fioccola, G., Zhou, T., Zhu, Y., Zhang, W., and K. Zhu,
"On-Path Telemetry YANG Data Model", Work in Progress,
Internet-Draft, draft-ietf-ippm-on-path-telemetry-yang-02,
2 January 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-on-path-telemetry-yang-02>.
The authors would like to thank Eliot Lear, Adrian Farrel, Joel M. Halpern, and Haoyu Song for the precious comments and suggestions.
著者らは、貴重なコメントと提案をくださった Eliot Lear、Adrian Farrel、Joel M. Halpern、Haoyu Song に感謝の意を表します。
The following people provided relevant contributions to this document:
次の人物がこのドキュメントに関連する寄稿を提供しました。
Fabio Bulgarella
Telecom Italia
Email: fabio.bulgarella@guest.telecomitalia.it
Massimo Nilo
FiberCop
Email: massimo.nilo@fibercop.com
Fabrizio Milan
FiberCop
Email: fabrizio.milan@fibercop.com
Giuseppe Fioccola
Huawei
Viale Martesana, 12
20055 Vimodrone (Milan)
Italy
Email: giuseppe.fioccola@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com
Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Xuewei Wang
Ruijie
Email: wangxuewei1@ruijie.com.cn
Geng Zhang
China Mobile
Email: zhanggeng@chinamobile.com
Mauro Cociglio
Email: mauro.cociglio@outlook.com