[要約] RFC 9437 は、LISPの制御プレーンにPubSub操作を可能にする拡張を定義しています。これは、LISPにパブリッシュ/サブスクライブ機能を追加することを目的としています。
Internet Engineering Task Force (IETF) A. Rodriguez-Natal
Request for Comments: 9437 Cisco
Category: Standards Track V. Ermagan
ISSN: 2070-1721 Google
A. Cabellos
UPC/BarcelonaTech
S. Barkai
Nexar
M. Boucadair
Orange
August 2023
This document specifies an extension to the Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation.
このドキュメントは、パブリッシュ/サブスクライブ（PUBSUB）操作を有効にするために、ロケーター/ID分離プロトコル（LISP）制御プレーンの拡張機能を指定します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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 https://www.rfc-editor.org/info/rfc9437.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9437で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Scope of Applicability
2. Terminology and Requirements Notation
3. Deployment Requirements
4. Map-Request PubSub Additions
5. Mapping Request Subscribe Procedures
6. Mapping Notification Publish Procedures
7. Security Considerations
7.1. Security Association between ITR and Map-Server
7.2. DDoS Attack Mitigation
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Sample PubSub Deployment Experiences
A.1. PubSub as a Monitoring Tool
A.2. Mitigating Negative Map-Cache Entries
A.3. Improved Mobility Latency
A.4. Enhanced Reachability with Dynamic Redistribution of
Prefixes
A.5. Better Serviceability
Acknowledgments
Contributors
Authors' Addresses
The Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] splits IP addresses into two different namespaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map and encapsulate (a.k.a., map-and-encap) approach that relies on (1) a Mapping System (basically a distributed database) that stores and disseminates EID-RLOC mappings and on (2) LISP Tunnel Routers (xTRs) that encapsulate and decapsulate data packets based on the content of those mappings.
ロケーター/ID分離プロトコル（LISP）[RFC9300] [RFC9301]は、IPアドレスを2つの異なる名前空間に分割します：エンドポイント識別子（EID）とルーティングロケーター（RLOC）。LISPは、EID-RLOCマッピングを保存および普及させるマッピングシステム（基本的に分散データベース）に依存するマップとカプセル化（別名、マップアンドエンク）アプローチを使用します。これらのマッピングのコンテンツに基づいて、データパケットをカプセル化および脱カプセル化します。
Ingress Tunnel Routers (ITRs), Re-encapsulating Tunnel Routers (RTRs), and Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC mapping information from the Mapping System by means of an explicit request message. Section 6.1 of [RFC9301] indicates how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about mapping changes. This document presents a Publish/Subscribe (PubSub) extension in which the Mapping System can notify ITRs/RTRs/PITRs about mapping changes. When this mechanism is used, mapping changes can be notified faster and can be managed in the Mapping System versus the LISP sites.
イングレストンネルルーター（ITR）、トンネルルーター（RTRS）の再カプセル化、およびプロキシイングレストンネルルーター（PITR）は、明示的な要求メッセージを使用してマッピングシステムからEid-to-RLOCマッピング情報を引き出します。[RFC9301]のセクション6.1は、変化のマッピングについてTunnelルーター（ETR）がITRS/RTRS/PITRを伝える方法を示しています。このドキュメントでは、マッピングシステムがマッピングの変更についてITRS/RTRS/PITRに通知できるパブリッシュ/サブスクライブ（PUBSUB）拡張機能を紹介します。このメカニズムを使用すると、マッピングの変更はより速く通知でき、マッピングシステムとLISPサイトで管理できます。
In general, when an ITR/RTR/PITR wants to be notified for mapping changes for a given EID-Prefix, the following main steps occur:
一般に、ITR/RTR/PITRが特定のEID-PREFIXの変更のマッピングのために通知を希望する場合、次の主な手順が発生します。
1. The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with the Notification-Requested bit (N-bit) set and that also includes its xTR-ID and Site-ID.
1. ITR/RTR/PITRは、通知リクエストビット（N-BIT）セットを使用して、そのEID-PrefixのMAP-Requestを構築します。
2. The Map-Request is forwarded to one of the Map-Servers that the EID-Prefix is registered to.
2. Map-Requestは、Eid-Prefixが登録されているマップサーバーの1つに転送されます。
3. The Map-Server creates subscription state for the ITR/RTR/PITR on the EID-Prefix.
3. Map-Serverは、Eid-PrefixでITR/RTR/PITRのサブスクリプション状態を作成します。
4. The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm that the subscription has been created and then waits for an acknowledgement of the notification.
4. Map-Serverは、Map-NotifyをITR/RTR/PITRに送信して、サブスクリプションが作成されたことを確認し、通知の承認を待ちます。
5. The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the successful receipt of the Map-Notify.
5. ITR/RTR/PITRは、Map-Notifyの成功した受領を確認するためにMap-notify-ackを送り返します。
6. When there is a change in the mapping of the EID-Prefix, the Map-Server sends a Map-Notify message to each ITR/RTR/PITR in the subscription list.
6. Eid-Prefixのマッピングに変更がある場合、Map-Serverはサブスクリプションリストの各ITR/RTR/PITRにMap-Notifyメッセージを送信します。
7. Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the received Map-Notify.
7. 各ITR/RTR/PITRは、受信したMAP-Notifyを確認するためにMap-notify-ackを送信します。
This operation is repeated for all EID-Prefixes for which ITRs/RTRs/ PITRs want to be notified. An ITR/RTR/PITR can set the N-bit for several EID-Prefixes within a single Map-Request. Please note that the steps above illustrate only the simplest scenario and that details for this and other scenarios are described later in the document.
この操作は、ITRS/ RTRS/ PITRSに通知を行うすべてのEID-PREFIXで繰り返されます。ITR/RTR/PITRは、単一のMAP-Request内でいくつかのEID-PREFIXSのNビットを設定できます。上記の手順は、最も単純なシナリオのみを示しており、このシナリオやその他のシナリオの詳細については、ドキュメントの後半で説明していることに注意してください。
The reader may refer to [FLOW-EXAMPLES] for sample flows to illustrate the use of the PubSub specification.
読者は、サンプルフローについて[フローエクサムを参照]を参照して、PubSub仕様の使用を説明できます。
The PubSub procedure specified in this document is intended for use in contexts with controlled access to the Map-Server. How a deployment controls access to a Map-Server is deployment specific and therefore out of the scope of this document. However, the Map-Resolvers and Map-Servers need to be configured with the required information to ensure at least the following:
このドキュメントで指定されているPubSub手順は、マップサーバーへのアクセスを制御するコンテキストで使用することを目的としています。展開がマップサーバーへのアクセスを制御する方法は展開固有であるため、このドキュメントの範囲外です。ただし、少なくとも次のことを確実にするために、必要な情報で地図の分解者とマップサーバーを構成する必要があります。
1. Map-Resolvers MUST verify that an xTR is allowed to (1) set the N-bit to 1 and (2) use the xTR-ID, Site-ID, and ITR-RLOCs included in a Map-Request.
1. MAP-Resolversは、XTRが（1）Nビットを1に設定し、（2）Map-Requestに含まれるXtr-ID、Site-ID、およびITR-RLOCを使用することを許可されていることを確認する必要があります。
2. Map-Servers MUST only accept subscription requests from Map-Resolvers that verify Map-Requests as previously described.
2. Map-Serversは、前述のようにMap-Requestsを確認するマップ解像度からのサブスクリプションリクエストのみを受け入れる必要があります。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The document uses the terms defined in Section 3 of [RFC9300].
このドキュメントでは、[RFC9300]のセクション3で定義されている用語を使用します。
In addition to the general assumptions and expectations that [RFC9301] makes for LISP deployments, this document imposes the following deployment requirements:
[RFC9301]がLISPの展開に行う一般的な仮定と期待に加えて、このドキュメントは次の展開要件を課します。
1. A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is assigned to each xTR.
1. 一意の128ビットXTR-ID（プラス64ビットサイトID）識別子が各XTRに割り当てられます。
2. Map-Servers are configured to proxy Map-Replying (i.e., they are solicited to generate and send Map-Reply messages) for the mappings they are serving.
2. マップサーバーは、提供しているマッピングのプロキシマップ応答（つまり、マップ繰り返しメッセージを生成および送信するように求められます）に設定されます。
3. A security association (e.g., a PubSubKey) is required between the ITRs and the Map-Servers (see Section 7.1).
3. セキュリティ協会（たとえば、PubSubkey）がITRとマップサーバーの間に必要です（セクション7.1を参照）。
If a requirement is not met, a subscription cannot be established, and the network will continue operating without this enhancement. The configuration of xTR-IDs and Site-IDs is out of the scope of this document. The reader may refer to [LISP-YANG] for an example of how these identifiers can be provisioned to LISP nodes.
要件が満たされていない場合、サブスクリプションを確立することはできず、この強化なしにネットワークは動作を続けます。XTR-IDとサイトIDの構成は、このドキュメントの範囲外です。読者は、これらの識別子をLISPノードにプロビジョニングする方法の例については、[lisp-yang]を参照できます。
Figure 1 shows the format of the updated Map-Request to support the PubSub functionality. In particular, this document associates a meaning with one of the reserved bits (see Section 8).
図1は、PUBSUB機能をサポートする更新されたMap-Requestの形式を示しています。特に、このドキュメントは、意味を予約済みのビットの1つと関連付けます（セクション8を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |N| Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ xTR-ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Site-ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID
図1：i-bit、n-bit、xtr-id、およびsite-idを備えたマップリクエスト
The following is added to the Map-Request message defined in Section 5.2 of [RFC9301]:
[RFC9301]のセクション5.2で定義されているマップレクエストメッセージに以下が追加されます。
xTR-ID bit (I-bit):
xtr-id bit（ibit）：
This bit is set to 1 to indicate that 128-bit xTR-ID and 64-bit Site-ID fields are present in the Map-Request message. For PubSub operation, an xTR MUST be configured with an xTR-ID and Site-ID, and it MUST set the I-bit to 1 and include its xTR-ID and Site-ID in the Map-Request messages it generates. If the I-bit is set but the Site-ID and/or xTR-ID are not included, a receiver can detect the error because, after processing that last EID-Record, there are no bytes left from processing the message. In this case, the receiver SHOULD log a malformed Map-Request and MUST drop the message.
このビットは、128ビットのXTR-IDおよび64ビットのサイトIDフィールドがMap-Requestメッセージに存在することを示す1に設定されています。PubSub操作の場合、XTRをXTR-IDおよびSite-IDで構成する必要があり、Iビットを1に設定し、生成するMap-RequestメッセージにXTR-IDとSite-IDを含める必要があります。Iビットが設定されているが、サイトIDおよび/またはXTR-IDが含まれていない場合、レシーバーはエラーを検出できます。これは、その最後のEIDレコードを処理した後、メッセージの処理からバイトが残っていないためです。この場合、レシーバーは奇形のマップレクエストを記録し、メッセージをドロップする必要があります。
Notification-Requested bit (N-bit):
通知要求ビット（n-bit）：
The N-bit of an EID-Record is set to 1 to specify that the xTR wants to be notified of updates for that EID-Prefix.
eid-recordのnビットは1に設定されており、xtrにそのeid-prefixの更新を通知したいことを指定します。
xTR-ID field:
XTR-IDフィールド：
If the I-bit is set, this field is added to the Map-Request message as shown in Figure 1, starting right after the final Record in the message (or the Map-Reply Record, if present). The xTR-ID is specified in Section 5.6 of [RFC9301].
Iビットが設定されている場合、このフィールドは、メッセージの最終レコード（または存在する場合はマップ対応レコード）の直後に始まる図1に示すように、マップリクエストメッセージに追加されます。XTR-IDは、[RFC9301]のセクション5.6で指定されています。
Site-ID field:
Site-IDフィールド：
If the I-bit is set, this field is added to the Map-Request message as shown in Figure 1, following the xTR-ID field. The Site-ID is defined in Section 5.6 of [RFC9301].
I-BITが設定されている場合、このフィールドは、図1に示すように、XTR-IDフィールドに従ってマップレクエストメッセージに追加されます。サイトIDは、[RFC9301]のセクション5.6で定義されています。
The xTR subscribes for changes to a given EID-Prefix by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record. The xTR builds a Map-Request according to Section 5.3 of [RFC9301] and also does the following:
XTRは、eid-recordにnビットセットを使用してマッピングシステムにマップリケストを送信することにより、特定のeid-prefixの変更をサブスクライブします。XTRは、[RFC9301]のセクション5.3に従ってマップリケストを構築し、次のことも行います。
1. The xTR MUST set the I-bit to 1 and append its xTR-ID and Site-ID to the Map-Request.
1. XTRはIビットを1に設定し、XTR-IDとSite-IDをMap-Requestに追加する必要があります。
2. The xTR MUST set the N-bit to 1 for the EID-Record to which the xTR wants to subscribe.
2. XTRは、XTRがサブスクライブしたいEid-Recordに対して、Nビットを1に設定する必要があります。
3. If the xTR has a nonce associated with the EID-Prefix, it MUST use this nonce increased by one in the Map-Request. Otherwise, it generates a nonce as described in Section 5.2 of [RFC9301]. It is RECOMMENDED that the xTR use persistent storage to keep nonce state. If the xTR does not have persistent storage and does not have a nonce associated with the EID-Prefix, it MUST reset the nonce by using the procedure described in Section 7.1 to successfully create a new security association with the Map-Server.
3. XTRにEid-Prefixに関連付けられているNonCEがある場合、MAP-RequestでこのNonCEを1つ増加させる必要があります。それ以外の場合、[RFC9301]のセクション5.2で説明されているように、NonCEを生成します。XTRは、非CE状態を維持するために永続的なストレージを使用することをお勧めします。XTRに永続的なストレージがなく、EID-PREFIXに関連付けられたNONCEがない場合、セクション7.1で説明した手順を使用してNONCEをリセットする必要があります。
The Map-Request is forwarded to the appropriate Map-Server through the Mapping System. This document does not assume that a Map-Server is pre-assigned to handle the subscription state for a given xTR. The Map-Server that receives the Map-Request will be the Map-Server responsible for notifying that specific xTR about future mapping changes for the subscribed mapping records.
Map-Requestは、マッピングシステムを介して適切なマップサーバーに転送されます。このドキュメントでは、特定のXTRのサブスクリプション状態を処理するためにMAPサーバーが事前に割り当てられているとは想定していません。Map-Requestを受信するMap-Serverは、サブスクライブマッピングレコードの将来のマッピングの変更に関する特定のXTRを通知する責任を負います。
Upon receipt of the Map-Request, the Map-Server processes it as described in Section 8.3 of [RFC9301]. In addition, unless the xTR is using the procedure described in Section 7.1 to create a new security association, the Map-Server MUST verify that the nonce in the Map-Request is greater than the stored nonce (if any) associated with the xTR-ID (and EID-Prefix, when applicable). Otherwise, the Map-Server MUST silently drop the Map-Request message and SHOULD log the event to record that a replay attack could have occurred. Furthermore, upon processing, for the EID-Record that has the N-bit set to 1, the Map-Server proceeds to add the xTR-ID contained in the Map-Request to the list of xTRs that have requested to be subscribed to that EID-Prefix.
MAP-Requestを受け取ると、MAP-Serverは[RFC9301]のセクション8.3で説明されているように処理します。さらに、XTRがセクション7.1で説明した手順を使用して新しいセキュリティ協会を作成している場合を除き、MAP-SERVERは、MAP-RequestのNonCEがXTRに関連付けられた保存されたNonCE（もしあれば）よりも大きいことを確認する必要があります。id（およびeid-prefix、該当する場合）。それ以外の場合、Map-Serverは静かにMap-Requestメッセージをドロップする必要があり、イベントをログにして、リプレイ攻撃が発生した可能性があることを記録する必要があります。さらに、処理すると、Nビットが1に設定されているEid-Recordの場合、Map-ServerはMap-Requestに含まれるXTR-IDを追加して、それにサブスクライブすることを要求したXTRのリストに追加します。Eid-Prefix。
If an xTR-ID is successfully added to the list of subscribers for an EID-Prefix, the Map-Server MUST extract the nonce and ITR-RLOCs present in the Map-Request and store the association between the EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state that is already present regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be overwritten. When the LISP deployment has a single Map-Server, the Map-Server can be configured to keep a single nonce per xTR-ID for all EID-Prefixes (when used, this option MUST be enabled at the Map-Server and all xTRs).
XTR-IDがEid-Prefixのサブスクライバーのリストに正常に追加された場合、MAP-ServerはMAP-Requestに存在するNonCEとITR-RLOCを抽出し、Eid-Prefix、Xtr-IDの間の関連を保存する必要があります。、itr-rlocs、およびnonce。同じXTR-IDのITR-RLOCSおよび/またはNONCEに関してすでに存在している状態を上書きする必要があります。LISPの展開に単一のマップサーバーがある場合、MAPサーバーを構成することができます。すべてのEID-PREFIXESのXTR-IDごとに単一のNonCEを保持することができます（使用する場合、このオプションはMap-ServerおよびすべてのXTRで有効にする必要があります）。
If the xTR-ID is added to the list, the Map-Server MUST send a Map-Notify message back to the xTR to acknowledge the successful subscription. The Map-Server builds the Map-Notify according to Sections 5.5 and 5.7 of [RFC9301] with the following considerations:
XTR-IDがリストに追加された場合、Map-Serverは、サブスクリプションの成功を確認するためにMap-NotifyメッセージをXTRに送り返す必要があります。マップサーバーは、[RFC9301]のセクション5.5および5.7に従って、次の考慮事項でMap-Notifyを構築します。
1. The Map-Server MUST use the nonce from the Map-Request as the nonce for the Map-Notify.
1. Map-Serverは、Map-NotifyのNONCEとしてMap-RequestのNonceを使用する必要があります。
2. The Map-Server MUST use its security association with the xTR (Section 7.1) to sign the authentication data of the Map-Notify. The xTR MUST use the security association to verify the received authentication data.
2. Map-Serverは、XTR（セクション7.1）とのセキュリティ協会を使用して、Map-Notifyの認証データに署名する必要があります。XTRは、セキュリティ協会を使用して、受信した認証データを確認する必要があります。
3. The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs received in the Map-Request (which one is implementation specific).
3. Map-Serverは、Map-Requestで受信したITR-RLOCの1つにMap-Notifyを送信する必要があります（実装固有）。
As a reminder, the initial transmission and retransmission of Map-Notify messages by a Map-Server follow the procedure specified in Section 5.7 of [RFC9301]. Some state changes may trigger an overload that would impact, e.g., the outbound capacity of a Map-Server. A similar problem may be experienced when a large number of state entries are simultaneously updated. To prevent such phenomena, Map-Servers SHOULD be configured with policies to control the maximum number of subscriptions and also the pace of Map-Notify messages. For example, the Map-Server may be instructed to limit the resources that are dedicated to unsolicited Map-Notify messages to a small fraction (e.g., less than 10%) of its overall processing and forwarding capacity. The exact details to characterize such policies are deployment and implementation specific. Likewise, this document does not specify which notifications take precedence when these policies are enforced.
リマインダーとして、[RFC9301]のセクション5.7で指定された手順に従ってください。一部の状態の変更により、マップサーバーのアウトバウンド容量など、影響を与える過負荷がトリガーされる場合があります。多数の州のエントリが同時に更新されると、同様の問題が発生する場合があります。このような現象を防ぐには、マップサーバーをポリシーで構成して、最大数のサブスクリプション数とMap-Notifyメッセージのペースを制御する必要があります。たとえば、マップサーバーは、全体的な処理および転送容量の少量（たとえば、10％未満）に未承諾のMap-Notifyメッセージに専念するリソースを制限するように指示される場合があります。このようなポリシーを特徴付ける正確な詳細は、展開と実装固有です。同様に、このドキュメントでは、これらのポリシーが施行されたときにどの通知が優先されるかを指定していません。
When the xTR receives a Map-Notify with a nonce that matches one in the list of outstanding Map-Request messages sent with an N-bit set, it knows that the Map-Notify is to acknowledge a successful subscription. The xTR processes this Map-Notify, as described in Section 5.7 of [RFC9301] and MUST use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. As a reminder, following Section 5.7 of [RFC9301], the xTR has to send a Map-Notify-Ack back to the Map-Server. If the Map-Server does not receive the Map-Notify-Ack after exhausting the Map-Notify retransmissions described in Section 5.7 of [RFC9301], the Map-Server can remove the subscription state. If the Map-Server removes the subscription state, and absent explicit policy, it SHOULD notify the xTR by sending a single Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0) and ACT bits set to 5 "Drop/Auth-Failure". It is OPTIONAL for the xTR to update its Map-Cache entry for the EID-Prefix (if any) based on this Map-Notify. This message is specifically useful for cases where Map-Notifies are successfully received by an xTR, but the corresponding Map-Notify-Acks are lost when forwarded to the Map-Server. xTR implementations can use this signal to try to reinstall their subscription state instead of maintaining stale mappings.
XTRが、n-bitセットで送信された未解決のMap-Requestメッセージのリストのリストに一致するNonceを使用してMap-notifyを受信すると、Map-notifyがサブスクリプションの成功を認めることを知っています。XTRは、[RFC9301]のセクション5.7で説明されているように、このMAP-NOTIFYを処理し、MAP-Notifyを使用して、返されたEID-PREFIXとRLOC-SETをマップキャッシュに入力する必要があります。リマインダーとして、[RFC9301]のセクション5.7に従って、XTRはMap-notify-ackをマップサーバーに戻す必要があります。[RFC9301]のセクション5.7で説明されているMap-Notifyの再送信を使い果たした後、Map-ServerがMap-Notify-CACKを受信しない場合、MAPServerはサブスクリプション状態を削除できます。マップサーバーがサブスクリプション状態を削除し、明示的なポリシーがない場合は、同じノンセとloc-count = 0（およびloc-afi = 0）で単一のmap-notifyを送信してxtrに通知する必要があります。5 "ドロップ/オーチュエル - 故障"に。XTRがこのMAP-Notifyに基づいてEid-Prefix（もしあれば）のマップキャッシュエントリを更新することはオプションです。このメッセージは、Map-NotifieがXTRによって正常に受信されますが、MAP-SERVERに転送されると対応するMAP-Notify-CACKが失われる場合に特に役立ちます。XTRの実装は、この信号を使用して、古いマッピングを維持する代わりに、サブスクリプション状態を再インストールしようとすることができます。
The subscription of an xTR-ID may fail for a number of reasons. For example, it fails because of local configuration policies (such as accept and drop lists of subscribers), because the Map-Server has exhausted the resources to dedicate to the subscription of that EID-Prefix (e.g., the number of subscribers excess the capacity of the Map-Server), or because the xTR was not successful tried but was not successful in establishing a new security association (Section 7.1).
XTR-IDのサブスクリプションは、いくつかの理由で失敗する場合があります。たとえば、MAPサーバーがそのEid-Prefixのサブスクリプションに専念するためのリソースを使い果たしたため、ローカル構成ポリシー（サブスクライバーの受け入れおよびドロップリストなど）のために失敗します（例えば、サブスクライバーの数は容量を超えています。Map-Serverの）、またはXTRが成功しなかったために試行されたが、新しいセキュリティ協会の確立に成功しなかったため（セクション7.1）。
If the subscription request fails, the Map-Server sends a Map-Reply to the originator of the Map-Request, as described in Section 8.3 of [RFC9301], with the following considerations:
サブスクリプションリクエストが失敗した場合、MAP-SERVERは、[RFC9301]のセクション8.3で説明されているように、MAP-Requestのオリジネーターにマップ応答を送信します。
* If the subscription request fails due to policy (e.g., for explicitly configured subscriptions, as described later in this section), the Map-Server MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 4 "Drop/Policy-Denied".
* サブスクリプション要求がポリシーのために失敗した場合（例：このセクションで説明したように、明示的に構成されたサブスクリプションの場合）、Map-Serverは、マップリクエストにネガティブマップリプリー（loc-count = 0およびloc--で応答する必要があります。AFI = 0）ACTビットが4「ドロップ/ポリシー除去」に設定されています。
* If the subscription request fails due to authentication (e.g., when a new security association is being established, as described in Section 7.1), the Map-Server MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 5 "Drop/Auth-Failure".
* 認証のためにサブスクリプションリクエストが失敗した場合（たとえば、セクション7.1で説明されているように、新しいセキュリティ協会が確立されている場合）、Map-Serverはネガティブマップリクスでマップリケストに応答する必要があります（loc-count = 0およびloc-afi = 0）ACTビットが5「ドロップ/認証ファイア」に設定されています。
* If the subscription request fails due to any other reason, the Map-Server MUST follow Section 8.3 of [RFC9301] with no changes.
* 他の理由によりサブスクリプション要求が失敗した場合、MAPサーバーは、変更なしで[RFC9301]のセクション8.3に従う必要があります。
The xTR processes any Map-Reply or Negative Map-Reply as specified in Section 8.1 of [RFC9301], with the following considerations: if the xTR receives a Negative Map-Reply with ACT bits set to 4 "Drop/ Policy-Denied" or 5 "Drop/Auth-Failure" as a response to a subscription request, it is OPTIONAL for the xTR to update its Map-Cache entry for the EID-Prefix (if any). If the subscription request fails (for whichever reason), it is up to the implementation of the xTR to try to subscribe again.
XTRは、[RFC9301]のセクション8.1で指定されているように、マップ応答または負のマップ応答を処理します。次の考慮事項：XTRがACTビットが4 "ドロップ/ポリシーデニード"に設定されたネガティブマップ応答を受信するか、または5「ドロップ/認証 - ファイア」サブスクリプションリクエストへの応答として、XTRがEid-Prefixのマップキャッシュエントリを更新することはオプションです（もしあれば）。サブスクリプションリクエストが（いずれかの理由で）失敗した場合、再度サブスクライブしようとするのはXTRの実装次第です。
If the Map-Server receives a subscription request for an EID-Prefix not present in the mapping database, it SHOULD follow the same logic described in Section 8.4 of [RFC9301] and create a temporary subscription state for the xTR-ID to the least specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure. Alternatively, the Map-Server can determine that such a subscription request fails and send a Negative Map-Reply following Section 8.3 of [RFC9301]. In both cases, the TTL of the temporary subscription state or the Negative Map-Reply SHOULD be configurable, with a value of 15 minutes being RECOMMENDED.
マップサーバーがマッピングデータベースに存在しないEID-Prefixのサブスクリプションリクエストを受信した場合、[RFC9301]のセクション8.4で説明されている同じロジックに従い、XTR-IDの一時サブスクリプション状態を作成してください。両方とも元のクエリと一致し、LISP対応インフラストラクチャに存在することが知られているEid-Prefixと一致しないプレフィックス。あるいは、MAPサーバーは、このようなサブスクリプション要求が失敗することを判断し、[RFC9301]のセクション8.3に従ってネガティブマップ応答を送信することができます。どちらの場合も、一時的なサブスクリプション状態のTTLまたはネガティブマップ応答が設定可能であり、15分の値が推奨されます。
The subscription state can also be created explicitly by configuration at the Map-Server (possible when a pre-shared security association exists, see Section 7) using a variety of means that are outside the scope of this document. If there is no nonce that can be used for the explicit subscription state at the time the explicit subscription is configured (e.g., from a different subscription already established with the same xTR when a single nonce is kept per xTR-ID), then both the xTR and Map-Server MUST be configured with the initial nonce. RECOMMENDED to have a configuration option to enable (or disable) the xTR to accept publication information for EID-Prefixes that the xTR did not explicitly subscribe to. By default, the xTR is allowed to modify explicitly configured subscription state following the procedures described in this section; however, this MAY be disabled at the Map-Server via configuration. If the Map-Server is instructed to not allow xTRs to modify explicitly configured subscriptions, and an xTR tries to do so, this triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described earlier in this section.
サブスクリプション状態は、このドキュメントの範囲外のさまざまな手段を使用して、Map-Serverでの構成（事前共有セキュリティ協会が存在する場合、セクション7を参照）で明示的に作成することもできます。明示的なサブスクリプション状態に使用できるNonCEがない場合、明示的なサブスクリプションが構成されています（たとえば、単一の非CEがXTR-IDごとに保持されているときに同じXTRですでに確立されている別のサブスクリプションから）、両方の両方です。XTRおよびMAP-SERVERは、最初のNONCEで構成する必要があります。XTRが明示的にサブスクライブしなかったEid-Prefixesの公開情報を受け入れるためにXTRを有効に（または無効）する構成オプションを持つことをお勧めします。デフォルトでは、XTRは、このセクションで説明した手順に従って、明示的に構成されたサブスクリプション状態を変更することができます。ただし、これは構成を介してマップサーバーで無効になる場合があります。Map-ServerがXTRが明示的に構成されたサブスクリプションを変更しないように指示され、XTRがそうしようとする場合、これにより、ACTビットが4 "ドロップ/ポリシーデニー"に設定されたACTビットが前述のように、マイナスマップ応答をトリガーします。セクション。
The following specifies the procedure to remove a subscription:
以下は、サブスクリプションを削除する手順を指定します。
* If a valid Map-Request with the N-bit set to 1 only has one ITR-RLOC with AFI = 0 (i.e., Unknown Address), the Map-Server MUST remove the subscription state for that xTR-ID (unless this is disabled via configuration, see previous paragraph).
* n-bitセットを1に設定した有効なMAP-RequestがAFI = 0（つまり、不明なアドレス）を持つITR-RLOCが1つしかない場合、MAPServerはそのXTR-IDのサブスクリプション状態を削除する必要があります（これが無効になっていない限り構成を介して、前の段落を参照してください）。
* If the subscription state is removed, the Map-Server MUST send a Map-Notify to the source RLOC of the Map-Request.
* サブスクリプション状態が削除された場合、Map-ServerはMap-RequestのソースRLOCにMap-Notifyを送信する必要があります。
* If the subscription removal fails due to configuration, this triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described earlier in this section; the Map-Server sends the Negative Map-Reply to the source RLOC of the Map-Request in this case.
* 構成によりサブスクリプションの削除が失敗した場合、このセクションで前述したように、ACTビットが4 "ドロップ/ポリシー除去された"に設定されたマイナスマップ繰り返しをトリガーします。マップサーバーは、この場合、マップレクエストのソースRLOCにネガティブマップを送信します。
* Removing subscription state at the Map-Server can lead to replay attacks. To soften this, the Map-Server SHOULD keep the last nonce seen per xTR-ID (and EID-Prefix, when applicable).
* マップサーバーでサブスクリプション状態を削除すると、リプレイ攻撃につながる可能性があります。これを和らげるために、マップサーバーは、Xtr-IDごとに見られた最後の非CEを保持する必要があります（および該当する場合はEid-Prefix）。
* If the Map-Server does not keep the last nonces seen, then the Map-Server MUST require the xTRs to subscribe using the procedure described in Section 7.1 to create a new security association with the Map-Server.
* Map-Serverが最後のNoncesを見ていない場合、Map Serverは、セクション7.1で説明されている手順を使用してXTRを購読するように要求する必要があります。
If the Map-Server receives a Map-Request asking to remove a subscription for an EID-Prefix without subscription state for that xTR-ID and the EID-Prefix is covered by a less-specific EID-Prefix for which subscription state exists for the xTR-ID, the Map-Server SHOULD stop publishing updates about this more-specific EID-Prefix to that xTR until the xTR subscribes to the more-specific EID-Prefix. The same considerations regarding authentication, integrity protection, and nonce checks, which are described in this section and Section 7 for Map-Requests used to update subscription state, apply for Map-Requests used to remove subscription state.
マップサーバーがそのXTR-IDのサブスクリプション状態なしでEID-PREFIXのサブスクリプションを削除するように要求するMAP-REQUESTを受信し、EID-PREFIXは、サブスクリプション状態が存在するより固有のEID-PREFIXでカバーされている場合XTR-ID、Map-Serverは、XTRがより特定のEID-Prefixに登録するまで、このXTRのこの固有のEid-Prefixに関する更新の公開を停止する必要があります。サブスクリプション状態を更新するために使用されるMAP-Requestsについては、このセクションで説明されている認証、整合性保護、およびNonCEチェックに関する同じ考慮事項は、サブスクリプション状態を削除するために使用されるMap-Requestを適用します。
When an EID-Prefix is removed from the Map-Server (either when explicitly withdrawn or when its TTL expires), the Map-Server notifies its subscribers (if any) via a Map-Notify with TTL equal to 0.
Eid-PrefixがMAPサーバーから削除された場合（明示的に撤回したときまたはTTLの有効期限が切れたとき）、MAP-SERVERは、TTLが0に等しいMAP-Notifyを介してサブスクライバー（存在する場合）に通知します。
The publish procedure is implemented via Map-Notify messages that the Map-Server sends to xTRs. The xTRs acknowledge the receipt of Map-Notifies by sending Map-Notify-Ack messages back to the Map-Server. The complete mechanism works as follows:
パブリッシュ手順は、Map-ServerがXTRSに送信するMap-Notifyメッセージを介して実装されます。XTRSは、Map-notify-ackメッセージをMap-Serverに送り返すことにより、Map-Notifieの受領を認めます。完全なメカニズムは次のように機能します。
When a mapping stored in a Map-Server is updated (e.g., via a Map-Register from an ETR), the Map-Server MUST notify the subscribers of that mapping via sending Map-Notify messages with the most up to date mapping information. If subscription state in the Map-Server exists for a less-specific EID-Prefix and a more-specific EID-Prefix is updated, then the Map-Notify is sent with the more-specific EID-Prefix mapping to the subscribers of the less-specific EID-Prefix mapping. The Map-Notify message sent to each of the subscribers as a result of an update event follows the encoding and logic defined in Section 5.7 of [RFC9301] for Map-Notify, except for the following:
マップサーバーに保存されているマッピングが更新された場合（たとえば、ETRからのマップレジスターを介して）、Map-Serverは、最新のマッピング情報を持つMap-Notifyメッセージを送信することでそのマッピングをサブスクライバーに通知する必要があります。MAP-SERVERのサブスクリプション状態が、より特定のEID-PREFIXのために存在し、より特異的なEID-PREFIXが更新された場合、MAP-Notifyは、より特異的なEID-PREFIXマッピングで送信されます。 - 特異的なeid-prefixマッピング。更新イベントの結果として各サブスクライバーに送信されたMap-Notifyメッセージは、以下を除き、MAP-Notifyの[RFC9301]のセクション5.7で定義されているエンコードとロジックに従います。
1. The Map-Notify MUST be sent to one of the ITR-RLOCs associated with the xTR-ID of the subscriber (which one is implementation specific).
1. Map-notifyは、サブスクライバーのXTR-IDに関連付けられたITR-RLOCの1つに送信する必要があります（実装固有）。
2. The Map-Server increments the nonce by one every time it sends a Map-Notify as publication to an xTR-ID for a particular EID-Prefix.
2. Map-Serverは、特定のEid-PrefixのXTR-IDに出版物としてMap-Notifyを送信するたびに、Nonceを1つずつ増加させます。
3. The Map-Server MUST use its security association with the xTR to compute the authentication data of the Map-Notify.
3. Map-Serverは、XTRとのセキュリティ関連を使用して、Map-Notifyの認証データを計算する必要があります。
When the xTR receives a Map-Notify with an EID that is not local to the xTR, the xTR knows that the Map-Notify is to update an entry on its Map-Cache. The xTR MUST keep track of the last nonce seen in a Map-Notify received as a publication from the Map-Server for the EID-Prefix. When the LISP deployment has a single Map-Server, the xTR can be configured to keep track of a single nonce for all EID-Prefixes (when used, this option MUST be enabled at the Map-Server and all xTRs). If a Map-Notify that is received as a publication has a nonce value that is not greater than the saved nonce, the xTR drops the Map-Notify message and logs the fact a replay attack could have occurred. The same considerations discussed in Section 5.6 of [RFC9301] regarding Map-Register nonces apply here for Map-Notify nonces.
XTRがXTRにローカルではないEIDを使用してMap-Notifyを受信すると、XTRはMap-Notifyがマップキャッシュのエントリを更新することを知っています。XTRは、Eid-PrefixのMap-Serverからの出版物として受信されたMap-Notifyで見られる最後の非CEを追跡する必要があります。LISPの展開に単一のマップサーバーがある場合、すべてのEID-PREFIXSの単一のNonCEを追跡するようにXTRを構成できます（使用する場合、このオプションはMap-ServerおよびすべてのXTRで有効にする必要があります）。出版物として受信されたMap-notifyに、保存されたNonceよりも大きくないNonce値がある場合、XTRはMap-Notifyメッセージをドロップし、リプレイ攻撃が発生した可能性のある事実を記録します。[RFC9301]のセクション5.6で議論されている同じ考慮事項は、Map-Notify Noncesにここに適用されます。
The xTR processes the received Map-Notify as specified in Section 5.7 of [RFC9301], with the following considerations:
XTRは、[RFC9301]のセクション5.7で指定されているように受信したMap-Notifyを処理します。
* The xTR MUST use its security association with the Map-Server (Section 7.1) to validate the authentication data on the Map-Notify.
* XTRは、Map-server（セクション7.1）とのセキュリティ関連を使用して、Map-notifyの認証データを検証する必要があります。
* The xTR MUST use the mapping information carried in the Map-Notify to update its internal Map-Cache.
* XTRは、Map-notifyにあるマッピング情報を使用して、内部マップキャッシュを更新する必要があります。
* If after following Section 5.7 of [RFC9301] regarding retransmission of Map-Notify messages, the Map-Server has not received the Map-Notify-Ack, it can try sending the Map-Notify to a different ITR-RLOC for that xTR-ID.
* Map-Notifyメッセージの再送信に関して[RFC9301]のセクション5.7に従って次のとおり、Map-ServerはMap-Notify-CACKを受信していない場合、そのXtr-IDの別のITR-RLOCにMap-Notifyを送信してみてください。。
* If the Map-Server tries all the ITR-RLOCs without receiving a response, it may stop trying to send the Map-Notify.
* マップサーバーが応答を受信せずにすべてのITR-rlocを試している場合、Map-notifyの送信を停止する可能性があります。
Generic security considerations related to LISP control messages are discussed in Section 9 of [RFC9301].
LISP制御メッセージに関連する一般的なセキュリティ上の考慮事項については、[RFC9301]のセクション9で説明します。
In the particular case of PubSub, cache poisoning via malicious Map-Notify messages is avoided by the use of nonce and the security association between the ITRs and the Map-Servers.
PubSubの特定のケースでは、悪意のあるMap-Notifyメッセージを介したキャッシュ中毒は、ITRSとMAPサーバーとの間のセキュリティ関連の使用によって回避されます。
It is RECOMMENDED to follow guidance from the last paragraph of Section 9 of [RFC9301] to ensure integrity protection of Map-Request messages (e.g., to prevent xTR-ID hijacking).
[RFC9301]のセクション9の最後の段落からのガイダンスに従って、MAP-Requestメッセージの整合性保護を確保することをお勧めします（XTR-IDハイジャックを防ぐため）。
Since Map-Notifies from the Map-Server to the ITR need to be authenticated, there is a need for a soft-state or hard-state security association (e.g., a PubSubKey) between the ITRs and the Map-Servers. For some controlled deployments, it might be possible to have a shared PubSubKey (or set of keys) between the ITRs and the Map-Servers. However, if pre-shared keys are not used in the deployment, LISP Security (LISP-SEC) [RFC9303] can be used as follows to create a security association between the ITR and the Map-Server.
Map-serverからITRに認証される必要があるため、ITRSとMap-Serversの間にソフトステートまたはハードステートセキュリティ協会（Pubsubkeyなど）が必要です。一部の制御された展開では、ITRとマップサーバーの間に共有されたpubsubkey（またはキーのセット）を持つことが可能かもしれません。ただし、展開で事前に共有キーが使用されていない場合、LISPセキュリティ（LISP-SEC）[RFC9303]を次のように使用して、ITRとMAPサーバーの間にセキュリティ関連を作成できます。
First, when the ITR is sending a Map-Request with the N-bit set as described in Section 5, the ITR also performs the steps described in Section 6.4 of [RFC9303]. The ITR can then generate a PubSubKey by deriving a key from the One-Time Key (OTK) and Map-Request's nonce as follows: PubSubKey = KDF(OTK + nonce), where KDF is the Key Derivation Function indicated by the OTK Wrapping ID. If the OTK Wrapping ID equals NULL-KEY-WRAP-128, then the PubSubKey is the OTK. Note that, as opposed to the pre-shared PubSubKey, this generated PubSubKey is different per EID-Prefix to which an ITR subscribes (since the ITR will use a different OTK per Map-Request).
まず、セクション5で説明されているように、ITRがNビットセットを使用してMAP-Requestを送信している場合、ITRは[RFC9303]のセクション6.4で説明されている手順も実行します。ITRは、次のように、1回限りのキー（OTK）とMap-RequestのNonceからキーを導き出すことでPubSubkeyを生成できます。PubSubkey= KDF（OTK Nonce）。KDFはOTKラッピングIDで示されるキー導入関数です。OTKラッピングIDがnull-key-wrap-128に等しい場合、pubsubkeyはOTKです。事前に共有されたPubSubkeyとは対照的に、この生成されたPubSubkeyは、ITRがサブスクライブするEid-Prefixごとに異なることに注意してください（ITRはMap-Requestごとに異なるOTKを使用するため）。
When the Map-Server receives the Map-Request, it follows the procedure specified in Section 5 with the following considerations: the Map-Server MUST verify that the OTK has not been used before. If the Map-Server verifies the OTK and cannot determine that the OTK has not been used before, the subscription request fails due to authentication, which triggers a Negative Map-Reply with ACT bits set to 5 "Drop/Auth-Failure", as described in Section 5. The xTR might try again with a different OTK upon receipt of this Negative Map-Reply. Note that a Map-Server implementation may decide not to keep track of all past OTKs and instead use some form of hash. In that case, hash collisions are handled as if the OTK has been reused. Such an implementation needs to balance the hash length with the rate of collisions expected for the particular deployment; this is implementation specific. If the Map-Server has to reply with a Map-Reply for any other reason (e.g., if PubSub is not supported or a subscription is not accepted), then it follows the normal LISP-SEC procedure described in Section 5.7 of [RFC9303]. No PubSubKey, security association, or subscription state is created when the Map-Server responds with any Map-Reply message.
Map-ServerがMap-Requestを受信すると、セクション5で指定された手順に従います。次の考慮事項：Map-Serverは、OTKが以前に使用されていないことを確認する必要があります。Map-ServerがOTKを検証し、OTKが以前に使用されていないことを判断できない場合、サブスクリプション要求は認証のために失敗します。セクション5で説明されています。XTRは、このネガティブマップ応答を受け取ったときに別のOTKで再試行する場合があります。マップサーバーの実装は、過去のすべてのOTKを追跡せず、代わりに何らかの形のハッシュを使用することを決定する場合があることに注意してください。その場合、Hash衝突は、OTKが再利用されているかのように処理されます。このような実装は、ハッシュの長さと特定の展開に期待される衝突速度のバランスをとる必要があります。これは実装固有です。Map-Serverが他の理由でMAP-Replyで返信する必要がある場合（たとえば、PubSubがサポートされていない場合、またはサブスクリプションが受け入れられない場合）、[RFC9303]のセクション5.7で説明されている通常のLISP-SEC手順に従います。。PubSubkey、セキュリティ協会、またはサブスクリプション状態は、マップサーバーがどのマップ繰り返しメッセージで応答したときに作成されません。
Otherwise, if the Map-Server has to reply with a Map-Notify (e.g., due to the subscription being accepted) to a received Map-Request, the following extra steps take place:
それ以外の場合、Map-ServerがMap-Notify（例えば、サブスクリプションが受け入れられているため）で受信したMap-Requestに返信する必要がある場合、次の追加手順が行われます。
* The Map-Server extracts the OTK and the OTK Wrapping ID from the LISP-SEC Encapsulated Control Message (ECM) Authentication Data.
* MAP-SERVERは、LISP-SECカプセル化コントロールメッセージ（ECM）認証データからOTKとOTKラッピングIDを抽出します。
* The Map-Server generates a PubSubKey by deriving a key from the OTK, as described before for the ITR. This is the same PubSubKey derived at the ITR that is used to establish a security association between the ITR and the Map-Server.
* Map-Serverは、ITRについて前述のように、OTKからキーを導き出すことによりPubSubkeyを生成します。これは、ITRで派生したITRで派生したPubSubkeyと同じです。これは、ITRとMap-Serverの間にセキュリティ関連を確立するために使用されます。
* The PubSubKey can now be used to sign and authenticate any Map-Notify between the Map-Server and the ITR for the subscribed EID-Prefix. This includes the Map-Notify sent as a confirmation to the subscription. When the ITR wants to update the security association for that Map-Server and EID-Prefix, it once again follows the procedure described in this section.
* PubSubkeyを使用して、サブスクライブされたEid-PrefixのMap-ServerとITRの間のMap-Notifyに署名して認証できるようになりました。これには、サブスクリプションの確認として送信されたMap-notifyが含まれます。ITRがそのマップサーバーとEid-Prefixのセキュリティ協会を更新したい場合、このセクションで説明した手順に再び従います。
Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply described in Section 5.7 of [RFC9303] occur.
マップサーバーがMap-notifyで応答した場合、[RFC9303]のセクション5.7で説明されているMAP-REPLYに関する通常のLISP-SECステップは発生しないことに注意してください。
If PubSub is deployed under the scope of applicability defined in Section 1.1, only known nodes can participate on the PubSub deployment. DDoS attacks based on replayed messages by unknown nodes are avoided by the use of nonce and the security association between the ITRs and the Map-Servers. Misbehaving known nodes may send massive subscription requests, which may lead to exhausting the resources of a Map-Server. Furthermore, frequently changing the state of a subscription may also be considered as an attack vector. To mitigate such issues, Section 5.3 of [RFC9301] discusses rate-limiting Map-Requests, and Section 5.7 of [RFC9301] discusses rate-limiting Map-Notifies. Note that when the Map-Notify rate-limit threshold is met for a particular xTR-ID, the Map-Server will discard additional subscription requests from that xTR-ID and will fall back to the behavior described in [RFC9301] when receiving a Map-Request from that xTR-ID (i.e., the Map-Server will send a Map-Reply).
PubSubがセクション1.1で定義されている適用性の範囲の下で展開されている場合、既知のノードのみがPubSubの展開に参加できます。未知のノードによる再生されたメッセージに基づくDDOS攻撃は、NonCEとITRSとMAPサーバーの間のセキュリティ関連の使用により回避されます。既知のノードの不正行為は、大規模なサブスクリプションリクエストを送信する可能性があり、それがマップサーバーのリソースを使い果たすことにつながる可能性があります。さらに、サブスクリプションの状態を頻繁に変更することも、攻撃ベクトルと見なされる場合があります。このような問題を軽減するために、[RFC9301]のセクション5.3は、レート制限マップ要求について説明し、[RFC9301]のセクション5.7については、レート制限マップ項目について説明します。特定のXTR-IDに対してMAP-Notifyレートリミットのしきい値が満たされている場合、MAPサーバーはそのXTR-IDからの追加のサブスクリプションリクエストを破棄し、マップを受信するときに[RFC9301]に記載されている動作に戻ることに注意してください。 - そのXtr-IDからのリクエスト（つまり、マップサーバーはマップ応答を送信します）。
IANA has assigned the following new bit from the "LISP Control Plane Header Bits: Map-Request" registry within the "Locator/ID Separation Protocol (LISP) Parameters" group of registries [IANA-LISP]:
IANAは、「ロケーター/ID分離プロトコル（LISP）パラメーター」レジストリ[IANA-LISP]：「LISPコントロールプレーンヘッダービット：Map-Request」レジストリから次の新しいビットを割り当てました。
+===========+===============+==========+=============+===========+
| Spec Name | IANA Name | Bit | Description | Reference |
| | | Position | | |
+===========+===============+==========+=============+===========+
| I | Map-Request-I | 11 | xTR-ID Bit | RFC 9437 |
+-----------+---------------+----------+-------------+-----------+
Table 1: Addition to the Map-Request Header Bits Registry
表1：Map-Requestヘッダービットレジストリへの追加
IANA has also created a new registry entitled "LISP Control Plane Header Bits: Map-Request-Record" within the "Locator/ID Separation Protocol (LISP) Parameters" group of registries [IANA-LISP].
IANAはまた、「Locator/ID分離プロトコル（LISP）パラメーター」レジストリ[IANA-LISP]の「LISP Control Plane Header Bits：Map-Request-Record」というタイトルの新しいレジストリを作成しました。
The initial content of this registry is shown in Table 2.
このレジストリの初期内容を表2に示します。
+====+===============+========+========================+===========+
|Spec| IANA Name |Bit | Description | Reference |
|Name| |Position| | |
+====+===============+========+========================+===========+
|N | Map-Request-N |1 | Notification-Requested | RFC 9437 |
| | | | Bit | |
+----+---------------+--------+------------------------+-----------+
Table 2: Initial Content of LISP Control Plane Header Bits: Map-Request-Record Registry
表2：LISPコントロールプレーンヘッダービットの初期コンテンツ：Map-Request-Recordレジストリ
The remaining bits (i.e., bit positions 2-8) are Unassigned.
残りのビット（つまり、ビット位置2〜8）は割り当てられていません。
The policy for allocating new bits in this registry is "Specification Required" (Section 4.6 of [RFC8126]).
このレジストリに新しいビットを割り当てるためのポリシーは「必要な仕様」です（[RFC8126]のセクション4.6）。
Allocation requests are evaluated on the advice of one or more designated experts. Designated experts should consider whether the proposed registration duplicates existing entries and whether the registration description is sufficiently detailed and fits the purpose of this registry. These criteria are to be considered in addition to those provided in Section 4.6 of [RFC8126] (e.g., the proposed registration "must be documented in a permanent and readily available public specification"). The designated experts will either approve or deny the registration request, and communicate their decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
割り当てリクエストは、1人以上の指定された専門家のアドバイスで評価されます。指定された専門家は、提案された登録が既存のエントリを複製しているかどうか、および登録の説明が十分に詳細であり、このレジストリの目的に適合するかどうかを検討する必要があります。これらの基準は、[RFC8126]のセクション4.6に記載されているものに加えて考慮されます（例えば、提案された登録は「永続的で容易に利用可能な公開仕様で文書化する必要があります」）。指定された専門家は、登録要求を承認または拒否し、決定を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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>.
[EID-MOBILITY]
Portoles, M., Ashtaputre, V., Maino, F., Moreno, V., and
D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified
Control Plane", Work in Progress, Internet-Draft, draft-
ietf-lisp-eid-mobility-12, 4 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-12>.
[FLOW-EXAMPLES]
Boucadair, M., "LISP PubSub Flow Examples", Work in
Progress, Internet-Draft, draft-boucadair-lisp-pubsub-
flow-examples-03, 10 February 2023,
<https://datatracker.ietf.org/doc/html/draft-boucadair-
lisp-pubsub-flow-examples-03>.
[GB-ATN] Haindl, B., Lindner, M., Moreno, V., Portoles, M., Maino,
F., and B. Venkatachalapathy, "Ground-Based LISP for the
Aeronautical Telecommunications Network", Work in
Progress, Internet-Draft, draft-haindl-lisp-gb-atn-09, 27
March 2023, <https://datatracker.ietf.org/doc/html/draft-
haindl-lisp-gb-atn-09>.
[IANA-LISP]
IANA, "Locator/ID Separation Protocol (LISP) Parameters",
<https://www.iana.org/assignments/lisp-parameters/>.
[LISP-YANG]
Ermagan, V., Rodriguez-Natal, A., Coras, F., Moberg, C.,
Rahman, R., Cabellos, A., and F. Maino, "LISP YANG Model",
Work in Progress, Internet-Draft, draft-ietf-lisp-yang-19,
2 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lisp-yang-19>.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.
[UBERLAY] Moreno, V., Farinacci, D., Rodriguez-Natal, A., Portoles-
Comeras, M., Maino, F., and S. Hooda, "Uberlay
Interconnection of Multiple LISP overlays", Work in
Progress, Internet-Draft, draft-moreno-lisp-uberlay-06, 28
September 2022, <https://datatracker.ietf.org/doc/html/
draft-moreno-lisp-uberlay-06>.
Some LISP production networks have been running different forms of PubSub for some time. The following subsections provide an inventory of some experience lessons from these deployments.
一部のLISP生産ネットワークは、しばらくの間、さまざまな形のPubSubを実行しています。次のサブセクションは、これらの展開からのいくつかの経験レッスンのインベントリを提供します。
Some LISP deployments are using PubSub as a way to monitor EID-Prefixes (particularly, EID-to-RLOC mappings). To that aim, some LISP implementations have extended the LISP Internet Groper ('lig') [RFC6835] tool to use PubSub. Such an extension is meant to support an interactive mode with 'lig' and to request subscription for the EID of interest. If there are RLOC changes, the Map-Server sends a notification, and then the 'lig' client displays that change to the user.
一部のLISP展開では、Eid-Prefixes（特にEid-to-RLOCマッピング）を監視する方法としてPubSubを使用しています。その目的のために、いくつかのLISP実装により、PubSubを使用するためのLISPインターネットグロパー（ 'lig'）[RFC6835]ツールが拡張されました。このような拡張機能は、「LIG」を使用したインタラクティブモードをサポートし、関心のあるEIDのサブスクリプションをリクエストすることを目的としています。RLOCの変更がある場合、Map-Serverは通知を送信し、「Lig」クライアントがユーザーに変更を表示します。
Section 8.1 of [RFC9301] suggests two TTL values for Negative Map-Replies: either a 15-minute TTL (if the EID-Prefix does not exist) or a 1-minute TTL (if the prefix exists but has not been registered). While these values are based on the original operational experience of the LISP protocol designers, negative cache entries have two unintended effects that were observed in production.
[RFC9301]のセクション8.1は、負のMAPレプリーの2つのTTL値を示唆しています。15分間のTTL（Eid-Prefixが存在しない場合）または1分間のTTL（プレフィックスが存在するが登録されていない場合）。これらの値は、LISPプロトコル設計者の元の運用体験に基づいていますが、ネガティブキャッシュエントリには、生産で観察された2つの意図しない効果があります。
First, if the xTR keeps receiving traffic for a negative EID destination (i.e., an EID-Prefix with no RLOCs associated with it), it will try to resolve the destination again once the cached state expires, even if the state has not changed in the Map-Server. It was observed in production that this is happening often in networks that have a significant amount of traffic addressed for outside of the LISP network. This might result in excessive resolution signaling to keep retrieving the same state due to the cache expiring. PubSub is used to relax TTL values and cache negative mapping entries for longer periods of time, avoiding unnecessary refreshes of these forwarding entries and drastically reducing signaling in these scenarios. In general, a TTL-based schema is a "polling mechanism" that leads to more signaling where PubSub provides an "event-triggered mechanism" at the cost of state.
まず、XTRがネガティブなEIDの目的地（つまり、RLOCが関連付けられていないEID-Prefix）のトラフィックを受け続けている場合、状態が変更されていなくても、キャッシュ状態の有効期限が切れたら再び目的地を解決しようとします。マップサーバー。生産中に、これはLISPネットワークの外側でかなりの量のトラフィックが対処されているネットワークでしばしば起こっていることが観察されました。これにより、キャッシュが期限切れになって同じ状態を取得し続けるために、過度の解像度シグナル伝達が発生する可能性があります。PubSubは、TTL値をリラックスさせ、ネガティブマッピングエントリをより長期間キャッシュするために使用され、これらの転送エントリの不必要なリフレッシュを回避し、これらのシナリオでのシグナル伝達を大幅に削減します。一般に、TTLベースのスキーマは、PubSubが国家の犠牲を払って「イベントトリガーメカニズム」を提供するより多くのシグナル伝達につながる「ポーリングメカニズム」です。
Second, if the state does indeed change in the Map-Server, updates based on TTL timeouts might prevent the cached state at the xTR from being updated until the TTL expires. This behavior was observed during configuration (or reconfiguration) periods on the network, where EID-Prefixes that are no longer negative do not receive the traffic yet, due to stale Map-Cache entries present in the network. With the activation of PubSub, stale caches can be updated as soon as the state changes.
第二に、マップサーバーで状態が実際に変更された場合、TTLのタイムアウトに基づく更新は、XTRのキャッシュ状態がTTLの有効期限が切れるまで更新されないようにする可能性があります。この動作は、ネットワークに存在する古いマップキャッシュエントリのために、ネットワーク上の構成（または再構成）期間中に観察されました。PubSubの活性化により、状態が変わるとすぐに古いキャッシュを更新できます。
An improved convergence time was observed on the presence of mobility events on LISP networks running PubSub as compared with running LISP [RFC9301]. As described in Section 4.1.2.1 of [EID-MOBILITY], LISP can rely on data-driven Solicit-Map-Requests (SMRs) to ensure eventual network convergence. Generally, PubSub offers faster convergence due to (1) no need to wait for a data-triggered event and (2) less signaling as compared with the SMR-based flow. Note that when a Map-Server running PubSub has to update a large number of subscribers at once (i.e., when a popular mapping is updated), SMR-based convergence may be faster for a small subset of the subscribers (those receiving PubSub updates last). Deployment experience reveals that data-driven SMRs and PubSub mechanisms complement each other and provide a fast and resilient network infrastructure in the presence of mobility events.
ランニングLISP [RFC9301]と比較して、PubSubを実行しているLISPネットワーク上のモビリティイベントの存在で、収束時間が改善されました。[EID-Mobility]のセクション4.1.2.1で説明されているように、LISPはデータ駆動型のSolicit-Map-Requests（SMRS）に依存して、最終的なネットワーク収束を確保できます。一般的に、PubSubは、（1）データトリガーされたイベントを待つ必要がなく、（2）SMRベースのフローと比較してより少ないシグナル伝達のために、より速い収束を提供します。PubSubを実行しているマップサーバーが多数のサブスクライバーを一度に更新する必要がある場合（つまり、人気のマッピングが更新されたとき）、SMRベースの収束は、サブスクライバーの小さなサブセットでより速くなる可能性があることに注意してください（PubSubの更新を受信した人は最後のサブスクライバーを受け取った人は）。展開の経験により、データ駆動型SMRとPUBSUBメカニズムが互いに補完し、モビリティイベントの存在下で高速で回復力のあるネットワークインフラストラクチャを提供することが明らかになりました。
Furthermore, experience showed that not all LISP entities on the network need to implement PubSub for the network to get the benefits. In scenarios with significant traffic coming from outside of the LISP network, the experience showed that enabling PubSub in the border routers significantly improves mobility latency overall. Even if edge xTRs do not implement PubSub, and traffic is exchanged between EID-Prefixes at the edge, xTRs still converge based on data-driven events and SMR-triggered updates.
さらに、ネットワーク上のすべてのLISPエンティティがネットワークのPUBSUBを実装して利益を得る必要があるわけではないことが経験が示されました。LISPネットワークの外側からの大幅なトラフィックがあるシナリオでは、このエクスペリエンスにより、Border RutersでPubSubを有効にすると、全体的にモビリティの遅延が大幅に向上することが示されました。Edge XtrがPubSubを実装せず、EdgeのEid-Prefixes間でトラフィックが交換されている場合でも、XTRはデータ駆動型のイベントとSMRトリガーされた更新に基づいて収束します。
There is a need to interconnect LISP networks with other networks that might or might not run LISP. Some of those scenarios are similar to the ones described in [GB-ATN] and [UBERLAY]. When connecting LISP to other networks, the experience revealed that in many deployments the point of interaction with the other domains is not the Mapping System but rather the border router of the LISP site. For those cases, the border router needs to be aware of the LISP prefixes to redistribute them to the other networks. Over the years, different solutions have been used.
LISPを実行する可能性のある他のネットワークと相互接続する必要があります。これらのシナリオのいくつかは、[gb-atn]および[uberlay]で説明されているシナリオに似ています。LISPを他のネットワークに接続すると、多くの展開において、他のドメインとの相互作用のポイントはマッピングシステムではなく、LISPサイトのボーダールーターであることが明らかになりました。これらの場合、Borderルーターは、他のネットワークに再配布するためにLISPプレフィックスを認識する必要があります。長年にわたり、さまざまなソリューションが使用されてきました。
First, Map-Servers were collocated with the border routers, but this was hard to scale since border routers scale at a different pace than Map-Servers. Second, decoupled Map-Servers and border routers were used with static configuration of LISP entries on the border, which was problematic when modifications were made. Third, a routing protocol (e.g., BGP) can be used to redistribute LISP prefixes from the Map-Servers to a border router, but this comes with some implications; in particular, the Map-Servers need to implement an additional protocol, which consumes resources and needs to be properly configured. Therefore, once PubSub was available, deployments started to adapt it to enable border routers to dynamically learn the prefixes they need to redistribute without a need for extra protocols or extra configuration on the network.
第一に、地図のサーバーはボーダールーターとcolocedされましたが、これは、マップサーバーとは異なるペースで境界線ルーターがスケーリングするため、拡張するのが困難でした。第二に、デカップされたマップサーバーと境界線ルーターは、ボーダーのLISPエントリの静的な構成で使用されました。これは、変更が行われたときに問題がありました。第三に、ルーティングプロトコル（BGPなど）を使用して、MAPサーバーからBorderルーターにLISPプレフィックスを再分配できますが、これにはいくつかの意味があります。特に、マップサーバーは、リソースを消費し、適切に構成する必要がある追加のプロトコルを実装する必要があります。したがって、PubSubが利用可能になると、展開が適応し始め、ボーダールーターがネットワーク上の追加プロトコルや追加の構成を必要とせずに再配布する必要があるプレフィックスを動的に学習できるようにしました。
In other words, PubSub can be used to discover EID-Prefixes so they can be imported into other routing domains that do not use LISP. Similarly, PubSub can also be used to discover when EID-Prefixes need to be withdrawn from other routing domains. That is, in a typical deployment, a border router will withdraw an EID-Prefix that it has been announcing to external routing domains if it receives a notification that the RLOC-set for that EID-Prefix is now empty.
言い換えれば、PubSubを使用してEid-Prefixesを発見して、LISPを使用しない他のルーティングドメインにインポートできます。同様に、PubSubを使用して、Eid-Prefixesを他のルーティングドメインから撤回する必要があることを発見することもできます。つまり、典型的な展開では、Border RouterがEid-Prefixを撤回し、そのEid-PrefixのRLOC-SETが空になったという通知を受け取った場合、外部ルーティングドメインにアナウンスしています。
EID-to-RLOC mappings can have a very long TTL, sometimes on the order of several hours. Upon the expiry of that TTL, the xTR checks if these entries are being used and removes any entry that is not being used. The problem with a very long Map-Cache TTL is that (in the absence of PubSub) if a mapping changes but is not being used, the cache remains but is stale. This is due to no data traffic being sent to the old location to trigger an SMR-based Map-Cache update as described in Section 4.1.2.1 of [EID-MOBILITY]. If the network operator runs a show command on a router to track the state of the Map-Cache, the router will display multiple entries waiting to expire but with stale RLOC information. This might be confusing for operators sometimes, particularly when they are debugging problems. With PubSub, the Map-Cache is updated with the correct RLOC information, even when it is not being used or waiting to expire, which helps with debugging.
Eid-to-RLOCマッピングには、非常に長いTTLがあり、時には数時間の順になります。そのTTLの有効期限が切れると、XTRはこれらのエントリが使用されているかどうかをチェックし、使用されていないエントリを削除します。非常に長いマップキャッシュTTLの問題は、マッピングが変更されていないが使用されていない場合、キャッシュが残っているが古いものであるということです。これは、[eid-mobility]のセクション4.1.2.1で説明されているように、SMRベースのマップキャッシュアップデートをトリガーするために、古い場所にデータトラフィックが送信されないためです。ネットワークオペレーターがルーターでshowコマンドを実行してマップキャッシュの状態を追跡する場合、ルーターには期限が切れるのを待っている複数のエントリが表示されますが、古いRLOC情報を使用します。これは、特に問題の問題が発生している場合、オペレーターにとって時々混乱する可能性があります。PubSubを使用すると、マップキャッシュが正しいRLOC情報で更新されます。
We would like to thank Marc Portoles, Balaji Venkatachalapathy, Bernhard Haindl, Luigi Iannone, and Padma Pillay-Esnault for their great suggestions and help regarding this document.
Marc Portoles、Balaji Venkatachalapathy、Bernhard Haindl、Luigi Iannone、Padma Pillay-Esnaultに、この文書に関する素晴らしい提案と助けについて感謝します。
Many thanks to Alvaro Retana for the careful AD review.
慎重な広告レビューをしてくれたAlvaro Retanaに感謝します。
Thanks to Chris M. Lonvick for the security directorate review, Al Morton for the OPS-DIR review, Roni Even for the Gen-ART review, Mike McBride for the rtg-dir review, Magnus Westerlund for the tsv directorate review, and Sheng Jiang for the int-dir review.
セキュリティディレクターレビューのためにクリスM.ロンヴィック、OPS-DIRレビューのためのアルモートン、Gen-ArtレビューのRoni、RTG-DirレビューのMike McBride、TSV Directrate ReviewのMagnus Westerlund、およびSheng Jiangに感謝しますint-dirレビュー用。
Thanks to John Scudder, Erik Kline, Lars Eggert, Warren Kumari, Martin Duke, Murray Kucherawy, Éric Vyncke, Robert Wilton, Zaheduzzaman Sarker, and Roman Danyliw for the IESG review.
John Scudder、Erik Kline、Lars Eggert、Warren Kumari、Martin Duke、Murray Kucherawy、エリックヴィンケ、ロバートウィルトン、ザヘダッツァマンサルカー、ロマンダニリウのIESGレビューに感謝します。
This work was partly funded by the ANR LISP-Lab project #ANR-13-INFR-009 <https://anr.fr/Projet-ANR-13-INFR-0009>.
この作業は、ANR LISP-LABプロジェクト＃ANR-13-infR-009 <https://anr.fr/projet-anr-13-infr-0009>によって部分的に資金提供されていました。
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
Johnson Leong
Email: johnsonleong@gmail.com
Fabio Maino
Cisco
San Jose, CA
United States of America
Email: fmaino@cisco.com
Christian Jacquenet
Orange
Rennes
France
Email: christian.jacquenet@orange.com
Stefano Secci
Cnam
France
Email: stefano.secci@cnam.fr
Alberto Rodriguez-Natal
Cisco
Barcelona
Spain
Email: natal@cisco.com
Vina Ermagan
Google
United States of America
Email: ermagan@gmail.com
Albert Cabellos
UPC/BarcelonaTech
Barcelona
Spain
Email: acabello@ac.upc.edu
Sharon Barkai
Nexar
Email: sharon.barkai@getnexar.com
Mohamed Boucadair
Orange
Rennes
France
Email: mohamed.boucadair@orange.com