Internet Engineering Task Force (IETF) R. Parekh, Ed.
Request for Comments: 10018 Arrcus
Updates: 6514, 7988 D. Voyer, Ed.
Category: Standards Track C. Filsfils
ISSN: 2070-1721 Cisco Systems, Inc.
H. Bidgoli
Nokia
Z. Zhang
Juniper Networks
August 2026
A Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs (EVPNs) in an SR domain. This document updates RFCs 6514 and 7988.
セグメント ルーティング (SR) ドメインのポイントツーマルチポイント (P2MP) ツリーは、ルートから一連のリーフにトラフィックを伝送します。この文書では、SR ドメインの BGP/MPLS IP VPN およびイーサネット VPN (EVPN) で使用される P2MP ツリーとイングレス レプリケーションの BGP エンコーディングの拡張と手順を指定します。この文書は RFC 6514 および 7988 を更新します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10018.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10018 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
1.2. Requirements Language
2. SR P2MP P-Tunnel
3. MVPN with SR
3.1. SRv6 Multicast Endpoint Behaviors
3.1.1. End.DTMC4: Decapsulation and Specific IPv4 Multicast
Table Lookup
3.1.2. End.DTMC6: Decapsulation and Specific IPv6 Multicast
Table Lookup
3.1.3. End.DTMC46: Decapsulation and Specific IP Multicast
Table Lookup
3.2. MVPN with SR P2MP P-Tunnel
3.2.1. PMSI Tunnel Attribute for SR P2MP P-Tunnel
3.2.2. Auto-Discovery Procedures
3.3. MVPN with Ingress Replication over SR
3.3.1. SR-MPLS
3.3.2. SRv6
4. EVPN with SR
4.1. EVPN with SR P2MP P-Tunnel
4.1.1. PMSI Tunnel Attribute for SR P2MP P-Tunnel
4.1.2. Split-Horizon Filtering for ES Multihoming
4.1.3. Auto-Discovery Procedures
4.2. EVPN with Ingress Replication over SR
4.2.1. SR-MPLS
4.2.2. SRv6
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
"Multicast in MPLS/BGP IP VPNs" [RFC6513] and "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs" [RFC6514] specify procedures that allow a network operator to provide Multicast VPN (MVPN) service to its customers. Multicast traffic from a customer is tunneled across the service provider network over Provider Tunnels (P-tunnels). P-tunnels can be instantiated using different transport mechanisms. For example, a service provider network that uses Segment Routing (SR) can use an SR Point-to-Multipoint (P2MP) tree defined by an SR P2MP Policy [RFC9960] or SR P2MP Ingress Replication (IR) to instantiate P-tunnels for MVPN. This document refers to a P-tunnel realized by an SR P2MP Policy as an SR P2MP P-tunnel. SR P2MP P-tunnels can be instantiated for both Segment Routing over MPLS (SR-MPLS) [RFC8660] and Segment Routing over IPv6 (SRv6) [RFC8986] [RFC8754].
「MPLS/BGP IP VPN でのマルチキャスト」[RFC6513] および「MPLS/BGP IP VPN でのマルチキャストの BGP エンコーディングと手順」[RFC6514] では、ネットワーク オペレータが顧客にマルチキャスト VPN (MVPN) サービスを提供できるようにする手順が規定されています。顧客からのマルチキャスト トラフィックは、プロバイダー トンネル (P トンネル) を介してサービス プロバイダー ネットワーク全体にトンネルされます。P トンネルは、さまざまなトランスポート メカニズムを使用してインスタンス化できます。たとえば、セグメント ルーティング (SR) を使用するサービス プロバイダー ネットワークは、SR P2MP ポリシー [RFC9960] または SR P2MP 入力レプリケーション (IR) によって定義された SR ポイントツーマルチポイント (P2MP) ツリーを使用して、MVPN の P トンネルをインスタンス化できます。このドキュメントでは、SR P2MP ポリシーによって実現される P トンネルを SR P2MP P トンネルと呼びます。SR P2MP P トンネルは、セグメント ルーティング オーバー MPLS (SR-MPLS) [RFC8660] とセグメント ルーティング オーバー IPv6 (SRv6) [RFC8986] [RFC8754] の両方に対してインスタンス化できます。
An SR P2MP tree is defined by an SR P2MP Policy [RFC9960] and instantiated via a controller such as a Path Computation Element (PCE). An SR P2MP Policy consists of a Root, a set of Leaf nodes, and a set of candidate paths (CPs) with optional set of constraints and/or optimization objectives to be satisfied by the SR P2MP tree. A CP has zero or more P2MP tree instances (PTIs).
SR P2MP ツリーは SR P2MP ポリシー [RFC9960] によって定義され、Path Computation Element (PCE) などのコントローラーを介してインスタンス化されます。SR P2MP ポリシーは、ルート、リーフ ノードのセット、および SR P2MP ツリーによって満たされるオプションの制約および/または最適化目標を含む候補パス (CP) のセットで構成されます。CP には 0 個以上の P2MP ツリー インスタンス (PTI) があります。
This document specifies extensions to BGP auto-discovery procedures specified in [RFC6514] for P-tunnels constructed with a PTI. Use of Protocol Independent Multicast (PIM) for auto-discovery is outside the scope of this document. Support for customer Bidirectional PIM (BIDIR-PIM) is also outside the scope of this document.
この文書は、PTI で構築された P トンネル用に [RFC6514] で指定されている BGP 自動検出手順の拡張を指定します。自動検出のための Protocol Independent Multicast (PIM) の使用は、このドキュメントの範囲外です。顧客の双方向 PIM (BIDIR-PIM) のサポートも、このドキュメントの範囲外です。
This document extends procedures in [RFC7988] for MVPN service with IR over an SR-MPLS data plane with a Service Level Agreement (SLA). New procedures are defined for MVPN service with IR over an SRv6 data plane with or without an SLA.
この文書は、サービス レベル アグリーメント (SLA) を備えた SR-MPLS データ プレーン上の IR を使用した MVPN サービスに関する [RFC7988] の手順を拡張します。SLA の有無にかかわらず、SRv6 データ プレーン上で IR を使用する MVPN サービス用の新しい手順が定義されています。
This document defines new SRv6 Endpoint behaviors [RFC8986] used for MVPN with SR P2MP and IR P-tunnels.
このドキュメントは、SR P2MP および IR P トンネルを備えた MVPN に使用される新しい SRv6 エンドポイント動作 [RFC8986] を定義します。
For BGP MPLS-Based EVPN specified in [RFC7432] and updated in [RFC9572], P-tunnels are advertised for handling multi-destination traffic. These P-tunnels can be instantiated by SR-MPLS or SRv6 P2MP trees.
[RFC7432] で規定され、[RFC9572] で更新された BGP MPLS ベースの EVPN では、複数宛先トラフィックを処理するために P トンネルがアドバタイズされます。これらの P トンネルは、SR-MPLS または SRv6 P2MP ツリーによってインスタンス化できます。
The reader is expected to be familiar with [RFC6513] and [RFC6514] for MVPN procedures. For EVPN procedures, refer to [RFC7432].
読者は、MVPN 手順に関する [RFC6513] および [RFC6514] に精通していることが期待されます。EVPN 手順については、[RFC7432] を参照してください。
Scalability, operational, and troubleshooting considerations for SR P2MP trees and Replication segments are described in [RFC9960] and [RFC9524], respectively. Operations, Administration, and Maintenance (OAM) ping and traceroute procedures for SR P2MP Policy using the SR-MPLS data plane are specified in [RFC9961].
SR P2MP ツリーとレプリケーション セグメントのスケーラビリティ、運用、トラブルシューティングに関する考慮事項は、それぞれ [RFC9960] と [RFC9524] で説明されています。SR-MPLS データ プレーンを使用した SR P2MP ポリシーの運用、管理、およびメンテナンス (OAM) ping およびtraceroute 手順は、[RFC9961] で規定されています。
The following terms are used as defined in [RFC8402]:
以下の用語は、[RFC8402] で定義されているように使用されます。
* Segment Routing (SR)
* セグメントルーティング (SR)
* Segment Identifier (SID)
* セグメント識別子 (SID)
* SR domain
* SRドメイン
* SR-MPLS
* SR-MPLS
* SRv6
* SRv6
* SRv6 SID
* SRv6 SID
The following term is used as defined in [RFC8754]:
次の用語は、[RFC8754] で定義されているように使用されます。
* Segment Routing Header (SRH)
* セグメントルーティングヘッダー (SRH)
The following terms are used as defined in [RFC9524]:
以下の用語は、[RFC9524] で定義されているように使用されます。
* Replication segment
* レプリケーションセグメント
* Replication-SID
* レプリケーション SID
* Root node
* ルートノード
* Leaf node
* リーフノード
* Bud node
* バドノード
* Intermediate Replication node
* 中間レプリケーションノード
The following terms are used as defined in [RFC9960]:
以下の用語は、[RFC9960] で定義されているように使用されます。
* SR P2MP Policy
* SR P2MP ポリシー
* Tree-ID
* ツリーID
* Candidate path (CP)
* 候補パス（CP）
* P2MP tree instance (PTI)
* P2MP ツリー インスタンス (PTI)
* Tree-SID
* ツリー-SID
For MVPN, the following terms are used as defined in [RFC6513] and [RFC6514]:
MVPN では、[RFC6513] および [RFC6514] で定義されている次の用語が使用されます。
* P-Multicast Service Interface (PMSI)
* P-マルチキャスト サービス インターフェイス (PMSI)
* P-tunnel
* Pトンネル
* PMSI Tunnel Attribute (PTA)
* PMSI トンネル属性 (PTA)
* Auto-Discovery (A-D) routes
* 自動検出 (A-D) ルート
* Intra-AS I-PMSI A-D
* AS 内 I-PMSI A-D
* Inter-AS I-PMSI A-D
* Inter-AS I-PMSI A-D
* S-PMSI A-D
* S-PMSI A-D
* Leaf A-D route
* リーフA-Dルート
For EVPN, the following terms are used as defined in [RFC7432], [RFC9251], and [RFC9572]:
EVPN では、[RFC7432]、[RFC9251]、および [RFC9572] で定義されている次の用語が使用されます。
* EVPN Instance (EVI)
* EVPN インスタンス (EVI)
* Ethernet Segment (ES)
* イーサネットセグメント (ES)
* Ethernet Segment Identifier (ESI)
* イーサネット セグメント識別子 (ESI)
* Inclusive Multicast Ethernet Tag (IMET) route
* 包括的なマルチキャスト イーサネット タグ (IMET) ルート
* Selective Multicast Ethernet Tag (SMET) route
* 選択的マルチキャスト イーサネット タグ (SMET) ルート
* Broadcast, Unknown Unicast or Multicast (BUM)
* ブロードキャスト、不明なユニキャストまたはマルチキャスト (BUM)
* S-PMSI
* S-PMSI
* Leaf A-D route
* リーフA-Dルート
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
For MVPN or EVPN, Provider Edge (PE) routers can steer customer traffic into a P-tunnel realized by an SR-MPLS or SRv6 PTI. An SR PTI is instantiated by a CP of an SR P2MP Policy [RFC9960]. A P-tunnel is signaled in MVPN or EVPN A-D routes using the BGP PMSI Tunnel Attribute (PTA) [RFC6514]. The PTA identifies the P-tunnel that is used to instantiate a PMSI.
MVPN または EVPN の場合、プロバイダー エッジ (PE) ルーターは、顧客のトラフィックを SR-MPLS または SRv6 PTI によって実現される P トンネルに誘導できます。SR PTI は、SR P2MP ポリシー [RFC9960] の CP によってインスタンス化されます。P トンネルは、BGP PMSI トンネル属性 (PTA) [RFC6514] を使用して、MVPN または EVPN A-D ルートでシグナリングされます。PTA は、PMSI のインスタンス化に使用される P トンネルを識別します。
+---------------------------------+
| INGRESS PE | +------------+
| +----------+ +----------+ | | |
| | | | SR P2MP | | PCEP/BGP/etc. | |
| | MVPN/EVPN+---->| Policy | +------------------>| CONTROLLER |
| | Module | | Module | | | |
| +----------+ +----------+ | | |
| | +------------+
+---------------------------------+
Figure 1: MVPN/EVPN Interaction with SR P2MP Policy
図 1: MVPN/EVPN と SR P2MP ポリシーの相互作用
The figure above shows the interaction between the conceptual MVPN or EVPN module and SR P2MP Policy module on an ingress PE. The ingress PE participates in MVPN or EVPN AD procedures and interacts with the SR P2MP Policy module as shown above to create and update the SR P2MP Policy, CP, and the Leaf set of SR P2MP policies. The SR P2MP Policy module interacts with a controller using protocols such as the Path Computation Element Communication Protocol (PCEP) [SR-P2MP-PCEP], BGP, the Network Configuration Protocol (NETCONF), etc., which are outside the scope of this document.
上の図は、概念的な MVPN または EVPN モジュールと入力 PE 上の SR P2MP ポリシー モジュール間の相互作用を示しています。入力 PE は、MVPN または EVPN AD プロシージャに参加し、上記のように SR P2MP ポリシー モジュールと対話して、SR P2MP ポリシー、CP、および SR P2MP ポリシーのリーフ セットを作成および更新します。SR P2MP ポリシー モジュールは、Path Computation Element Communication Protocol (PCEP) [SR-P2MP-PCEP]、BGP、Network Configuration Protocol (NETCONF) などのプロトコルを使用してコントローラーと対話しますが、これらはこのドキュメントの範囲外です。
An ingress PE creates a CP of an SR P2MP Policy in the SR P2MP Policy module upon provisioning of the MVPN or EVPN module for the SR P2MP P-tunnel or based on events or policy, such as mapping MVPN or EVPN flow to a new SR P2MP P-tunnel. This CP can have optional traffic engineering constraints and/or an optimization objective by provisioning or by a local policy. The SR P2MP Policy module signals the CP along with the constraints and optimization objective to the controller using one of the protocols mentioned above. The ingress PE deletes the CP of the SR P2MP Policy from the SR P2MP Policy module when the SR P2MP P-tunnel is not longer required. The SR P2MP Policy module signals deletion of the CP of the SR P2MP Policy to the controller.
入力 PE は、SR P2MP P トンネル用の MVPN または EVPN モジュールのプロビジョニング時、または MVPN または EVPN フローの新しい SR P2MP P トンネルへのマッピングなどのイベントまたはポリシーに基づいて、SR P2MP ポリシー モジュールに SR P2MP ポリシーの CP を作成します。この CP には、プロビジョニングまたはローカル ポリシーによるオプションのトラフィック エンジニアリング制約や最適化目標を設定できます。SR P2MP ポリシー モジュールは、前述のプロトコルのいずれかを使用して、制約および最適化目標とともに CP をコントローラーに送信します。SR P2MP P トンネルが不要になった場合、入力 PE は SR P2MP ポリシー モジュールから SR P2MP ポリシーの CP を削除します。SR P2MP ポリシー モジュールは、SR P2MP ポリシーの CP の削除をコントローラに通知します。
An ingress PE participates in the MVPN or EVPN A-D procedures defined in this document to discover Leaf nodes of an SR P2MP P-tunnel via various A-D routes. The MVPN or EVPN module on the ingress PE updates the Leaf set of the SR P2MP Policy corresponding to the P-tunnel in the SR P2MP Policy module. The SR P2MP Policy module signals the updated Leaf set to the controller using one of the protocols mentioned above.
入力 PE は、このドキュメントで定義されている MVPN または EVPN A-D プロシージャに参加し、さまざまな A-D ルートを介して SR P2MP P トンネルのリーフ ノードを検出します。入力 PE の MVPN または EVPN モジュールは、SR P2MP ポリシー モジュールの P トンネルに対応する SR P2MP ポリシーのリーフ セットを更新します。SR P2MP ポリシー モジュールは、上記のプロトコルのいずれかを使用して、更新されたリーフ セットをコントローラに送信します。
An egress PE associates an MVPN or EVPN A-D route with an MVPN or EVPN context and informs the SR P2MP Policy module to join the SR P2MP P-tunnel as a Leaf or a Bud node.
出力 PE は、MVPN または EVPN の A-D ルートを MVPN または EVPN コンテキストに関連付け、SR P2MP ポリシー モジュールにリーフ ノードまたはバッド ノードとして SR P2MP P トンネルに参加するように通知します。
Given a Leaf set of an SR P2MP Policy and a CP with constraints and an optimization objective, the controller computes and instantiates the PTI on the nodes that are part of the tree by stitching Replication segments [RFC9524] at the Root (ingress PE) node, intermediate replication nodes, and Leaf nodes (egress PEs). A Replication segment of a PTI can be instantiated by various methods such as BGP, PCEP, NETCONF, etc., which are outside the scope of this document. This PTI of the SR P2MP Policy instantiates the P-tunnel advertised by the MVPN or EVPN A-D routes.
SR P2MP ポリシーのリーフ セットと制約と最適化目標を備えた CP が与えられると、コントローラーはルート (入力 PE) ノード、中間レプリケーション ノード、およびリーフ ノード (出力 PE) でレプリケーション セグメント [RFC9524] を結合することにより、ツリーの一部であるノード上で PTI を計算しインスタンス化します。PTI のレプリケーション セグメントは、BGP、PCEP、NETCONF などのさまざまな方法でインスタンス化できますが、これらはこのドキュメントの範囲外です。SR P2MP ポリシーのこの PTI は、MVPN または EVPN A-D ルートによってアドバタイズされる P トンネルをインスタンス化します。
The Tree-SID is the unique data plane identifier of the PTI. The Root node encapsulates the payload in the Tree-SID to steer it into the PTI. The Provider (P) routers replicate the encapsulated payload using Replication segments towards the Leaf nodes of the PTI. The Leaf nodes of the PTI dispose the Tree-SID and deliver the payload. A Leaf node derives the MVPN or EVPN instance for delivering the payload from either the Tree-SID or another context encoded in the packet.
Tree-SID は、PTI の一意のデータ プレーン識別子です。ルート ノードは、ペイロードを Tree-SID にカプセル化して、PTI に誘導します。プロバイダー (P) ルーターは、レプリケーション セグメントを使用してカプセル化されたペイロードを PTI のリーフ ノードに向けて複製します。PTI のリーフ ノードは、Tree-SID を破棄し、ペイロードを配信します。リーフ ノードは、Tree-SID またはパケット内にエンコードされた別のコンテキストからペイロードを配信するための MVPN または EVPN インスタンスを派生します。
Note that an ingress PE can deliver an MVPN or EVPN payload to the egress PEs using IR over SR-MPLS or SRv6. The SR P2MP Policy module and controller do not participate in IR.
入力 PE は、IR over SR-MPLS または SRv6 を使用して MVPN または EVPN ペイロードを出力 PE に配信できることに注意してください。SR P2MP ポリシー モジュールとコントローラーは IR に参加しません。
MVPN service can be provided using SR P2MP trees or IR over either an SR-MPLS or SRv6 data plane.
MVPN サービスは、SR-MPLS または SRv6 データ プレーン上の SR P2MP ツリーまたは IR を使用して提供できます。
The following SRv6 Endpoint behaviors can be associated with the SRv6 Multicast Service SID used for MVPN with SR P2MP and IR P-tunnels.
次の SRv6 エンドポイントの動作は、SR P2MP および IR P トンネルを備えた MVPN に使用される SRv6 マルチキャスト サービス SID に関連付けることができます。
The "Endpoint with Decapsulation and IPv4 Multicast Table Lookup" behavior (End.DTMC4 for short) is functionally identical to the End.DT4 behavior specified in [RFC8986], except that the forwarding lookup MUST be performed in the IPv4 multicast routing table rather than the IPv4 unicast routing table.
「カプセル化解除と IPv4 マルチキャスト テーブル ルックアップを備えたエンドポイント」の動作 (略して End.DTMC4) は、転送ルックアップが IPv4 ユニキャスト ルーティング テーブルではなく IPv4 マルチキャスト ルーティング テーブルで実行されなければならないことを除いて、[RFC8986] で指定されている End.DT4 の動作と機能的に同じです。
This behavior MUST only be associated with the SRv6 Multicast Service SID carried in AFI/SAFI 1/129 (MVPN-IPv4) A-D routes.
この動作は、AFI/SAFI 1/129 (MVPN-IPv4) A-D ルートで伝送される SRv6 マルチキャスト サービス SID にのみ関連付けられなければなりません (MUST)。
The "Endpoint with Decapsulation and IPv6 Multicast Table Lookup" behavior (End.DTMC6 for short) is functionally identical to the End.DT6 behavior specified in [RFC8986], except that the forwarding lookup MUST be performed in the IPv6 multicast routing table rather than the IPv6 unicast routing table.
「カプセル化解除と IPv6 マルチキャスト テーブル ルックアップを備えたエンドポイント」の動作 (略して End.DTMC6) は、転送ルックアップが IPv6 ユニキャスト ルーティング テーブルではなく IPv6 マルチキャスト ルーティング テーブルで実行されなければならないことを除いて、[RFC8986] で指定されている End.DT6 の動作と機能的に同じです。
This behavior MUST only be associated with the SRv6 Multicast Service SID carried in AFI/SAFI 2/129 (MVPN-IPv6) A-D routes.
この動作は、AFI/SAFI 2/129 (MVPN-IPv6) A-D ルートで伝送される SRv6 マルチキャスト サービス SID にのみ関連付けられなければなりません (MUST)。
The "Endpoint with Decapsulation and IP Multicast Table Lookup" behavior (End.DTMC46 for short) is functionally identical to the End.DT4 and End.DT6 behaviors specified in [RFC8986], except that the forwarding lookup MUST be performed in the IP multicast routing table rather than in an IP unicast routing table.
「カプセル化解除と IP マルチキャスト テーブル ルックアップを伴うエンドポイント」の動作 (略して End.DTMC46) は、転送ルックアップが IP ユニキャスト ルーティング テーブルではなく IP マルチキャスト ルーティング テーブルで実行されなければならないことを除いて、[RFC8986] で指定されている End.DT4 および End.DT6 の動作と機能的に同一です。
This behavior MUST only be associated with the SRv6 Multicast Service SID carried in AFI/SAFI 1/129 (MVPN-IPv4) or 2/129 (MVPN-IPv6) A-D routes.
この動作は、AFI/SAFI 1/129 (MVPN-IPv4) または 2/129 (MVPN-IPv6) A-D ルートで伝送される SRv6 マルチキャスト サービス SID にのみ関連付けられなければなりません (MUST)。
[RFC6514] defines procedures for discovering PEs participating in a given MVPN and binding customer multicast flows to specific P-tunnels. This section specifies modifications to these procedures for SR P2MP P-tunnels. The Intra-AS I-PMSI, Inter-AS I-PMSI, and S-PMSI A-D routes have the PTA that specifies the SR P2MP tree P-tunnel. In this section, the term "SR P2MP" refers to both SR-MPLS and SRv6 data planes.
[RFC6514] は、特定の MVPN に参加している PE を検出し、顧客のマルチキャスト フローを特定の P トンネルにバインドする手順を定義しています。このセクションでは、SR P2MP P トンネルのこれらの手順の変更について説明します。Intra-AS I-PMSI、Inter-AS I-PMSI、および S-PMSI A-D ルートには、SR P2MP ツリー P トンネルを指定する PTA があります。このセクションでは、「SR P2MP」という用語は SR-MPLS と SRv6 データ プレーンの両方を指します。
A PTA for an SR P2MP P-tunnel is constructed as specified below.
SR P2MP P トンネルの PTA は、以下に指定されているように構築されます。
* Tunnel Type: One of the following SR P2MP P-tunnel types (from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry).
* トンネル タイプ: 次の SR P2MP P トンネル タイプのいずれか (「P-マルチキャスト サービス インターフェイス トンネル (PMSI トンネル) トンネル タイプ」レジストリから)。
- 0x0C for SR-MPLS P2MP Tree
- SR-MPLS P2MP ツリーの場合は 0x0C
- 0x0D for SRv6 P2MP Tree
- SRv6 P2MP ツリーの場合は 0x0D
* Flags: See Section 3.2.2 for use of the "Leaf Information Required" flag.
* フラグ: 「リーフ情報が必要」フラグの使用については、セクション 3.2.2 を参照してください。
* MPLS Label: See Section 4.1.1.1.
* MPLS ラベル: セクション 4.1.1.1 を参照してください。
* Tunnel Identifier: The SR P2MP P-tunnel identifies an SR P2MP Policy with the identifier <Root, Tree-ID> [RFC9960] encoded in the exact order below:
* トンネル識別子: SR P2MP P トンネルは、以下の正確な順序でエンコードされた識別子 <Root, Tree-ID> [RFC9960] を使用して SR P2MP ポリシーを識別します。
- Tree-ID: A 32-bit unsigned value that uniquely identifies an SR P2MP Policy at the Root.
- Tree-ID: ルートで SR P2MP ポリシーを一意に識別する 32 ビットの符号なしの値。
- Root: An IP address identifying the Root of the SR P2MP Policy. This can be either an IPv4 or IPv6 address. The address type can be inferred from the PTA length.
- ルート: SR P2MP ポリシーのルートを識別する IP アドレス。これは、IPv4 アドレスまたは IPv6 アドレスのいずれかになります。アドレスのタイプは PTA の長さから推測できます。
A PTA with a SR P2MP P-tunnel is provisioned with the Tunnel Type for SR-MPLS or SRv6 P2MP trees. An implementation SHOULD advertise a PTA with SR P2MP P-tunnel only when the underlying SR-MPLS or SRv6 data plane is supported. The procedures for provisioning and determination of data plane support for SR-MPLS or SRv6 are outside scope of this document.
SR P2MP P トンネルを備えた PTA は、SR-MPLS または SRv6 P2MP ツリーのトンネル タイプでプロビジョニングされます。実装では、基盤となる SR-MPLS または SRv6 データ プレーンがサポートされている場合にのみ、SR P2MP P トンネルを使用して PTA をアドバタイズする必要があります (SHOULD)。SR-MPLS または SRv6 のデータ プレーン サポートのプロビジョニングと決定の手順は、このドキュメントの範囲外です。
A P-tunnel can be segmented or non-segmented (see Section 8 of [RFC6513]). When a P-tunnel is non-segmented, the PTA is created by PE router at the Root of an SR P2MP tree. For segmented P-tunnels, each segment can be instantiated by a different P-tunnel type. If a segment is instantiated using a P2MP tree, the router at the Root of an SR P2MP tree creates the PTA.
P トンネルはセグメント化することも、セグメント化しないこともできます ([RFC6513] のセクション 8 を参照)。P トンネルがセグメント化されていない場合、PTA は SR P2MP ツリーのルートにある PE ルーターによって作成されます。セグメント化された P トンネルの場合、各セグメントは異なる P トンネル タイプによってインスタンス化できます。P2MP ツリーを使用してセグメントがインスタンス化される場合、SR P2MP ツリーのルートにあるルーターが PTA を作成します。
When an SR P2MP P-tunnel is not shared across MVPNs, i.e., there is one-to-one association between an MVPN instance and an SR P2MP P-tunnel, the MPLS Label field is set to zero as per [RFC6514] for both SR-MPLS and SRv6. In this case, the SR-MPLS or SRv6 Tree-SID of the PTI of the SR P2MP Policy advertised in the P-tunnel is sufficient to identify the MVPN instance for delivering the payload.
SR P2MP P トンネルが MVPN 間で共有されていない場合、つまり、MVPN インスタンスと SR P2MP P トンネルの間に 1 対 1 の関連付けがある場合、MPLS ラベル フィールドは、SR-MPLS と SRv6 の両方について [RFC6514] に従ってゼロに設定されます。この場合、ペイロードを配信する MVPN インスタンスを識別するには、P トンネルでアドバタイズされる SR P2MP ポリシーの PTI の SR-MPLS または SRv6 ツリー SID で十分です。
[RFC6514] allows a PE to aggregate two or more MVPNs onto one SR P2MP P-tunnel by advertising the same P-tunnel in PTA of A-D routes of different MVPNs. In this case, the MPLS Label field of the PTA is filled to provide a context bound to a specific MVPN instance as described in sections below. The value in this field is used by egress PEs to identify the MVPN instance for delivering the payload encapsulated in SR-MPLS or SRv6.
[RFC6514] では、異なる MVPN の A-D ルートの PTA で同じ P トンネルをアドバタイズすることにより、PE が 2 つ以上の MVPN を 1 つの SR P2MP P トンネルに集約することができます。この場合、以下のセクションで説明するように、PTA の MPLS ラベル フィールドに値が入力されて、特定の MVPN インスタンスにバインドされたコンテキストが提供されます。このフィールドの値は、SR-MPLS または SRv6 でカプセル化されたペイロードを配信するための MVPN インスタンスを識別するために出力 PE によって使用されます。
When an SR P2MP P-tunnel is shared across two or more MVPNs in an SR-MPLS domain, the MPLS Label field of a PTA advertised in an A-D route MUST contain an upstream-assigned MPLS label [RFC5331] [RFC6513] or a label assigned from a global context, such as the Domain-wide Common Block (DCB) as specified in [RFC9573], that the advertising PE has bound to the MVPN.
SR P2MP P トンネルが SR-MPLS ドメイン内の 2 つ以上の MVPN 間で共有されている場合、A-D ルートでアドバタイズされる PTA の MPLS ラベル フィールドには、アップストリームで割り当てられた MPLS ラベル [RFC5331] [RFC6513]、またはアドバタイジング PE がバインドしている、[RFC9573] で指定されているドメイン全体の共通ブロック (DCB) などのグローバル コンテキストから割り当てられたラベルが含まれなければなりません (MUST)。MVPN。
When an ingress PE steers the payload into a shared SR P2MP P-tunnel PTI, this MPLS label MUST be imposed before the MPLS label representing the Tree-SID. The trade-off of sharing an SR P2MP P-tunnel across MVPNs is that two MPLS labels have to be imposed on ingress and disposed on egress.
入力 PE がペイロードを共有 SR P2MP P トンネル PTI に誘導する場合、この MPLS ラベルは、Tree-SID を表す MPLS ラベルの前に適用されなければなりません (MUST)。MVPN 間で SR P2MP P トンネルを共有する場合のトレードオフは、2 つの MPLS ラベルを入力時に適用し、出力時に破棄する必要があることです。
The egress PEs of a shared SR P2MP P-tunnel use the MPLS label to determine the MVPN instance for delivering the payload.
共有 SR P2MP P トンネルの出力 PE は、MPLS ラベルを使用して、ペイロードを配信するための MVPN インスタンスを決定します。
When an SR P2MP P-tunnel is shared across two or more MVPNs in an SRv6 domain [RFC8986], the MPLS Label field of a PTA advertised in an A-D route MUST contain an upstream-assigned SRv6 Multicast Service SID (Section 3.1) that the advertising PE has bound to the MVPN or an SRv6 Multicast Service SID assigned from a global context; this follows same concept of the DCB label as specified in [RFC9573]. The high-order 20 bits of the MPLS Label field carry the whole or a portion of the Function part of the SRv6 Multicast Service SID when the Transposition Scheme of encoding as defined in [RFC9252] is used. When using the Transposition Scheme, the Transposition Length of the SRv6 SID Structure Sub-Sub-TLV of the SRv6 Prefix-SID attribute (see below) MUST be less than or equal to 20 and less than or equal to the Function Length. When the Transposition Scheme is not used, the MPLS Label field MUST be set to zero as per [RFC6514], and Transposition Length MUST be zero.
SR P2MP P トンネルが SRv6 ドメイン [RFC8986] 内の 2 つ以上の MVPN で共有されている場合、A-D ルートでアドバタイズされる PTA の MPLS ラベル フィールドには、アドバタイジング PE が MVPN にバインドしたアップストリームで割り当てられた SRv6 マルチキャスト サービス SID (セクション 3.1)、またはグローバル コンテキストから割り当てられた SRv6 マルチキャスト サービス SID が含まれなければなりません (MUST)。これは、[RFC9573] で指定されている DCB ラベルと同じ概念に従います。[RFC9252] で定義されている符号化の転置スキームが使用される場合、MPLS ラベル フィールドの上位 20 ビットは、SRv6 マルチキャスト サービス SID の機能部分の全体または一部を伝送します。転置スキームを使用する場合、SRv6 プレフィックス SID 属性の SRv6 SID 構造サブサブ TLV の転置長 (以下を参照) は 20 以下であり、関数の長さ以下でなければなりません。転置スキームが使用されない場合、MPLS ラベル フィールドは [RFC6514] に従ってゼロに設定されなければならず、転置長もゼロでなければなりません。
The advertising ingress PE MUST attach a BGP Prefix-SID attribute [RFC8669] to Intra-AS I-PMSI, Inter-AS I-PMSI, or S-PMSI A-D routes with the SRv6 L3 Service TLV [RFC9252] to signal the SRv6 Multicast Service SID. The SRv6 SID Information Sub-TLV carries the SRv6 Multicast Service SID in the SRv6 SID Value field. The SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV encodes one of End.DTMC4, End.DTMC6, or End.DTMC46 code point values. The SRv6 SID Structure Sub-Sub-TLV encodes the structure of the SRv6 Multicast Service SID. If the Transposition Scheme is used, the offset and length of SRv6 Multicast Endpoint function of the SRv6 Multicast Service SID is set in the Transposition Length and Transposition Offset fields of this sub-sub-TLV. Otherwise, the Transposition Length and Offset fields MUST be set to zero. The locator (LOC) of an SRv6 Multicast Service SID, which is assigned from a global context, such as DCB, is outside the scope of this document.
アドバタイジングイングレス PE は、SRv6 マルチキャスト サービス SID を通知するために、SRv6 L3 サービス TLV [RFC9252] を使用して、BGP プレフィックス SID 属性 [RFC8669] を AS 内 I-PMSI、AS 間 I-PMSI、または S-PMSI A-D ルートに付加しなければなりません (MUST)。SRv6 SID 情報サブ TLV は、SRv6 SID 値フィールドで SRv6 マルチキャスト サービス SID を伝送します。SRv6 SID 情報サブ TLV の SRv6 エンドポイント動作は、End.DTMC4、End.DTMC6、または End.DTMC46 コード ポイント値のいずれかをエンコードします。SRv6 SID 構造サブサブ TLV は、SRv6 マルチキャスト サービス SID の構造をエンコードします。転置スキームが使用される場合、SRv6 マルチキャスト サービス SID の SRv6 マルチキャスト エンドポイント機能のオフセットと長さは、このサブサブ TLV の転置長フィールドと転置オフセット フィールドに設定されます。それ以外の場合は、移調長フィールドとオフセット フィールドをゼロに設定しなければなりません。DCB などのグローバル コンテキストから割り当てられる SRv6 マルチキャスト サービス SID のロケーター (LOC) は、このドキュメントの範囲外です。
The advertising ingress PE, which is the Root node of the shared SR P2MP P-tunnel, MUST encapsulate a payload in an outer IPv6 header with an SRH in which the SRv6 Multicast Service SID MUST be the last segment in the segment list (note the SRv6 Multicast Service SID may be the only segment in the SRH). If the Transposition Scheme is used, the ingress PE MUST merge the Function part of the MPLS Label field of the PTA with the SRv6 SID in the SRv6 SID Information Sub-TLV using the Transposition Offset and Length fields from the SRv6 SID Structure Sub-Sub-TLV to create the SRv6 Multicast Service SID.
共有 SR P2MP P トンネルのルート ノードであるアドバタイジングイングレス PE は、SRv6 マルチキャスト サービス SID がセグメント リストの最後のセグメントでなければならない (SRv6 マルチキャスト サービス SID が SRH 内の唯一のセグメントである可能性があることに注意してください)。転置スキームが使用される場合、入力 PE は、SRv6 SID 構造サブサブ TLV からの転置オフセットおよび長さフィールドを使用して、PTA の MPLS ラベル フィールドの機能部分と SRv6 SID 情報サブ TLV の SRv6 SID をマージし、SRv6 マルチキャスト サービス SID を作成しなければなりません。
An egress PE of the shared SR P2MP P-tunnel uses the SRv6 Multicast Service SID in the SRH to determine the MVPN instance in which the customer payload is to be delivered. The egress PE, in the role of Leaf or Bud node of the Replication segment associated with the shared SR P2MP P-tunnel tree, uses the "look at next SID in SRH" behavior [RFC9524] to process the SRv6 Multicast Service SID. An egress PE MUST NOT install the SRv6 Multicast Service SID in its Forwarding Information Base (FIB), i.e., it MUST NOT forward packets based on the Locator portion of the SRv6 Multicast Service SID because the SID is not significant on the ingress PE.
共有 SR P2MP P トンネルの出力 PE は、SRH 内の SRv6 マルチキャスト サービス SID を使用して、顧客ペイロードが配信される MVPN インスタンスを決定します。共有 SR P2MP P トンネル ツリーに関連付けられたレプリケーション セグメントのリーフ ノードまたはバッド ノードの役割を持つ出力 PE は、「SRH の次の SID を確認する」動作 [RFC9524] を使用して SRv6 マルチキャスト サービス SID を処理します。出力 PE は、SRv6 マルチキャスト サービス SID をその転送情報ベース (FIB) にインストールしてはなりません。つまり、SID は入力 PE では重要ではないため、SRv6 マルチキャスト サービス SID のロケーター部分に基づいてパケットを転送してはなりません (MUST NOT)。
MVPN A-D procedures specified in [RFC6514] are used to advertise an SR P2MP P-tunnel and discover the Leaf nodes of the SR P2MP Policy associated with the P-tunnel. This section describes the processing of MVPN A-D routes to create, update, and tear down an SR P2MP Policy of an SR P2MP P-tunnel as described in Section 2.
[RFC6514] で指定されている MVPN A-D プロシージャは、SR P2MP P トンネルをアドバタイズし、P トンネルに関連付けられた SR P2MP ポリシーのリーフ ノードを検出するために使用されます。このセクションでは、セクション 2 で説明したように、SR P2MP P トンネルの SR P2MP ポリシーを作成、更新、破棄するための MVPN A-D ルートの処理について説明します。
A PE interacts with an SR P2MP Policy module to create a CP, with optional traffic engineering constraints and an optional optimization objective, of an SR P2MP Policy when it originates an Intra-AS I-PMSI A-D route [RFC6514], an Inter-AS I-PMSI A-D route for an intra-AS segment [RFC6514], an S-PMSI A-D route [RFC6514], or a "wildcard" S-PMSI A-D route [RFC6625] with a PTA that has an SR P2MP P-tunnel type.
PE は、AS イントラ AS I-PMSI A-D ルート [RFC6514]、AS 内セグメントの Inter-AS I-PMSI A-D ルート [RFC6514]、S-PMSI A-D ルート [RFC6514]、またはSR P2MP P トンネル タイプを持つ PTA を使用した「ワイルドカード」S-PMSI A-D ルート [RFC6625]。
The CP of the SR P2MP Policy associated with an SR P2MP P-tunnel is deleted from the SR P2MP Policy module when a PE withdraws the Intra-AS I-PMSI, Inter-AS I-PMSI, or S-PMSI A-D route advertising that P-tunnel.
SR P2MP P トンネルに関連付けられた SR P2MP ポリシーの CP は、PE がその P トンネルをアドバタイズする Intra-AS I-PMSI、Inter-AS I-PMSI、または S-PMSI A-D ルートを取り消すときに、SR P2MP ポリシー モジュールから削除されます。
When a PE originates an Inter-AS I-PMSI or an S-PMSI A-D route with a PTA that has an SR P2MP P-tunnel type, it MUST set the "Leaf Information Required" flag in the PTA.
PE が SR P2MP P トンネル タイプを持つ PTA を使用して Inter-AS I-PMSI または S-PMSI A-D ルートを開始する場合、PE は PTA に「リーフ情報が必要」フラグを設定しなければなりません。
An ingress PE that advertises an MVPN A-D route with a PTA that has an SR P2MP P-tunnel type discovers a Leaf node of the SR P2MP Policy associated with the SR P2MP P-tunnel when it imports an Intra-AS I-PMSI A-D route [RFC6514] or Leaf A-D route [RFC6514] from an egress PE. The ingress PE adds the egress PE as a Leaf node in the SR P2MP Policy module.
SR P2MP P トンネル タイプを持つ PTA で MVPN A-D ルートをアドバタイズする入力 PE は、出力 PE から Intra-AS I-PMSI A-D ルート [RFC6514] またはリーフ A-D ルート [RFC6514] をインポートするときに、SR P2MP P トンネルに関連付けられた SR P2MP ポリシーのリーフ ノードを検出します。入力 PE は、出力 PE を SR P2MP ポリシー モジュールのリーフ ノードとして追加します。
An ingress PE removes an egress PE from the Leaf set of the SR P2MP Policy when the egress PE withdraws the Intra-AS I-PMSI or the Leaf A-D route.
入力 PE は、出力 PE が Intra-AS I-PMSI またはリーフ A-D ルートを取り消すと、SR P2MP ポリシーのリーフ セットから出力 PE を削除します。
An egress PE informs the SR P2MP Policy module to join the SR P2MP Policy as a Leaf or Bud node when it imports an Intra-AS I-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an S-PMSI A-D route from an ingress PE that has a PTA with an SR P2MP P-tunnel type. The egress PE MUST originate a Leaf A-D route if the "Leaf Information Required" flag is set in the PTA.
出力 PE は、SR P2MP P トンネル タイプの PTA を持つ入力 PE から AS 内 I-PMSI A-D ルート、AS 間 I-PMSI A-D ルート、または S-PMSI A-D ルートをインポートするときに、SR P2MP ポリシー モジュールにリーフ ノードまたはバッド ノードとして SR P2MP ポリシーに参加するように通知します。PTA で「リーフ情報が必要」フラグが設定されている場合、出力 PE はリーフ A-D ルートを開始しなければなりません (MUST)。
An egress PE withdraws itself as a Leaf or Bud node of the SR P2MP Policy when the ingress PE withdraws an Intra-AS I-PMSI, Inter-AS I-PMSI, or S-PMSI A-D route. The egress PE MUST withdraw the Leaf A-D it had originated earlier in response to the "Leaf Information Required" flag in the PTA.
入力 PE が AS 内 I-PMSI、AS 間 I-PMSI、または S-PMSI A-D ルートを撤回すると、出力 PE は SR P2MP ポリシーのリーフ ノードまたはバッド ノードとして自身を撤回します。出口 PE は、PTA の「リーフ情報が必要」フラグに応答して、以前に発信したリーフ A ～ D を取り消さなければなりません (MUST)。
A PE can provide MVPN service using IR over SR. The payload is encapsulated in SR-MPLS or SRv6 at an ingress PE and replicated with each copy sent to an egress PE via unicast.
PE は、IR over SR を使用して MVPN サービスを提供できます。ペイロードは入力 PE で SR-MPLS または SRv6 にカプセル化され、ユニキャスト経由で出力 PE に送信される各コピーとともに複製されます。
"Ingress Replication Tunnels in Multicast VPN" [RFC7988] specifies procedures that can be reused to provide MVPN service with IR in an SR domain. A PE advertises Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, or Selective PMSI A-D and Leaf A-D routes with the PTA for IR. Egress PEs join as Leaf nodes using Intra-AS I-PMSI A-D or Leaf A-D routes. The procedures of [RFC7988] provide an MVPN IR service with best-effort unicast connectivity.
「マルチキャスト VPN の入力レプリケーション トンネル」[RFC7988] は、SR ドメインで IR を使用して MVPN サービスを提供するために再利用できる手順を指定しています。PE は、IR 用の PTA を使用して、AS 内 I-PMSI A-D、AS 間 I-PMSI A-D、または選択 PMSI A-D およびリーフ A-D ルートをアドバタイズします。出力 PE は、Intra-AS I-PMSI A-D またはリーフ A-D ルートを使用してリーフ ノードとして参加します。[RFC7988] の手順は、ベストエフォート型のユニキャスト接続を備えた MVPN IR サービスを提供します。
This document adds procedures for providing an MVPN IR service with an SLA from an ingress PE to an egress PE both for SR-MPLS and SRv6. This document extends the BGP Update message of AFI/SAFI 1/129 (MVPN-IPv4) and 2/129 (MVPN-IPv6) to carry the Color Extended Community as specified in [RFC9012] and the Color-Only Type extension specified in Section 3 of [RFC9830]. An egress PE colors the Leaf or Intra-AS I-PMSI A-D route with a Color Extended Community. The ingress PE replicates MVPN customer payload to the egress PE by steering it into an SR-TE policy according to Section 8 of [RFC9256]. The ingress PE encapsulates the payload packet into a segment list of the matching SR-TE policy to the egress PE along with the IR MPLS label or SRv6 Multicast Service SID received from the egress PE.
このドキュメントでは、SR-MPLS と SRv6 の両方について、入力 PE から出力 PE への SLA を備えた MVPN IR サービスを提供する手順を追加します。この文書は、AFI/SAFI 1/129 (MVPN-IPv4) および 2/129 (MVPN-IPv6) の BGP アップデート メッセージを拡張して、[RFC9012] で指定されているカラー拡張コミュニティと、[RFC9830] のセクション 3 で指定されているカラー専用タイプ拡張を伝送します。出力 PE は、カラー拡張コミュニティを使用してリーフまたはイントラ AS I-PMSI A-D ルートを色付けします。入力 PE は、[RFC9256] のセクション 8 に従って SR-TE ポリシーにステアリングすることにより、MVPN 顧客ペイロードを出力 PE に複製します。入力 PE は、出力 PE から受信した IR MPLS ラベルまたは SRv6 マルチキャスト サービス SID とともに、出力 PE に一致する SR-TE ポリシーのセグメント リストにペイロード パケットをカプセル化します。
Note that the Color Extended Community is not used with an MVPN SR P2MP P-tunnel. For MVPN with an SR P2MP P-tunnel, the ingress PE dictates the traffic engineering treatment by specifying the constraints and the metric optimization in the CP of the SR P2MP Policy corresponding to the P-tunnel on the ingress PE. This is necessary because packets are replicated in the PTI; therefore, it is not possible to have differing traffic engineering treatment towards each egress PE (Leaf node) of the PTI.
カラー拡張コミュニティは MVPN SR P2MP P トンネルでは使用されないことに注意してください。SR P2MP P トンネルを備えた MVPN の場合、入力 PE は、入力 PE の P トンネルに対応する SR P2MP ポリシーの CP で制約とメトリック最適化を指定することにより、トラフィック エンジニアリング処理を指示します。これは、パケットが PTI で複製されるため必要です。したがって、PTI の各出力 PE (リーフ ノード) に対して異なるトラフィック エンジニアリング処理を行うことはできません。
The PTA carried in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, S-PMSI A-D, and Leaf A-D routes is constructed as specified in [RFC7988].
AS 内 I-PMSI A-D、AS 間 I-PMSI A-D、S-PMSI A-D、およびリーフ A-D ルートで伝送される PTA は、[RFC7988] で指定されているように構築されます。
MVPN IR service with SLA over SR-MPLS data plane can be provided by using the Color Extended Community as described above. Suppose an egress PE, say PE2, sends Leaf A-D route with Extended Color Community C1 with Color-Only Type 0 and IR label L10 to the ingress PE1. Assume the segment list of SR-TE policy (C1, PE2) at ingress PE1 is <L1, L2, L3>. PE1 will encapsulate the MVPN payload into the MPLS label stack <L1, L2, L3, L10> with L10 as the Bottom-of-Stack (BoS) label.
SR-MPLS データ プレーン上の SLA を備えた MVPN IR サービスは、前述のように Color Extended Community を使用して提供できます。出力 PE (PE2 など) が、カラー専用タイプ 0 および IR ラベル L10 を持つ拡張カラー コミュニティ C1 を持つリーフ A-D ルートを入力 PE1 に送信するとします。入力 PE1 の SR-TE ポリシー (C1、PE2) のセグメント リストが <L1、L2、L3> であると仮定します。PE1 は、L10 をスタックのボトム (BoS) ラベルとして使用して、MVPN ペイロードを MPLS ラベル スタック <L1、L2、L3、L10> にカプセル化します。
The procedures specified in [RFC7988], with the modifications defined in this section, are used to provide MVPN IR service over SRv6.
[RFC7988] で指定されている手順とこのセクションで定義されている変更は、SRv6 経由で MVPN IR サービスを提供するために使用されます。
The PTA carried in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, Selective PMSI A-D, and Leaf A-D routes is constructed as specified in [RFC7988] with the following modifications:
Intra-AS I-PMSI A-D、Inter-AS I-PMSI A-D、Selective PMSI A-D、Leaf A-D ルートで伝送される PTA は、[RFC7988] で規定されているように構築されますが、次の変更が加えられます。
* Tunnel Type: "Ingress Replication" as per [RFC6514].
* トンネル タイプ: [RFC6514] による「イングレス レプリケーション」。
* MPLS Label: The high-order 20 bits of this field carry the whole or a portion of the Function part of the SRv6 Multicast Service SID when the Transposition Scheme is used for encoding as defined in [RFC9252]. When using the Transposition Scheme, the Transposition Length of the SRv6 SID Structure Sub-Sub-TLV of the SRv6 Prefix-SID attribute (see below) MUST be less than or equal to 20 and less than or equal to the Function Length. When the Transposition Scheme is not used, the MPLS Label field MUST be set to zero, and Transposition Length MUST be zero.
* MPLS ラベル: [RFC9252] で定義されているように、転置スキームがエンコードに使用される場合、このフィールドの上位 20 ビットは、SRv6 マルチキャスト サービス SID の機能部分の全体または一部を伝送します。転置スキームを使用する場合、SRv6 プレフィックス SID 属性の SRv6 SID 構造サブサブ TLV の転置長 (以下を参照) は 20 以下であり、関数の長さ以下でなければなりません。転置スキームが使用されない場合、MPLS ラベル フィールドは 0 に設定されなければならず、転置長も 0 に設定されなければなりません。
Sections 6 and 7 of [RFC7988] describe considerations and procedures for allocating MPLS labels for IR P-tunnels. These considerations also apply to allocation of a SRv6 Multicast Service SID for SRv6 IR.
[RFC7988] のセクション 6 および 7 では、IR P トンネルに MPLS ラベルを割り当てるための考慮事項と手順について説明しています。これらの考慮事項は、SRv6 IR の SRv6 マルチキャスト サービス SID の割り当てにも当てはまります。
To join an SRv6 IR P-tunnel advertised in the PTA of Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, or Selective S-PMSI A-D routes, an egress PE constructs a Leaf A-D or Intra-AS I-PMSI A-D route as described in [RFC7988] with the modified PTA above. The egress PE MUST attach a BGP Prefix-SID attribute [RFC8669] with a Leaf A-D or Intra-AS I-PMSI A-D route with the SRv6 L3 Service TLV [RFC9252] to signal the SRv6 Multicast Service SID (Section 3.1). The SRv6 SID Information Sub-TLV carries the SRv6 Multicast Service SID in the SRv6 SID Value field. The SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV MUST encode one of the End.DTMC4, End.DTMC6, or End.DTMC46 code point values. The SRv6 SID Structure Sub-Sub-TLV encodes the structure of the SRv6 Multicast Service SID. If the Transposition Scheme is used, the offset and length of SRv6 Multicast Endpoint function of the SRv6 Multicast Service SID is set in the Transposition Length and Transposition Offset fields of this sub-sub-TLV. Otherwise, the Transposition Length and Offset fields MUST be set to zero. The BGP Prefix SID attribute with the SRv6 L3 Service TLV in an Intra-AS I-PMSI or Leaf A-D route indicates to the ingress PE that the egress PE supports SRv6.
Intra-AS I-PMSI A-D、Inter-AS I-PMSI A-D、または Selective S-PMSI A-D ルートの PTA でアドバタイズされた SRv6 IR P トンネルに参加するには、出力 PE は、[RFC7988] で説明されているように、上記の修正された PTA を使用して Leaf A-D または Intra-AS I-PMSI A-D ルートを構築します。出力 PE は、SRv6 マルチキャスト サービス SID (セクション 3.1) を通知するために、リーフ A-D またはイントラ AS I-PMSI A-D ルートに SRv6 L3 サービス TLV [RFC9252] を持つ BGP プレフィックス SID 属性 [RFC8669] を付加しなければなりません (MUST)。SRv6 SID 情報サブ TLV は、SRv6 SID 値フィールドで SRv6 マルチキャスト サービス SID を伝送します。SRv6 SID 情報サブ TLV の SRv6 エンドポイント動作は、End.DTMC4、End.DTMC6、または End.DTMC46 コード ポイント値のいずれかをエンコードする必要があります。SRv6 SID 構造サブサブ TLV は、SRv6 マルチキャスト サービス SID の構造をエンコードします。転置スキームが使用される場合、SRv6 マルチキャスト サービス SID の SRv6 マルチキャスト エンドポイント機能のオフセットと長さは、このサブサブ TLV の転置長フィールドと転置オフセット フィールドに設定されます。それ以外の場合は、移調長フィールドとオフセット フィールドをゼロに設定しなければなりません。Intra-AS I-PMSI またはリーフ A-D ルート内の SRv6 L3 サービス TLV を含む BGP プレフィックス SID 属性は、出力 PE が SRv6 をサポートしていることを入力 PE に示します。
The SRv6 Multicast Service SID MUST be routable within the AS of the egress PE. As per [RFC7988], the ingress PE uses the Tunnel Identifier of PTA to determine the unicast tunnel to use in order to send data to the egress PE. For SRv6 IR, the ingress PE MUST use the SRv6 Multicast Service SID to determine the unicast tunnel to be used. For best-effort MVPN IR service or SLA-based MVPN IR service using the IGP Flexible Algorithm, the ingress PE MUST encapsulate the payload in an outer IPv6 header, with the SRv6 Multicast Service SID provided by the egress PE used as the destination address. If the Transposition Scheme is used, the ingress PE MUST merge the Function part of the MPLS Label field of the PTA with SRv6 SID in the SRv6 SID Information Sub-TLV using the Transposition Offset and Length fields from the SRv6 SID Structure Sub-Sub-TLV to create the SRv6 Multicast Service SID.
SRv6 マルチキャスト サービス SID は、出力 PE の AS 内でルーティング可能でなければなりません。[RFC7988] に従って、入力 PE は PTA のトンネル識別子を使用して、出力 PE にデータを送信するために使用するユニキャスト トンネルを決定します。SRv6 IR の場合、入力 PE は SRv6 マルチキャスト サービス SID を使用して、使用するユニキャスト トンネルを決定する必要があります。IGP フレキシブル アルゴリズムを使用したベスト エフォート MVPN IR サービスまたは SLA ベースの MVPN IR サービスの場合、入力 PE は、出力 PE によって提供される SRv6 マルチキャスト サービス SID を宛先アドレスとして使用して、外側の IPv6 ヘッダーにペイロードをカプセル化する必要があります。転置スキームが使用される場合、入力 PE は、SRv6 SID 構造サブサブ TLV からの転置オフセットおよび長さフィールドを使用して、PTA の MPLS ラベル フィールドの機能部分を SRv6 SID 情報サブ TLV の SRv6 SID とマージし、SRv6 マルチキャスト サービス SID を作成しなければなりません。
MVPN IR service with SLA over SRv6 can be provided by using the Color Extended Community as described above. Suppose an egress PE, say PE2, sends Leaf A-D route with Extended Color community C1 with Color-Only Type 0 and SRv6 Multicast Service SID S10 to ingress PE1. Assume the segment list of the SR-TE policy (C1, PE2) at ingress PE1 is <S1, S2, S3>. PE1 will encapsulate a payload into an IPv6 header with SRH (PE1, S1) (S10, S3, S2; SL=3) (payload).
SRv6 を介した SLA を備えた MVPN IR サービスは、前述のように Color Extended Community を使用して提供できます。出力 PE (PE2 など) が、カラー専用タイプ 0 および SRv6 マルチキャスト サービス SID S10 を持つ拡張カラー コミュニティ C1 を持つリーフ A-D ルートを入力 PE1 に送信するとします。入力 PE1 の SR-TE ポリシー (C1、PE2) のセグメント リストが <S1、S2、S3> であると仮定します。PE1 は、SRH (PE1、S1) (S10、S3、S2; SL=3) (ペイロード) を使用してペイロードを IPv6 ヘッダーにカプセル化します。
BGP MPLS-Based EVPN, specified in [RFC7432], specifies the IMET route to support BUM traffic. This IMET route is the equivalent of the MVPN Intra-AS I-PMSI route and is advertised with a PTA as specified in [RFC6514] to advertise the inclusive P-tunnels. [RFC9252] specifies procedures for IMET routes with IR over SRv6.
[RFC7432] で規定されている BGP MPLS ベースの EVPN は、BUM トラフィックをサポートするための IMET ルートを指定します。この IMET ルートは MVPN Intra-AS I-PMSI ルートと同等であり、包括的な P トンネルをアドバタイズするために [RFC6514] で指定されているように PTA でアドバタイズされます。[RFC9252] は、SRv6 上の IR を使用した IMET ルートの手順を規定しています。
[RFC9572] updates the EVPN BUM procedures to support selective P-tunnels. It defines new BGP route types that are advertised with a PTA, including the S-PMSI A-D and Leaf A-D routes. The S-PMSI and Leaf A-D routes of [RFC9572] are analogous to MVPN S-PMSI and Leaf A-D routes [RFC6514]. Note that support of Inter-AS and Inter-Region segmentation procedures in [RFC9572] with SR P2MP P-tunnels are out of scope of this document.
[RFC9572] は、選択的 P トンネルをサポートするために EVPN BUM 手順を更新します。S-PMSI A-D ルートやリーフ A-D ルートなど、PTA でアドバタイズされる新しい BGP ルート タイプを定義します。[RFC9572] の S-PMSI およびリーフ A-D ルートは、MVPN S-PMSI およびリーフ A-D ルート [RFC6514] に類似しています。SR P2MP P トンネルを使用した [RFC9572] の Inter-AS および Inter-Region セグメンテーション手順のサポートは、この文書の範囲外であることに注意してください。
Inclusive and selective P-tunnels can be instantiated using SR P2MP trees or IR over SR.
包括的かつ選択的な P トンネルは、SR P2MP ツリーまたは IR over SR を使用してインスタンス化できます。
This section specifies modifications to procedures of [RFC7432] and [RFC9572] for SR P2MP P-tunnels. The IMET, S-PMSI, and Leaf A-D routes have the PTA that specifies the SR P2MP tree P-tunnel. In this section, the term "SR P2MP" refers to both SR-MPLS and SRv6 data planes.
このセクションでは、SR P2MP P トンネル用の [RFC7432] および [RFC9572] の手順の変更を指定します。IMET、S-PMSI、およびリーフ A-D ルートには、SR P2MP ツリー P トンネルを指定する PTA があります。このセクションでは、「SR P2MP」という用語は SR-MPLS と SRv6 データ プレーンの両方を指します。
A PTA for an SR P2MP P-tunnel is constructed as specified in Section 3.2.1, except the MPLS Label and Flags fields are filled as specified in Sections 4.1.1.1 and 4.1.3, respectively.
SR P2MP P トンネルの PTA は、MPLS ラベル フィールドとフラグ フィールドがそれぞれセクション 4.1.1.1 および 4.1.3 の指定に従って入力されることを除き、セクション 3.2.1 の指定に従って構築されます。
When an SR P2MP P-tunnel is not shared across MVPNs, i.e., there is one-to-one association between an EVI and an SR P2MP P-tunnel, the MPLS Label field is set to zero as per [RFC6514]. In this case, the SR-MPLS Tree-SID of the PTI of the SR P2MP Policy advertised in the P-tunnel is sufficient to identify the MVPN instance for delivering the payload.
SR P2MP P トンネルが MVPN 間で共有されていない場合、つまり、EVI と SR P2MP P トンネルの間に 1 対 1 の関連付けがある場合、MPLS ラベル フィールドは [RFC6514] に従って 0 に設定されます。この場合、P トンネルでアドバタイズされる SR P2MP ポリシーの PTI の SR-MPLS ツリー SID は、ペイロードを配信するための MVPN インスタンスを識別するのに十分です。
[RFC7432] and [RFC9572] allow a PE to aggregate two or more EVIs onto one SR P2MP P-tunnel by advertising the same P-tunnel in the PTA of A-D routes of different EVIs. When an SR P2MP P-tunnel is shared across two or more EVIs in an SR-MPLS domain, the MPLS Label field of a PTA advertised in an EVPN A-D route MUST contain an upstream-assigned MPLS label [RFC5331] [RFC6513] or a label assigned from a global context, such as DCB as specified in [RFC9573], that the advertising PE has bound to the EVI. The egress PE uses this label as context to identify the specific EVI for delivering the EVPN payload encapsulated in SR-MPLS. When an ingress PE steers the payload into a shared SR P2MP P-tunnel PTI, this MPLS label MUST be imposed before the MPLS label representing the Tree-SID.
[RFC7432] および [RFC9572] では、異なる EVI の A-D ルートの PTA で同じ P トンネルをアドバタイズすることにより、PE が 2 つ以上の EVI を 1 つの SR P2MP P トンネルに集約できます。SR P2MP P トンネルが SR-MPLS ドメイン内の 2 つ以上の EVI 間で共有されている場合、EVPN A-D ルートでアドバタイズされる PTA の MPLS ラベル フィールドには、アップストリームで割り当てられた MPLS ラベル [RFC5331] [RFC6513]、またはアドバタイジング PE が EVI にバインドした、[RFC9573] で指定されている DCB などのグローバル コンテキストから割り当てられたラベルが含まれなければなりません。出力 PE は、このラベルをコンテキストとして使用して、SR-MPLS でカプセル化された EVPN ペイロードを配信するための特定の EVI を識別します。入力 PE がペイロードを共有 SR P2MP P トンネル PTI に誘導する場合、この MPLS ラベルは、Tree-SID を表す MPLS ラベルの前に適用されなければなりません (MUST)。
For SRv6 P2MP, an EVI is identified by an SRv6 SID encoded in the SRH of an IPv6-encapsulated packet from the ingress PE as described later in this section. This is required even if the SR P2MP P-tunnel is not shared across EVIs.
SRv6 P2MP の場合、EVI は、このセクションで後述するように、入力 PE からの IPv6 カプセル化パケットの SRH でエンコードされた SRv6 SID によって識別されます。これは、SR P2MP P トンネルが EVI 間で共有されていない場合でも必要です。
The advertising ingress PE MUST attach a BGP Prefix-SID attribute [RFC8669] to IMET [RFC9252] or S-PMSI [RFC9572] A-D routes with the SRv6 L2 Service TLV [RFC9252]. The SRv6 SID Information Sub-TLV carries the SID in the SRv6 SID Value field. The SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV SHOULD be END.DT2M [RFC8986] as per Section 6.3 of [RFC9252]. The SRv6 SID Structure Sub-Sub-TLV encodes the structure of SID. If the Transposition Scheme is used, the offset and length of the SID is set in the Transposition Length and Transposition Offset fields of this sub-sub-TLV. Otherwise, the Transposition Length and Offset fields MUST be set to zero. The LOC of a SID, which is assigned from a global context, such as DCB, is outside the scope of this document.
アドバタイジングイングレス PE は、BGP プレフィックス SID 属性 [RFC8669] を、SRv6 L2 サービス TLV [RFC9252] を使用して IMET [RFC9252] または S-PMSI [RFC9572] A-D ルートに付加しなければなりません (MUST)。SRv6 SID 情報サブ TLV は、SRv6 SID 値フィールドの SID を伝送します。SRv6 SID 情報サブ TLV の SRv6 エンドポイント動作は、[RFC9252] のセクション 6.3 に従って END.DT2M [RFC8986] である必要があります (SHOULD)。SRv6 SID 構造サブサブ TLV は、SID の構造をエンコードします。転置スキームが使用される場合、SID のオフセットと長さは、このサブサブ TLV の転置長フィールドと転置オフセット フィールドに設定されます。それ以外の場合は、移調長フィールドとオフセット フィールドをゼロに設定しなければなりません。DCB などのグローバル コンテキストから割り当てられる SID の LOC は、このドキュメントの範囲外です。
The MPLS Label field of a PTA advertised in an A-D route MUST contain an upstream-assigned SRv6 SID that the advertising PE has bound to the EVI or an SRv6 SID assigned from a global context; this follows same concept of the DCB label as specified in [RFC9573]. The high-order 20 bits of the MPLS Label field carry the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding as defined in [RFC9252] is used. When using the Transposition Scheme, the Transposition Length of the SRv6 SID Structure Sub-Sub-TLV of the SRv6 Prefix-SID attribute MUST be less than or equal to 20 and less than or equal to the Function Length. When the Transposition Scheme is not used, the MPLS Label field MUST be set to zero as per [RFC6514], and Transposition Length MUST be zero.
A-D ルートでアドバタイズされる PTA の MPLS ラベル フィールドには、アドバタイジング PE が EVI にバインドしたアップストリームで割り当てられた SRv6 SID、またはグローバル コンテキストから割り当てられた SRv6 SID が含まれなければなりません (MUST)。これは、[RFC9573] で指定されている DCB ラベルと同じ概念に従います。[RFC9252] で定義されているエンコードの転置スキームが使用される場合、MPLS ラベル フィールドの上位 20 ビットは、SRv6 SID の機能部分の全体または一部を伝送します。転置スキームを使用する場合、SRv6 プレフィックス SID 属性の SRv6 SID 構造サブサブ TLV の転置長は 20 以下、関数長以下でなければなりません。転置スキームが使用されない場合、MPLS ラベルフィールドは [RFC6514] に従ってゼロに設定されなければならず、転置長もゼロでなければなりません。
The advertising ingress PE, which is the Root node of the SR P2MP P-tunnel, MUST encapsulate a payload in an outer IPv6 header with an SRH in which the SRv6 SID (advertised in the BGP Prefix-SID attribute) MUST be the last segment in the segment list (note the SRv6 SID may be the only segment in the SRH). If the Transposition Scheme is used, the ingress PE MUST merge the Function part of the MPLS Label field of the PTA with the SRv6 SID in the SRv6 SID Information Sub-TLV using the Transposition Offset and Length fields from the SRv6 SID Structure Sub-Sub-TLV to create the SRv6 SID. When ESI-based split-horizon filtering is used, the Arg.FE2 (see Section 4.1.2.2) SHOULD be merged with the SRv6 SID by doing a bitwise logical OR operation to create the complete SRv6 SID encoded in the SRH on the ingress PE.
SR P2MP P トンネルのルート ノードであるアドバタイジングイングレス PE は、SRH を含む外部 IPv6 ヘッダーにペイロードをカプセル化しなければなりません (MUST)。SRH では、SRv6 SID (BGP Prefix-SID 属性でアドバタイズされる) がセグメント リストの最後のセグメントでなければなりません (SRv6 SID が SRH 内の唯一のセグメントである可能性があることに注意してください)。転置スキームが使用される場合、入力 PE は、SRv6 SID 構造サブサブ TLV からの転置オフセットおよび長さフィールドを使用して、PTA の MPLS ラベル フィールドの機能部分を SRv6 SID 情報サブ TLV の SRv6 SID とマージし、SRv6 SID を作成しなければなりません。ESI ベースのスプリット ホライズン フィルタリングが使用される場合、Arg.FE2 (セクション 4.1.2.2 を参照) は、ビット単位の論理 OR 演算を実行して SRv6 SID とマージされ、入力 PE の SRH でエンコードされた完全な SRv6 SID を作成する必要があります (SHOULD)。
An egress PE of the SR P2MP P-tunnel uses the SRv6 SID in the SRH to determine the EVI in which the customer payload is to be delivered. The egress PE, in role of Leaf or Bud node of the Replication segment associated with the SR P2MP P-tunnel tree, uses "look at next SID in SRH" [RFC9524] behavior to process the SRv6 SID. An egress PE MUST NOT install the SRv6 SID in its FIB, i.e., it MUST NOT forward packets based on the Locator portion of the SRv6 SID. The Arg.FE2 of the SID, if present, is used for ESI-based split-horizon filtering as specified in Section 4.1.2.2.
SR P2MP P トンネルの出力 PE は、SRH 内の SRv6 SID を使用して、顧客ペイロードが配信される EVI を決定します。SR P2MP P トンネル ツリーに関連付けられたレプリケーション セグメントのリーフ ノードまたはバッド ノードの役割を持つ出力 PE は、「SRH の次の SID を確認する」[RFC9524] 動作を使用して SRv6 SID を処理します。出力 PE は、SRv6 SID を FIB にインストールしてはなりません (MUST NOT)。つまり、SRv6 SID のロケーター部分に基づいてパケットを転送してはなりません (MUST NOT)。SID の Arg.FE2 が存在する場合、セクション 4.1.2.2 で指定されているように、ESI ベースのスプリット ホライズン フィルタリングに使用されます。
EVPN requires split-horizon filtering with ES multihoming in order to prevent duplicate BUM traffic as described in Section 8.3 of [RFC7432]. This section describes split-horizon filtering procedures with SR P2MP P-tunnels.
EVPN では、[RFC7432] のセクション 8.3 で説明されているように、BUM トラフィックの重複を防ぐために、ES マルチホーミングによるスプリット ホライズン フィルタリングが必要です。このセクションでは、SR P2MP P トンネルを使用したスプリット ホライズン フィルタリング手順について説明します。
The split-horizon procedures specified for P2MP MPLS Label Switched Paths (LSPs) in Section 8.3.1.2 of [RFC7432] are sufficient for SR P2MP P-tunnels. Note for shared SR P2MP P-tunnels, the ESI label is at the bottom of the label stack, followed by an EVI context label and finally the Tree-SID label of the PTI associated with P-tunnel at the top in SR-MPLS encapsulation.
[RFC7432] のセクション 8.3.1.2 で P2MP MPLS ラベル スイッチド パス (LSP) に指定されているスプリット ホライズン手順は、SR P2MP P トンネルには十分です。共有 SR P2MP P トンネルの場合、ESI ラベルはラベル スタックの一番下にあり、次に EVI コンテキスト ラベルが続き、最後に SR-MPLS カプセル化の一番上にある P トンネルに関連付けられた PTI のツリー SID ラベルが続きます。
For SRv6, the Arg.FE2 argument of End.DT2M SRv6 Endpoint behavior [RFC8986] is used for ESI-based split-horizon filtering. For an SR P2MP P-tunnel, the Arg.FE2 SID argument is an upstream-assigned value assigned by an ingress PE and identifies an ES of origin. This SID Argument is analogous to the upstream-assigned ESI MPLS label specified in Section 8.3 of [RFC7432]. The Arg.FE2 is signaled in the ESI Label field of the ESI Label extended community [RFC7432] and a BGP Prefix-SID attribute with an Ethernet A-D per ES route as specified in Section 6.1.1 of [RFC9252] and expanded further in [RFC9819].
SRv6 の場合、End.DT2M SRv6 エンドポイント動作 [RFC8986] の Arg.FE2 引数は、ESI ベースのスプリット ホライズン フィルタリングに使用されます。SR P2MP P トンネルの場合、Arg.FE2 SID 引数は、入力 PE によって割り当てられたアップストリーム割り当て値であり、発信元の ES を識別します。この SID 引数は、[RFC7432] のセクション 8.3 で指定されているアップストリームに割り当てられた ESI MPLS ラベルに似ています。Arg.FE2 は、ESI ラベル拡張コミュニティ [RFC7432] の ESI ラベル フィールドでシグナリングされ、[RFC9252] のセクション 6.1.1 で規定され、[RFC9819] でさらに拡張された ES ルートごとのイーサネット A-D を持つ BGP プレフィックス SID 属性で通知されます。
The advertised Arg.FE2 is encoded with the SRv6 SID in the SRH by the ingress PE as described in Section 4.1.1.1.2. The egress PE uses the Arg.FE2 of the SRv6 SID, if present, to perform ESI-based split-horizon filtering as specified for the End.DT2M forwarding behavior in Section 4.12 of [RFC8986].
アドバタイズされた Arg.FE2 は、セクション 4.1.1.1.2 で説明されているように、入力 PE によって SRH 内の SRv6 SID でエンコードされます。出力 PE は、SRv6 SID の Arg.FE2 (存在する場合) を使用して、[RFC8986] のセクション 4.12 の End.DT2M 転送動作に指定されている ESI ベースのスプリットホライズン フィルタリングを実行します。
EVPN A-D procedures specified in [RFC7432] and [RFC9572] are used to advertise an SR P2MP P-tunnel and discover the Leaf nodes of the SR P2MP Policy associated with the P-tunnel. This section describes the processing of EVPN A-D routes to create, update, and tear down an SR P2MP Policy of an SR P2MP P-tunnel as described in Section 2.
[RFC7432] および [RFC9572] で指定されている EVPN A-D プロシージャは、SR P2MP P トンネルをアドバタイズし、P トンネルに関連付けられた SR P2MP ポリシーのリーフ ノードを検出するために使用されます。このセクションでは、セクション 2 で説明したように、SR P2MP P トンネルの SR P2MP ポリシーを作成、更新、破棄するための EVPN A-D ルートの処理について説明します。
A PE interacts with an SR P2MP Policy module to create a CP, with optional traffic engineering constraints and an optional optimization objective, of an SR P2MP Policy when it originates an IMET A-D route [RFC7432] or an S-PMSI A-D route [RFC9572], with a PTA that has an SR P2MP P-tunnel type.
PE は、SR P2MP ポリシー モジュールと対話して、SR P2MP P トンネル タイプを持つ PTA を使用して IMET A-D ルート [RFC7432] または S-PMSI A-D ルート [RFC9572] を発信するときに、オプションのトラフィック エンジニアリング制約とオプションの最適化目標を備えた SR P2MP ポリシーの CP を作成します。
The CP of the SR P2MP Policy associated with an SR P2MP P-tunnel is deleted from the SR P2MP Policy module when a PE withdraws the IMET or S-PMSI A-D route advertising that P-tunnel.
SR P2MP P トンネルに関連付けられた SR P2MP ポリシーの CP は、PE がその P トンネルをアドバタイズする IMET または S-PMSI A-D ルートを取り消すと、SR P2MP ポリシー モジュールから削除されます。
When a PE originates an S-PMSI A-D route with a PTA that has an SR P2MP P-tunnel type, it MUST set the "Leaf Information Required" flag in the PTA.
PE が SR P2MP P トンネル タイプを持つ PTA との S-PMSI A-D ルートを開始する場合、PE は PTA に「リーフ情報が必要」フラグを設定しなければなりません。
An ingress PE that advertises an EVPN A-D route with a PTA that has an SR P2MP P-tunnel type discovers a Leaf node of the SR P2MP Policy associated with the SR P2MP P-tunnel when it imports an IMET A-D route [RFC7432] or Leaf A-D route [RFC9572] from an egress PE. The ingress PE adds the egress PE as a Leaf node in the SR P2MP Policy module.
SR P2MP P トンネル タイプを持つ PTA で EVPN A-D ルートをアドバタイズする入力 PE は、出力 PE から IMET A-D ルート [RFC7432] またはリーフ A-D ルート [RFC9572] をインポートするときに、SR P2MP P トンネルに関連付けられた SR P2MP ポリシーのリーフ ノードを検出します。入力 PE は、出力 PE を SR P2MP ポリシー モジュールのリーフ ノードとして追加します。
An ingress PE removes an egress PE from the Leaf set of the SR P2MP Policy when the egress PE withdraws the IMET A-D or the Leaf A-D route.
入力 PE は、IMET A-D またはリーフ A-D ルートを取り消すと、SR P2MP ポリシーのリーフ セットから出力 PE を削除します。
An egress PE informs the SR P2MP Policy module to join the SR P2MP Policy as a Leaf or Bud node when it imports an IMET A-D route or an S-PMSI A-D route from an ingress PE that has a PTA with an SR P2MP P-tunnel type. The egress PE MUST originate a Leaf A-D route if the "Leaf Information Required" flag is set in the PTA.
出力 PE は、SR P2MP P トンネル タイプの PTA を持つ入力 PE から IMET A-D ルートまたは S-PMSI A-D ルートをインポートするときに、SR P2MP ポリシー モジュールにリーフ ノードまたはバッド ノードとして SR P2MP ポリシーに参加するように通知します。PTA で「リーフ情報が必要」フラグが設定されている場合、出力 PE はリーフ A-D ルートを開始しなければなりません (MUST)。
An egress PE withdraws itself as a Leaf or Bud node of the SR P2MP Policy when the ingress PE withdraws an IMET or an S-PMSI A-D route. The egress PE MUST withdraw the Leaf A-D it had originated earlier in response to the "Leaf Information Required" flag in the PTA.
入力 PE が IMET または S-PMSI A-D ルートを取り消すと、出力 PE は SR P2MP ポリシーのリーフ ノードまたはバッド ノードとして自身を取り消します。出口 PE は、PTA の「リーフ情報が必要」フラグに応答して、以前に発信したリーフ A ～ D を取り消さなければなりません (MUST)。
A PE can provide EVPN service using IR over SR. The EVPN payload is encapsulated in SR-MPLS or SRv6 at an ingress PE and replicated with each copy sent to an egress PE via unicast. IR procedures for MPLS are specified for the IMET A-D route in [RFC7432] and the SMET A-D route in [RFC9251]. Procedures for EVPN IR over SRv6 for the IMET A-D route are specified in [RFC9252]. These procedures provide an EVPN IR service with best-effort unicast connectivity.
PE は、IR over SR を使用して EVPN サービスを提供できます。EVPN ペイロードは、入力 PE で SR-MPLS または SRv6 にカプセル化され、ユニキャスト経由で出力 PE に送信される各コピーとともに複製されます。MPLS の IR 手順は、[RFC7432] の IMET A-D ルートと [RFC9251] の SMET A-D ルートに対して指定されています。IMET A-D ルートの SRv6 を介した EVPN IR の手順は [RFC9252] で規定されています。これらの手順により、ベストエフォート型のユニキャスト接続を備えた EVPN IR サービスが提供されます。
This document adds procedures for providing an EVPN IR service with an SLA from an ingress PE to an egress PE both for SR-MPLS and SRv6. This document extends the BGP Update message of AFI/SAFI 25/70 (L2VPN-EVPN) to carry the Color Extended Community as specified in [RFC9012] and the Color-Only Type extension specified in Section 3 of [RFC9830]. An egress PE colors the IMET with a Color Extended Community. The ingress PE replicates EVPN customer payload to the egress PE by steering it into an SR-TE policy according to Section 8 of [RFC9256]. The ingress PE encapsulates the payload packet into a segment list of the matching SR-TE policy to the egress PE along with IR MPLS label or SRv6 End.DT2M SID received from the egress PE.
このドキュメントでは、SR-MPLS と SRv6 の両方について、入力 PE から出力 PE への SLA を備えた EVPN IR サービスを提供する手順を追加します。この文書は、AFI/SAFI 25/70 (L2VPN-EVPN) の BGP 更新メッセージを拡張して、[RFC9012] で指定されているカラー拡張コミュニティと、[RFC9830] のセクション 3 で指定されているカラー専用タイプ拡張を伝送します。出力 PE は、Color Extended Community を使用して IMET を色付けします。入力 PE は、[RFC9256] のセクション 8 に従って SR-TE ポリシーにステアリングすることにより、EVPN 顧客ペイロードを出力 PE に複製します。入力 PE は、出力 PE から受信した IR MPLS ラベルまたは SRv6 End.DT2M SID とともに、出力 PE に一致する SR-TE ポリシーのセグメント リストにペイロード パケットをカプセル化します。
Note that the Color Extended Community is not used with an EVPN SR P2MP P-tunnel. For EVPN with an SR P2MP P-tunnel, the ingress PE dictates the traffic engineering treatment by specifying the constraints and the metric optimization in the CP of the SR P2MP Policy corresponding to the P-tunnel on the ingress PE. This is necessary because packets are replicated in the PTI; therefore, it is not possible to have differing traffic engineering treatment towards each egress PE (Leaf node) of the PTI.
Color Extended Community は EVPN SR P2MP P トンネルでは使用されないことに注意してください。SR P2MP P トンネルを備えた EVPN の場合、入力 PE は、入力 PE の P トンネルに対応する SR P2MP ポリシーの CP で制約とメトリックの最適化を指定することにより、トラフィック エンジニアリング処理を指示します。これは、パケットが PTI で複製されるため必要です。したがって、PTI の各出力 PE (リーフ ノード) に対して異なるトラフィック エンジニアリング処理を行うことはできません。
EVPN IR procedures for MPLS specified in [RFC7432] and [RFC9251] can be extended for EVPN IR over SR-MPLS.
[RFC7432] および [RFC9251] で指定されている MPLS 用の EVPN IR 手順は、SR-MPLS 上の EVPN IR 用に拡張できます。
EVPN IR service with an SLA over SR-MPLS data plane can be provided by using the Color Extended Community as described above. Suppose an egress PE, say PE2, sends an IMET A-D route with Extended Color Community C1 with Color-Only Type 0 and EVPN BUM label L10 to ingress PE1. Assume the segment list of SR-TE policy (C1, PE2) at ingress PE1 is <L1, L2, L3>. PE1 will encapsulate the MVPN payload into the MPLS label stack <L1, L2, L3, L10> with L10 as the BoS label. Note that the MPLS label stack may have the ESI label at the bottom of the label stack if ESI-based split-horizon filtering is used.
SR-MPLS データ プレーン上の SLA を備えた EVPN IR サービスは、前述のように Color Extended Community を使用して提供できます。出力 PE (PE2 など) が、カラー専用タイプ 0 および EVPN BUM ラベル L10 を持つ拡張カラー コミュニティ C1 を持つ IMET A-D ルートを入力 PE1 に送信するとします。入力 PE1 の SR-TE ポリシー (C1、PE2) のセグメント リストが <L1、L2、L3> であると仮定します。PE1 は、L10 を BoS ラベルとして、MVPN ペイロードを MPLS ラベル スタック <L1、L2、L3、L10> にカプセル化します。ESI ベースのスプリットホライズン フィルタリングが使用されている場合、MPLS ラベル スタックの一番下に ESI ラベルが存在する可能性があることに注意してください。
EVPN IR procedures for SRv6 are specified in Section 6.3 of [RFC9252] for the IMET A-D route.
SRv6 の EVPN IR 手順は、IMET A-D ルートに関して [RFC9252] のセクション 6.3 で規定されています。
A PE can provide EVPN IR service with SLA over SRv6 using the Color Extended Community as described above. Suppose an egress PE, say PE2, sends an IMET A-D route with Extended Color community C1 with Color-Only Type 0 and SRv6 End.DT2M SID S10 to ingress PE1. Assume the segment list of the SR-TE policy (C1, PE2) at ingress PE1 is <S1, S2, S3>. PE1 will encapsulate a payload into an IPv6 header with SRH (PE1, S1) (S10, S3, S2; SL=3) (payload). Note that the End.DT2M SID S10 may also have an Arg.FE2 Argument if ESI-based split-horizon filtering is used.
PE は、上で説明したように Color Extended Community を使用して SRv6 上の SLA を備えた EVPN IR サービスを提供できます。出力 PE (PE2 など) が、カラー専用タイプ 0 および SRv6 End.DT2M SID S10 を持つ拡張カラー コミュニティ C1 を持つ IMET A-D ルートを入力 PE1 に送信するとします。入力 PE1 の SR-TE ポリシー (C1、PE2) のセグメント リストが <S1、S2、S3> であると仮定します。PE1 は、SRH (PE1、S1) (S10、S3、S2; SL=3) (ペイロード) を使用してペイロードを IPv6 ヘッダーにカプセル化します。ESI ベースのスプリット ホライズン フィルタリングが使用されている場合、End.DT2M SID S10 には Arg.FE2 引数も含まれる可能性があることに注意してください。
IANA has assigned the following values in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry [RFC7385] within the "Border Gateway Protocol (BGP) Parameters" registry group <https://www.iana.org/assignments/bgp-parameters>.
IANA は、「ボーダー ゲートウェイ プロトコル (BGP) パラメーター」レジストリ グループ <https://www.iana.org/assignments/bgp-parameters> 内の「P-マルチキャスト サービス インターフェイス トンネル (PMSI トンネル) トンネル タイプ」レジストリ [RFC7385] に次の値を割り当てました。
+=======+===================+===========+
| Value | Meaning | Reference |
+=======+===================+===========+
| 0x0C | SR-MPLS P2MP Tree | RFC 10018 |
+-------+-------------------+-----------+
| 0x0D | SRv6 P2MP Tree | RFC 10018 |
+-------+-------------------+-----------+
Table 1: PMSI Tunnel Types
表 1: PMSI トンネルの種類
IANA has allocated the following code points in the "SRv6 Endpoint Behaviors" registry [RFC8986] within the "Segment Routing" registry group <https://www.iana.org/assignments/segment-routing>.
IANA は、「Segment Routing」レジストリ グループ <https://www.iana.org/assignments/segment-routing> 内の「SRv6 Endpoint Behaviors」レジストリ [RFC8986] に次のコード ポイントを割り当てました。
+=======+========+===================+===========+============+
| Value | Hex | Endpoint Behavior | Reference | Change |
| | | | | Controller |
+=======+========+===================+===========+============+
| 76 | 0x004C | End.DTMC4 | RFC 10018 | IETF |
+-------+--------+-------------------+-----------+------------+
| 77 | 0x004D | End.DTMC6 | RFC 10018 | IETF |
+-------+--------+-------------------+-----------+------------+
| 78 | 0x004E | End.DTMC46 | RFC 10018 | IETF |
+-------+--------+-------------------+-----------+------------+
Table 2: SRv6 Endpoint Behaviors
表 2: SRv6 エンドポイントの動作
The procedures in this document do not introduce any additional security considerations beyond those mentioned in [RFC6513], [RFC6514], [RFC7432], and [RFC9572]. For general security considerations applicable to SR P2MP Policy and Replication segments, please refer to [RFC9960] and [RFC9524], respectively.
この文書の手順では、[RFC6513]、[RFC6514]、[RFC7432]、および [RFC9572] で言及されているものを超える追加のセキュリティ考慮事項は導入されていません。SR P2MP ポリシーおよびレプリケーション セグメントに適用される一般的なセキュリティに関する考慮事項については、それぞれ [RFC9960] および [RFC9524] を参照してください。
[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>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>.
[RFC7385] Andersson, L. and G. Swallow, "IANA Registry for
P-Multicast Service Interface (PMSI) Tunnel Type Code
Points", RFC 7385, DOI 10.17487/RFC7385, October 2014,
<https://www.rfc-editor.org/info/rfc7385>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
February 2024, <https://www.rfc-editor.org/info/rfc9524>.
[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
Multicast (BUM) Procedures", RFC 9572,
DOI 10.17487/RFC9572, May 2024,
<https://www.rfc-editor.org/info/rfc9572>.
[RFC9819] Talaulikar, K., Raza, K., Rabadan, J., and W. Lin,
"Argument Signaling for BGP Services in Segment Routing
over IPv6 (SRv6)", RFC 9819, DOI 10.17487/RFC9819, July
2025, <https://www.rfc-editor.org/info/rfc9819>.
[RFC9960] Parekh, R., Ed., Voyer, D., Ed., Filsfils, C., Bidgoli,
H., and Z. Zhang, "Segment Routing Point-to-Multipoint
Policy", RFC 9960, DOI 10.17487/RFC9960, April 2026,
<https://www.rfc-editor.org/info/rfc9960>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels",
RFC 9573, DOI 10.17487/RFC9573, May 2024,
<https://www.rfc-editor.org/info/rfc9573>.
[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in
BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
<https://www.rfc-editor.org/info/rfc9830>.
[RFC9961] Bidgoli, H., Ed., Ali, Z., Zhang, Z., Budhiraja, A., and
D. Voyer, "MPLS Segment Routing Point-to-Multipoint (P2MP)
Policy Ping", RFC 9961, DOI 10.17487/RFC9961, April 2026,
<https://www.rfc-editor.org/info/rfc9961>.
[SR-P2MP-PCEP]
Bidgoli, H., Voyer, D., Budhiraja, A., Parekh, R., and S.
Sivabalan, "PCEP extensions for SR P2MP Policy", Work in
Progress, Internet-Draft, draft-ietf-pce-sr-p2mp-policy-
19, 6 July 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-sr-p2mp-policy-19>.
The authors would like to acknowledge Luc André Burdet reviewing the document.
著者らは、この文書をレビューした Luc André Burdet に感謝の意を表します。
Zafar Ali
Cisco Systems, Inc.
United States of America
Email: zali@cisco.com
Arvind Venkateswaran
Cisco Systems, Inc.
United States of America
Email: arvvenka@cisco.com
Jayant Kotalwar
Nokia
Mountain View, CA
United States of America
Email: jayant.kotalwar@nokia.com
Tanmoy Kundu
Nokia
Mountain View, CA
United States of America
Email: tanmoy.kundu@nokia.com
Clayton Hassen
Bell
Vancouver
Canada
Email: clayton.hassen@bell.ca
Mankamana Mishra
Cisco Systems, Inc.
United States of America
Email: mankamis@cisco.com
Rishabh Parekh (editor)
Arrcus
United States of America
Email: rishabh@arrcus.com
Daniel Voyer (editor)
Cisco Systems, Inc.
Montreal
Canada
Email: davoyer@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Hooman Bidgoli
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net