[要約] RFC 7922は、I2RSトレース能力のためのフレームワークと情報モデルを提供しています。その目的は、ネットワークルーティングシステムのトレース能力を向上させ、ネットワークの可視性と管理を向上させることです。
Internet Engineering Task Force (IETF) J. Clarke
Request for Comments: 7922 G. Salgueiro
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco
June 2016
Interface to the Routing System (I2RS) Traceability: Framework and Information Model
ルーティングシステム（I2RS）トレーサビリティへのインターフェイス：フレームワークと情報モデル
Abstract
概要
This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.
このドキュメントでは、ルーティングシステムへのインターフェイス（I2RS）のトレーサビリティのフレームワークと、そのフレームワークの情報モデルについて説明します。動機、要件、およびユースケースを指定し、I2RSプロトコルを実装する要素間の相互作用を記録するための情報モデルを定義します。このフレームワークは、I2RSアーキテクチャを実装するコンポーネントに一貫したトレースインターフェイスを提供し、何がいつ、どのコンポーネントで行われたかを記録します。 I2RS実装の管理を改善することを目的としており、トラブルシューティング、監査、フォレンジック、および会計目的に使用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7922.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7922で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology and Conventions .....................................3
3. Motivation ......................................................4
4. Use Cases .......................................................4
5. Information Model ...............................................5
5.1. I2RS Traceability Framework ................................5
5.2. I2RS Trace Log Fields ......................................7
5.3. End of Message Marker .....................................11
6. Examples .......................................................11
7. Operational Guidance ...........................................11
7.1. Trace Log Creation ........................................12
7.2. Trace Log Temporary Storage ...............................12
7.3. Trace Log Rotation ........................................13
7.4. Trace Log Retrieval .......................................13
7.4.1. Retrieval via Syslog ...............................14
7.4.2. Retrieval via I2RS Information Collection ..........14
7.4.3. Retrieval via I2RS Pub/Sub .........................14
8. Security Considerations ........................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
The architecture for the Interface to the Routing System [RFC7921] specifies that I2RS clients wishing to retrieve or change the routing state on a routing element MUST authenticate to an I2RS agent. The I2RS client will have a unique identity it provides for authentication, and should provide another opaque identity for applications communicating through it. The programming of routing state will produce a return code containing the results of the specified operation and associated reason(s) for the result. All of this is critical information to be used for understanding the history of I2RS interactions.
ルーティングシステムへのインターフェイス[RFC7921]のアーキテクチャは、ルーティング要素のルーティング状態を取得または変更するI2RSクライアントがI2RSエージェントに対して認証する必要があることを指定しています。 I2RSクライアントは、認証に提供する一意のIDを持ち、それを介して通信するアプリケーションに別の不透明なIDを提供する必要があります。ルーティング状態のプログラミングは、指定された操作の結果とその結果の関連する理由を含む戻りコードを生成します。これらすべては、I2RS相互作用の履歴を理解するために使用される重要な情報です。
This document defines the framework necessary to trace those interactions between the I2RS client and I2RS agent. It goes on to describe use cases for traceability within I2RS. Based on these use cases, the document proposes an information model and reporting requirements to provide for effective recording of I2RS interactions. In this context, effective troubleshooting means being able to identify what operation was performed by a specific I2RS client via the I2RS agent, what was the result of the operation, and when that operation was performed.
このドキュメントでは、I2RSクライアントとI2RSエージェントの間の相互作用を追跡するために必要なフレームワークを定義します。続いて、I2RS内のトレーサビリティのユースケースについて説明します。これらのユースケースに基づいて、ドキュメントは、I2RS相互作用の効果的な記録を提供するための情報モデルとレポート要件を提案します。このコンテキストでは、効果的なトラブルシューティングとは、I2RSエージェントを介して特定のI2RSクライアントによって実行された操作、操作の結果、およびその操作がいつ実行されたかを識別できることを意味します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The architecture specification for I2RS [RFC7921] defines additional terms used in this document that are specific to the I2RS domain, such as "I2RS agent", "I2RS client", etc. The reader is expected to be familiar with the terminology and concepts defined in [RFC7921].
I2RSのアーキテクチャ仕様[RFC7921]は、このドキュメントで使用されている、「I2RSエージェント」、「I2RSクライアント」など、I2RSドメインに固有の追加の用語を定義しています。読者は、定義された用語と概念に精通している必要があります。 [RFC7921]。
As networks scale and policy becomes an increasingly important part of the control plane that creates and maintains the forwarding state, operational complexity increases as well. I2RS offers more granular and coherent control over policy and control-plane state, but it also removes or reduces the locality of the policy that has been applied to the control plane at any individual forwarding device. The ability to automate and abstract even complex policy-based controls highlights the need for an equally scalable traceability function to provide recording at event-level granularity of the evolution of the routing system compliant with the requirements of I2RS (Section 5 of [RFC7920]).
ネットワークのスケーリングとポリシーが、フォワーディングステートを作成および維持するコントロールプレーンのますます重要な部分になると、運用の複雑さも増加します。 I2RSは、ポリシーとコントロールプレーンの状態をより細かく一貫した制御を提供しますが、個々の転送デバイスでコントロールプレーンに適用されているポリシーの局所性を削除または削減します。複雑なポリシーベースの制御を自動化して抽象化する機能は、I2RSの要件に準拠したルーティングシステムの進化のイベントレベルの粒度で記録を提供するために、同等にスケーラブルなトレーサビリティ機能の必要性を強調します（[RFC7920]のセクション5）。 。
An obvious motivation for I2RS traceability is the need to troubleshoot and identify root causes of problems in these increasingly complex routing systems. For example, since I2RS is a high-throughput multi-channel, full duplex, and highly responsive interface, I2RS clients may be performing a large number of operations on I2RS agents concurrently or at nearly the same time and quite possibly in very rapid succession. As these many changes are made, the network reacts accordingly. These changes might lead to a race condition, performance issues, data loss, or disruption of services. In order to isolate the root cause of these issues, it is critical that a network operator or administrator has visibility into what changes were made via I2RS at a specific time.
I2RSトレーサビリティの明らかな動機は、これらのますます複雑になるルーティングシステムの問題の根本原因をトラブルシューティングして特定する必要があることです。たとえば、I2RSは高スループットのマルチチャネル、全二重、および応答性の高いインターフェイスであるため、I2RSクライアントは、I2RSエージェント上で多数の操作を同時にまたはほぼ同時に、非常に迅速に連続して実行している可能性があります。これらの多くの変更が行われると、ネットワークはそれに応じて反応します。これらの変更は、競合状態、パフォーマンスの問題、データの損失、またはサービスの中断につながる可能性があります。これらの問題の根本的な原因を特定するには、ネットワークオペレーターまたは管理者が特定の時間にI2RSを介して行われた変更を確認できることが重要です。
Some network environments have strong auditing requirements for configuration and runtime changes. Other environments have policies that require saving logging information for operational or regulatory compliance considerations. These requirements therefore demand that I2RS provides an account of changes made to network element routing systems.
一部のネットワーク環境には、構成およびランタイムの変更に対する強力な監査要件があります。他の環境には、運用上または規制上のコンプライアンスを考慮してログ情報を保存する必要があるポリシーがあります。したがって、これらの要件は、I2RSがネットワーク要素ルーティングシステムに加えられた変更のアカウントを提供することを要求します。
As I2RS becomes increasingly pervasive in routing environments, a traceability model that supports controllable trace log retention using a standardized structured data format offers significant advantages, such as the ability to create common tools supporting automated testing, and facilitates the following use cases: o real-time monitoring and troubleshooting of router events;
I2RSがルーティング環境にますます広がるようになると、標準化された構造化データ形式を使用して制御可能なトレースログの保持をサポートするトレーサビリティモデルは、自動テストをサポートする一般的なツールを作成する機能などの大きな利点を提供し、次のユースケースを容易にします。ルーターイベントの時間監視とトラブルシューティング
o automated event correlation, trend analysis, and anomaly detection;
o 自動化されたイベント相関、傾向分析、および異常検出。
o offline (manual or tools-based) analysis of router state evolution from the retained trace logs;
o 保持されたトレースログからのルーター状態の進化のオフライン（手動またはツールベース）分析。
o enhanced network audit, management, and forensic analysis capabilities;
o 強化されたネットワーク監査、管理、およびフォレンジック分析機能。
o improved accounting of routing system operations; and
o ルーティングシステム操作のアカウンティングの改善。そして
o providing a standardized format for incident reporting and test logging.
o インシデントレポートとテストログの標準化された形式を提供します。
These sections describe the I2RS traceability information model and the details about each of the fields to be logged.
これらのセクションでは、I2RSトレーサビリティ情報モデルと、ログに記録される各フィールドの詳細について説明します。
This section describes a framework for I2RS traceability based on the I2RS Architecture.
このセクションでは、I2RSアーキテクチャに基づくI2RSトレーサビリティのフレームワークについて説明します。
The interaction between the optional network application that drives client activity, I2RS client, I2RS agent, the Routing System, and the data captured in the I2RS trace log is shown in Figure 1.
図1は、クライアントアクティビティを駆動するオプションのネットワークアプリケーション、I2RSクライアント、I2RSエージェント、ルーティングシステム、およびI2RSトレースログにキャプチャされたデータの相互作用を示しています。
+---------------+
+----------------+ |
|Application | |
|.............. | | 0 or more Applications
| Application ID | +
+----------------+
^
|
|
v
+-------------+
+-------------+ |
|I2RS Client | |
|.............| | 1 or more Clients
| Client ID | +
+-------------+
^
|
|
v
+-------------+ +-----------------------------+
|I2RS Agent |---------------->|Trace Log |
| | |.............................|
+-------------+ |Log Entry [1 .. N] |
| ^ |.............................|
| | |Event ID |
| | |Starting Timestamp |
| | |Request State |
| | |Client ID |
| | |Client Priority |
| | |Secondary ID |
Operation + | | Result Code |Client Address |
Op Data | | |Requested Operation |
| | |Applied Operation |
| | |Operation Data Present |
| | |Requested Operation Data |
| | |Applied Operation Data |
| | |Transaction ID |
| | |Result Code |
| | |Ending Timestamp |
| | |Timeout Occurred |
v | |End Of Message |
+-------------+ +-----------------------------+
|Routing |
|System |
+-------------+
Figure 1: I2RS Interaction Trace Log Capture
図1：I2RS相互作用トレースログのキャプチャ
The following fields comprise an I2RS trace log. These fields ensure that each I2RS interaction can be properly traced back to the client that made the request at a specific point in time.
次のフィールドは、I2RSトレースログを構成します。これらのフィールドにより、各I2RSインタラクションを、特定の時点で要求を行ったクライアントまで適切に追跡できます。
The list below describes the fields captured in the I2RS trace log. This list represents a common set of fields that MUST appear in all I2RS trace logs. In addition to these fields, I2RS agent implementations MAY choose to log additional fields such as I2RS client vendor or agent statistics like free memory, performance metrics, etc.
以下のリストは、I2RSトレースログにキャプチャされるフィールドについて説明しています。このリストは、すべてのI2RSトレースログに表示される必要がある一般的なフィールドのセットを表します。これらのフィールドに加えて、I2RSエージェント実装は、I2RSクライアントベンダーや空きメモリ、パフォーマンスメトリックなどのエージェント統計などの追加フィールドをログに記録することを選択できます（MAY）。
Event ID: This is a unique identifier for each event in the I2RS trace log. An event can be a client authenticating with the agent, a client to agent operation, or a client disconnecting from an agent. Operation events can either be logged atomically upon completion (in which case they will have both a Starting and an Ending Timestamp field) or they can be logged at the beginning of each Request State transition. Since operations can occur from the same client at the same time, it is important to have an identifier that can be unambiguously associated to a specific entry. If each state transition is logged for an operation, the same ID MUST be used for each of the Request State log entries. In this way, the life of a request can be easily followed in the I2RS trace log. Beyond the requirement that the Event ID MUST be unique for each event, the specific type and value is left up to the implementation.
イベントID：これは、I2RSトレースログの各イベントの一意の識別子です。イベントは、エージェントで認証するクライアント、クライアントからエージェントへの操作、またはエージェントから切断するクライアントです。操作イベントは、完了時にアトミックにログに記録するか（この場合、開始タイムスタンプフィールドと終了タイムスタンプフィールドの両方を持つ）、または各要求状態遷移の開始時にログに記録できます。操作は同じクライアントから同時に発生する可能性があるため、特定のエントリに明確に関連付けることができる識別子を持つことが重要です。操作の各状態遷移がログに記録される場合、各要求状態ログエントリに同じIDを使用する必要があります。このように、I2RSトレースログで要求の存続期間を簡単に追跡できます。イベントIDはイベントごとに一意である必要があるという要件を超えて、特定のタイプと値は実装に任されています。
Starting Timestamp: The specific time at which the I2RS operation enters the specified Request State within the agent. If the log entry covers the entire duration of the request, then this will be the time that it was first received by the agent. This field MUST be present in all entries that specify the beginning of the state transition, as well as those entries that log the entire duration of the request. The time is passed in the full timestamp format [RFC3339], including the date and offset from Coordinated Universal Time (UTC). Given that many I2RS operations can occur in rapid succession, the fractional seconds element of the timestamp MUST be used to provide adequate granularity. Fractional seconds SHOULD be expressed with at least three significant digits in second.microsecond format.
開始タイムスタンプ：I2RS操作がエージェント内の指定された要求状態に入る特定の時間。ログエントリがリクエストの期間全体をカバーしている場合、これはエージェントによって最初に受信された時刻になります。このフィールドは、状態遷移の開始を指定するすべてのエントリと、リクエストの期間全体を記録するエントリに存在する必要があります。時刻は、日付と協定世界時（UTC）からのオフセットを含む完全なタイムスタンプ形式[RFC3339]で渡されます。多くのI2RS操作が連続して発生する可能性があることを考えると、タイムスタンプの小数秒要素を使用して、適切な粒度を提供する必要があります。小数秒は、second.microsecond形式で少なくとも3桁の有効数字で表現する必要があります（SHOULD）。
Request State: The state of the given operation within the I2RS agent state machine at the specified Starting or Ending Timestamps. The I2RS agent SHOULD generate a log entry at the moment a request enters and exits a state. Upon entering a new state, the log entry will have a Starting Timestamp set to the time of entry and no Ending Timestamp. Upon exiting a state, the log entry will have an Ending Timestamp set to the time of exit and no Starting Timestamp. The progression of the request through its various states can be linked using the Event ID. The states can be one of the following values:
要求状態：指定された開始または終了タイムスタンプでのI2RSエージェント状態マシン内の特定の操作の状態。 I2RSエージェントは、リクエストが状態に出入りするときにログエントリを生成する必要があります（SHOULD）。新しい状態に入ると、ログエントリには開始タイムスタンプがエントリの時刻に設定され、終了タイムスタンプはありません。状態を終了すると、ログエントリには終了タイムスタンプが終了時刻に設定され、開始タイムスタンプはありません。イベントIDを使用して、リクエストのさまざまな状態の進行をリンクできます。状態は、次のいずれかの値になります。
PENDING: The request has been received and queued for processing.
PENDING：リクエストが受信され、処理のためにキューに入れられました。
IN PROCESS: The request is currently being handled by the I2RS agent.
IN PROCESS：リクエストは現在I2RSエージェントによって処理されています。
COMPLETED: The request has reached a terminal point.
COMPLETED：リクエストが終点に達しました。
Every state transition SHOULD be logged unless doing so will put an undue performance burden on the I2RS agent. However, an entry with the Request State set to COMPLETED MUST be logged for all operations. If the COMPLETED state is the only entry for a given request, then it MUST have both Starting and Ending Timestamps that cover the entire duration of the request from ingress to the agent until completion.
I2RSエージェントに過度のパフォーマンス負荷をかけない限り、すべての状態遷移をログに記録する必要があります（SHOULD）。ただし、リクエストの状態がCOMPLETEDに設定されているエントリは、すべての操作でログに記録する必要があります。 COMPLETED状態が特定の要求の唯一のエントリである場合、開始から終了までの要求の期間全体をカバーする開始と終了の両方のタイムスタンプが必要です。
Client Identity: The I2RS client identity used to authenticate the client to the I2RS agent.
クライアントID：I2RSエージェントに対するクライアントの認証に使用されるI2RSクライアントID。
Client Priority: The I2RS client priority assigned by the access control model that authenticates the client. For example, this can be set by the Network Configuration Protocol (NETCONF) Access Control Model (NACM) as described in [RFC6536].
クライアントの優先度：クライアントを認証するアクセス制御モデルによって割り当てられたI2RSクライアントの優先度。たとえば、これは、[RFC6536]で説明されているように、ネットワーク構成プロトコル（NETCONF）アクセス制御モデル（NACM）によって設定できます。
Secondary Identity: This is an opaque identity that may be known to the client from a controlling network application. This is used to trace the network application driving the actions of the client. The client may not provide this identity to the agent if there is no external network application driving the client. However, this field MUST be logged even if the client does not provide a Secondary Identity. In that case, the field will be logged with an empty value.
セカンダリID：これは、制御しているネットワークアプリケーションからクライアントに認識される可能性がある不透明なIDです。これは、クライアントのアクションを駆動するネットワークアプリケーションを追跡するために使用されます。クライアントを駆動する外部ネットワークアプリケーションがない場合、クライアントはこのIDをエージェントに提供しない可能性があります。ただし、クライアントがセカンダリIDを提供しない場合でも、このフィールドはログに記録される必要があります。その場合、フィールドは空の値でログに記録されます。
Client Address: This is the network address of the client that connected to the agent. For example, this may be an IPv4 or an IPv6 address.
クライアントアドレス：これは、エージェントに接続したクライアントのネットワークアドレスです。たとえば、これはIPv4またはIPv6アドレスです。
Requested Operation: This is the I2RS operation that was requested to be performed. For example, this may be an add route operation if a route is being inserted into a routing table. This may not be the operation that was actually applied to the agent.
要求された操作：これは、実行が要求されたI2RS操作です。たとえば、ルートがルーティングテーブルに挿入されている場合、これはルートの追加操作である可能性があります。これは、エージェントに実際に適用された操作ではない可能性があります。
In the case of a client authenticating to the agent, the Requested Operation MUST be "CLIENT AUTHENTICATE". In the case of a client disconnecting from the agent, the Requested Operation MUST be "CLIENT DISCONNECT".
エージェントがクライアントを認証する場合、要求された操作は「クライアント認証」でなければなりません。クライアントがエージェントから切断する場合、要求された操作は「クライアント切断」でなければなりません。
Applied Operation: This is the I2RS operation that was actually performed. This can differ from the Requested Operation in cases where the agent cannot satisfy the Requested Operation. This field may not be logged unless the Request State is COMPLETED.
適用された操作：これは、実際に実行されたI2RS操作です。これは、エージェントが要求された操作を満たすことができない場合に、要求された操作とは異なる場合があります。このフィールドは、リクエストの状態がCOMPLETEDでない限り、ログに記録されない場合があります。
Operation Data Present: This is a Boolean field that indicates whether or not additional per-Operation Data is present.
オペレーションデータの存在：これは、オペレーションごとの追加のデータが存在するかどうかを示すブールフィールドです。
Requested Operation Data: This field comprises the data passed to the agent to complete the desired operation. For example, if the operation is a route add operation, the Operation Data would include the route prefix, prefix length, and next-hop information to be inserted as well as the specific routing table to which the route will be added. If Operation Data is provided, then the Operation Data Present field MUST be set to TRUE. Some operations may not provide operation data. In those cases, the Operation Data Present field MUST be set to FALSE, and this field MUST be empty. This may not represent the data that was used for the operation that was actually applied on the agent.
要求された操作データ：このフィールドには、目的の操作を完了するためにエージェントに渡されるデータが含まれます。たとえば、操作がルート追加操作の場合、操作データには、ルートプレフィックス、プレフィックス長、挿入されるネクストホップ情報、およびルートが追加される特定のルーティングテーブルが含まれます。オペレーションデータが提供される場合、オペレーションデータ存在フィールドはTRUEに設定する必要があります。一部の操作では操作データが提供されない場合があります。これらの場合、Operation Data PresentフィールドはFALSEに設定する必要があり、このフィールドは空である必要があります。これは、エージェントに実際に適用された操作に使用されたデータを表していない場合があります。
When a client authenticates to the agent, the Requested Operation Data MUST contain the client priority. Other attributes such as credentials used for authentication MAY be logged.
クライアントがエージェントに対して認証を行う場合、要求された操作データにはクライアントの優先順位が含まれている必要があります。認証に使用される資格情報などの他の属性がログに記録される場合があります。
Applied Operation Data: This field comprises the data that was actually applied as part of the Applied Operation. If the agent cannot satisfy the Requested Operation with the Requested Operation Data, then this field can differ from the Requested Operation Data. This field will be empty unless the Requested Operation Data was specified. This field may not be logged unless the Request State is COMPLETED.
適用操作データ：このフィールドには、適用操作の一部として実際に適用されたデータが含まれます。エージェントが、要求された操作データで要求された操作を満たすことができない場合、このフィールドは、要求された操作データと異なる場合があります。要求された操作データが指定されていない限り、このフィールドは空になります。このフィールドは、リクエストの状態がCOMPLETEDでない限り、ログに記録されない場合があります。
Transaction ID: The Transaction Identity represents that this particular operation is part of a long-running I2RS transaction that can consist of multiple, related I2RS operations. Using this value, one can relate multiple log entries together as they are part of a single, overall I2RS operation. This is an optional field that may not be logged unless the event is part of a long-running transaction.
トランザクションID：トランザクションIDは、この特定の操作が、関連する複数のI2RS操作で構成される可能性のある長時間実行I2RSトランザクションの一部であることを表します。この値を使用すると、複数のログエントリを1つの全体的なI2RS操作の一部として関連付けることができます。これはオプションのフィールドであり、イベントが長期実行トランザクションの一部でない限り、ログに記録されない場合があります。
Result Code: This field holds the result of the operation once the Request State is COMPLETED. In the case of Routing Information Base (RIB) operations, this MUST be the return code as specified in Section 4 of [RIBINFO]. The operation may not complete with a result code in the case of a timeout. If the operation fails to complete, it MUST still log the attempted operation with an appropriate result code.
結果コード：このフィールドには、要求状態が完了したときの操作の結果が保持されます。ルーティング情報ベース（RIB）操作の場合、これは[RIBINFO]のセクション4で指定されている戻りコードである必要があります。タイムアウトの場合、操作は結果コードで完了しない場合があります。操作が完了しなかった場合でも、試行された操作を適切な結果コードで記録する必要があります。
Timeout Occurred: This is a Boolean field that indicates whether or not a timeout occurred in the operation. When this is true, the value of the Ending Timestamp MUST be set to the time the agent recorded for the timeout occurrence. This field may not be logged unless the Request State is COMPLETED.
タイムアウトが発生しました：これは、操作でタイムアウトが発生したかどうかを示すブール値フィールドです。これがtrueの場合、終了タイムスタンプの値は、エージェントがタイムアウトの発生について記録した時間に設定する必要があります。このフィールドは、リクエストの状態がCOMPLETEDでない限り、ログに記録されない場合があります。
Ending Timestamp: The specific time at which the I2RS operation exits the specified Request State within the I2RS agent. If the log entry covers the entire duration of the request, then this will be the time that the request reached a terminal point within the agent. This field MUST be present in all entries that specify the ending of the state transition, as well as those entries that log the entire duration of the request. The time is passed in the full timestamp format [RFC3339], including the date and offset from Coordinated Universal Time (UTC). See the description for Starting Timestamp above for the proper format of the Ending Timestamp.
Ending Timestamp：I2RS操作がI2RSエージェント内の指定された要求状態を終了する特定の時間。ログエントリがリクエストの期間全体をカバーしている場合、これはリクエストがエージェント内のターミナルポイントに到達した時間になります。このフィールドは、状態遷移の終了を指定するすべてのエントリと、要求の期間全体を記録するエントリに存在する必要があります。時刻は、日付と協定世界時（UTC）からのオフセットを含む完全なタイムスタンプ形式[RFC3339]で渡されます。終了タイムスタンプの正しい形式については、上記の開始タイムスタンプの説明を参照してください。
End Of Message: Each log entry SHOULD have an appropriate End Of Message (EOM) indicator. See Section 5.3 below for more details.
メッセージの終わり：各ログエントリには、適切なメッセージの終わり（EOM）インジケーターが必要です（SHOULD）。詳細については、以下のセクション5.3を参照してください。
Because of variability within I2RS trace log fields, implementors MUST use a format-appropriate End Of Message (EOM) indicator in order to signify the end of a particular record. That is, regardless of format, the I2RS trace log MUST provide a distinct way of distinguishing between the end of one record and the beginning of another. For example, in a linear-formatted log (similar to a syslog) the EOM marker may be a newline character. In an XML-formatted log, the schema would provide for element tags that denote the beginning and end of records. In a JSON-formatted log, the syntax would provide record separation (likely by comma-separated array elements).
I2RSトレースログフィールド内の可変性のため、特定のレコードの終わりを示すために、実装者はフォーマットに適したメッセージの終わり（EOM）インジケーターを使用する必要があります。つまり、フォーマットに関係なく、I2RSトレースログは、あるレコードの終わりと別のレコードの始まりを区別する明確な方法を提供する必要があります。たとえば、線形形式のログ（syslogに類似）では、EOMマーカーは改行文字である場合があります。 XML形式のログでは、スキーマはレコードの開始と終了を示す要素タグを提供します。 JSON形式のログでは、構文によりレコードが分離されます（おそらくコンマで区切られた配列要素による）。
This section shows a sample of what the fields and values could look like.
このセクションでは、フィールドと値の例を示します。
Event ID: 1
Starting Timestamp: 2013-09-03T12:00:01.21+00:00
Request State: COMPLETED
Client ID: 5CEF1870-0326-11E2-A21F-0800200C9A66
Client Priority: 100
Secondary ID: com.example.RoutingApp
Client Address: 2001:db8:c0c0::2
Requested Operation: ROUTE_ADD
Applied Operation: ROUTE_ADD
Operation Data Present: TRUE
Requested Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64
NEXT-HOP 2001:db8:cafe::1
Applied Operation Data: PREFIX 2001:db8:feed:: PREFIX-LEN 64
NEXT-HOP 2001:db8:cafe::1
Transaction ID: 2763461
Result Code: SUCCESS(0)
Timeout Occurred: FALSE
Ending Timestamp: 2013-09-03T12:00:01.23+00:00
Specific operational procedures regarding temporary log storage, rollover, retrieval, and access of I2RS trace logs is out of scope for this document. Organizations employing I2RS trace logging are responsible for establishing proper operational procedures that are appropriately suited to their specific requirements and operating environment. In this section, we only provide fundamental and generalized operational guidelines that are implementation independent.
I2RSトレースログの一時的なログの保存、ロールオーバー、取得、およびアクセスに関する特定の操作手順は、このドキュメントの範囲外です。 I2RSトレースロギングを採用している組織は、特定の要件と運用環境に適切に適した適切な運用手順を確立する責任があります。このセクションでは、実装に依存しない基本的かつ一般化された運用ガイドラインのみを提供します。
The I2RS agent interacts with the Routing and Signaling functions of the Routing Element. Since the I2RS agent is responsible for actually making the routing changes on the associated network device, it creates and maintains a log of operations that can be retrieved to troubleshoot I2RS-related impact to the network. Changes that occur to the network element's local configuration outside of the I2RS protocol that preempt I2RS state will only be logged if the network element notifies the I2RS agent.
I2RSエージェントは、ルーティング要素のルーティングおよびシグナリング機能と対話します。 I2RSエージェントは、関連付けられたネットワークデバイスで実際にルーティングの変更を行う責任があるため、ネットワークへのI2RS関連の影響をトラブルシューティングするために取得できる操作のログを作成および維持します。ネットワーク要素がI2RSエージェントに通知した場合にのみ、I2RS状態を優先するI2RSプロトコルの外部でネットワーク要素のローカル構成に発生した変更がログに記録されます。
The trace information may be temporarily stored either in an in-memory buffer or as a file local to the agent. Care should be given to the number of I2RS operations expected on a given agent so that the appropriate storage medium is used, and to maximize the effectiveness of the log while not impacting the performance and health of the agent. client requests may not always be processed synchronously or within a bounded time period. Consequently, to ensure that trace log fields, such as "Operation" and "Result Code", are part of the same trace log record, buffering of the trace log entries may be required. This buffering may result in additional resource load on the agent and the network element.
トレース情報は、メモリ内のバッファに一時的に格納されるか、エージェントのローカルファイルとして格納されます。適切なストレージメディアが使用されるように、またエージェントのパフォーマンスと正常性に影響を与えずにログの効果を最大化するために、特定のエージェントで予想されるI2RS操作の数に注意を払う必要があります。クライアント要求は、常に同期的に、または限られた時間内に処理されるとは限りません。したがって、「操作」や「結果コード」などのトレースログフィールドが同じトレースログレコードの一部であることを確認するには、トレースログエントリのバッファリングが必要になる場合があります。このバッファリングにより、エージェントとネットワーク要素に追加のリソース負荷がかかる可能性があります。
Section 7.3 discusses rotating the trace log in order to preserve the operation history without exhausting agent or network device resources. It is perfectly acceptable, therefore, to use both an in-memory buffer for recent operations while rotating or archiving older operations to a local file.
セクション7.3では、エージェントやネットワークデバイスのリソースを使い果たすことなく操作履歴を保存するために、トレースログをローテーションする方法について説明します。したがって、古い操作をローカルファイルにローテーションまたはアーカイブしながら、最近の操作にメモリ内バッファの両方を使用することは完全に許容されます。
It is outside the scope of this document to specify the implementation details (i.e., size, throughput, data protection, etc.) for the physical storage of the I2RS log file. In terms of data retention, attention should be paid to the length of time that the I2RS trace log data is kept when that data contains security- or privacy-sensitive attributes. The longer this data is retained, the higher the impact if it were to be leaked. It is also possible that legislation may impose some additional requirements on the minimum and/or maximum durations for which some kinds of data may be retained.
I2RSログファイルの物理ストレージの実装の詳細（サイズ、スループット、データ保護など）を指定することは、このドキュメントの範囲外です。データの保持に関しては、I2RSトレースログデータにセキュリティまたはプライバシーに敏感な属性が含まれている場合に、そのデータが保持される期間に注意する必要があります。このデータが保持される期間が長いほど、漏洩した場合の影響が大きくなります。また、法律によっては、特定の種類のデータを保持できる最小期間および/または最大期間に追加の要件が課される場合もあります。
In order to prevent the exhaustion of resources on the I2RS agent or its associated network device, it is RECOMMENDED that the I2RS agent implements trace log rotation. The details on how this is achieved are left to the implementation and are outside the scope of this document. However, it should be possible to do a file rotation based on either the time or size of the current trace log. If file rollover is supported, multiple archived log files should be supported in order to maximize the troubleshooting and accounting benefits of the trace log.
I2RSエージェントまたは関連するネットワークデバイスのリソースの枯渇を防ぐために、I2RSエージェントがトレースログローテーションを実装することをお勧めします。これがどのように達成されるかの詳細は実装に任されており、このドキュメントの範囲外です。ただし、現在のトレースログの時間またはサイズのいずれかに基づいてファイルローテーションを実行できるはずです。ファイルのロールオーバーがサポートされている場合は、トレースログのトラブルシューティングとアカウンティングの利点を最大限に活用するために、複数のアーカイブログファイルをサポートする必要があります。
Implementors are free to provide their own, proprietary interfaces and develop custom tools to retrieve and display the I2RS trace log. These may include the display of the I2RS trace log as command-line interface (CLI) output. However, a key intention of defining this information model is to establish a vendor-agnostic and consistent interface to collect I2RS trace data. Correspondingly, retrieval of the data should also be made vendor-agnostic.
実装者は、独自の独自のインターフェイスを自由に提供し、I2RSトレースログを取得して表示するカスタムツールを開発できます。これらには、コマンドラインインターフェイス（CLI）出力としてのI2RSトレースログの表示が含まれる場合があります。ただし、この情報モデルを定義する主な目的は、ベンダーに依存しない一貫したインターフェイスを確立して、I2RSトレースデータを収集することです。同様に、データの取得もベンダーに依存しないようにする必要があります。
Despite the fact that export of I2RS trace log information could be an invaluable diagnostic tool for off-box analysis, exporting this information MUST NOT interfere with the ability of the agent to process new incoming operations.
I2RSトレースログ情報のエクスポートがオフボックス分析の非常に貴重な診断ツールになる可能性があるという事実にもかかわらず、この情報のエクスポートは、新しい着信操作を処理するエージェントの機能を妨げてはなりません。
The following three sections describe potential ways the trace log can be accessed. The use of I2RS pub/sub for accessing trace log data is mandatory-to-implement, while others are optional.
次の3つのセクションでは、トレースログにアクセスする方法について説明します。トレースログデータにアクセスするためのI2RS pub / subの使用は必須であり、その他はオプションです。
The syslog protocol [RFC5424] is a standard way of sending event notification messages from a host to a collector. However, the protocol does not define any standard format for storing the messages, and thus implementors of I2RS tracing would be left to define their own format. So, while the data contained within the syslog message would adhere to this information model, and may be consumable by a human operator, it would not be easily parseable by a machine. Syslog MAY be employed as a means of retrieving or disseminating the I2RS trace log contents.
syslogプロトコル[RFC5424]は、イベント通知メッセージをホストからコレクターに送信する標準的な方法です。ただし、プロトコルはメッセージを格納するための標準形式を定義していないため、I2RSトレースの実装者は独自の形式を定義する必要があります。そのため、syslogメッセージに含まれるデータはこの情報モデルに準拠し、人間のオペレーターが使用できる可能性がありますが、マシンでは簡単に解析できません。 Syslogは、I2RSトレースログの内容を取得または配布する手段として使用できます。
If syslog is used for trace log retrieval, then existing logging infrastructure and capabilities of syslog [RFC5424] should be leveraged without the need to define or extend existing formats. That is, the various fields described in Section 5.2 SHOULD be modeled and encoded as Structured Data Elements (referred to as "SD-ELEMENT"), as described in Section 6.3.1 of [RFC5424].
トレースログの取得にsyslogを使用する場合、既存のロギングインフラストラクチャとsyslog [RFC5424]の機能を利用して、既存のフォーマットを定義または拡張する必要はありません。つまり、セクション5.2で説明されているさまざまなフィールドは、[RFC5424]のセクション6.3.1で説明されているように、構造化データ要素（「SD-ELEMENT」と呼ばれる）としてモデル化およびエンコードする必要があります（SHOULD）。
Section 7.7 of the I2RS architecture [RFC7921] defines a mechanism for information collection. The information collected includes obtaining a snapshot of a large amount of data from the network element. It is the intent of I2RS to make this data available in an implementor-agnostic fashion. Therefore, the I2RS trace log SHOULD be made available via the I2RS information collection mechanism either as a single snapshot or via a subscription stream.
I2RSアーキテクチャ[RFC7921]のセクション7.7は、情報収集のメカニズムを定義しています。収集される情報には、ネットワーク要素から大量のデータのスナップショットを取得することが含まれます。 I2RSの目的は、このデータを実装者にとらわれない方法で利用できるようにすることです。したがって、I2RSトレースログは、I2RS情報収集メカニズムを介して、単一のスナップショットとして、またはサブスクリプションストリームを介して利用可能にする必要があります（SHOULD）。
Section 7.6 of the I2RS architecture [RFC7921] goes on to describe notification mechanisms for a feed of changes happening within the I2RS layer. Specifically, the requirements for a publish-subscribe system for I2RS are defined in [RFC7923]. I2RS agents MUST support publishing I2RS trace log information to that feed as described in [RFC7923]. Subscribers would then receive a live stream of I2RS interactions in trace log format and could flexibly choose to do a number of things with the log messages. For example, the subscribers could log the messages to a datastore, aggregate, and summarize interactions from a single client, etc. The full range of potential activities is virtually limitless and the details of how they are performed are outside the scope of this document, however.
I2RSアーキテクチャ[RFC7921]のセクション7.6では、I2RSレイヤー内で発生する変更のフィードの通知メカニズムについて説明します。具体的には、I2RSのパブリッシュ/サブスクライブシステムの要件は、[RFC7923]で定義されています。 [RFC7923]で説明されているように、I2RSエージェントはそのフィードへのI2RSトレースログ情報の公開をサポートする必要があります。その後、サブスクライバーは、I2RS対話のライブストリームをトレースログ形式で受信し、ログメッセージを使用してさまざまな処理を柔軟に選択できます。たとえば、サブスクライバーは、データストアにメッセージを記録し、単一のクライアントからの相互作用を集約して要約することができます。潜在的なアクティビティの全範囲は事実上無制限であり、それらが実行される方法の詳細はこのドキュメントの範囲外です。しかしながら。
The I2RS trace log, like any log file, reveals the state of the entity producing it as well as the identifying information elements and detailed interactions of the system containing it. The information model described in this document does not itself introduce any security issues, but it does define the set of attributes that make up an I2RS log file. These attributes may contain sensitive information, and thus should adhere to the security, privacy, and permission policies of the organization making use of the I2RS log file.
I2RSトレースログは、他のログファイルと同様に、それを生成しているエンティティの状態、およびそれを含むシステムの識別情報要素と詳細な相互作用を明らかにします。このドキュメントで説明する情報モデル自体はセキュリティの問題を引き起こしませんが、I2RSログファイルを構成する一連の属性を定義します。これらの属性には機密情報が含まれる可能性があるため、I2RSログファイルを使用する組織のセキュリティ、プライバシー、およびアクセス許可のポリシーに準拠する必要があります。
It is outside the scope of this document to specify how to protect the stored log file, but it is expected that adequate precautions and security best practices such as disk encryption, appropriately restrictive file/directory permissions, suitable hardening and physical security of logging entities, mutual authentication, transport encryption, channel confidentiality, and channel integrity if transferring log files. Additionally, the potentially sensitive information contained in a log file SHOULD be adequately anonymized or obfuscated by operators to ensure its privacy.
保存されたログファイルを保護する方法を指定することはこのドキュメントの範囲外ですが、ディスクの暗号化、適切に制限されたファイル/ディレクトリのアクセス許可、適切な強化とロギングエンティティの物理的セキュリティなどの適切な予防策とセキュリティのベストプラクティスが期待されます。相互認証、トランスポート暗号化、チャネルの機密性、およびログファイルを転送する場合のチャネルの整合性。さらに、ログファイルに含まれる潜在的な機密情報は、プライバシーを確保するために、オペレーターによって適切に匿名化または難読化される必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<http://www.rfc-editor.org/info/rfc3339 >。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、DOI 10.17487 / RFC5424、2009年3月、<http://www.rfc-editor.org/info/rfc5424>。
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://www.rfc-editor.org/info/rfc7921>.
[RFC7921] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「An Routing for the Interface to the Routing System」、RFC 7921、DOI 10.17487 / RFC7921、2016年6月、<http://www.rfc-editor.org/info/rfc7921>。
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016.
[RFC7923] Voit、E.、Clemm、A。、およびA. Gonzalez Prieto、「YANG Datastoresへのサブスクリプションの要件」、RFC 7923、DOI 10.17487 / RFC7923、2016年6月。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、DOI 10.17487 / RFC6536、2012年3月、<http://www.rfc-editor.org/info/ rfc6536>。
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7923, DOI 10.17487/RFC7923, June 2016, <http://www.rfc-editor.org/info/rfc7920>.
[RFC7920] Atlas、A.、Ed。、Nadeau、T.、Ed。、and D. Ward、 "Problem Statement for the Interface to the Routing System"、RFC 7923、DOI 10.17487 / RFC7923、June 2016、<http： //www.rfc-editor.org/info/rfc7920>。
[RIBINFO] Bahadur, N., Ed., Kini, S., Ed., and J. Medved, "Routing Information Base Info Model", Work in Progress, draft-ietf-i2rs-rib-info-model-08, October 2015.
[RIBINFO] Bahadur、N.、Ed。、Kini、S.、Ed。、およびJ. Medved、「Routing Information Base Info Model」、Work in Progress、draft-ietf-i2rs-rib-info-model-08、 2015年10月。
Acknowledgments
謝辞
The authors would like to thank Alia Atlas for her initial feedback and overall support for this work. Additionally, the authors acknowledge Alvaro Retana, Russ White, Matt Birkner, Jeff Haas, Joel Halpern, Dean Bogdanovich, Ignas Bagdonas, Nobo Akiya, Kwang-koog Lee, Sue Hares, Mach Chen, Alex Clemm, Stephen Farrell, Benoit Claise, Les Ginsberg, Suresh Krishnan, and Elwyn Davies for their reviews, contributed text, and suggested improvements to this document.
著者は、彼女の最初のフィードバックとこの作業に対する全体的なサポートを提供してくれたAlia Atlasに感謝します。さらに、著者は、Alvaro Retana、Russ White、Matt Birkner、Jeff Haas、Joel Halpern、Dean Bogdanovich、Ignas Bagdonas、Nobo Akiya、Kwang-koog Lee、Sue Hares、Mach Chen、Alex Clemm、Stephen Farrell、Benoit Claise、Lesを認めますGinsberg、Suresh Krishnan、およびElwyn Daviesのレビュー、テキストの寄稿、およびこのドキュメントへの改善の提案。
Authors' Addresses
著者のアドレス
Joe Clarke Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Joe Clarke Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Phone: +1-919-392-2867
Email: jclarke@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: gsalguei@cisco.com
Carlos Pignataro Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709 United States
Carlos Pignataro Cisco Systems、Inc. 7200-11 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: cpignata@cisco.com