Juniper Networks

zzhang@juniper.net

Juniper Networks

prz@juniper.net

Cisco Systems

sajassi@cisco.com

Nokia

jorge.rabadan@nokia.com

RTF BIER This document specifies protocols and procedures for forwarding Broadcast, Unknown Unicast, or Multicast (BUM) traffic of Ethernet VPNs (EVPNs) using Bit Index Explicit Replication (BIER).

Status of This Memo 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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.

Table of Contents

• .  Introduction
  • .  Terminology
  • .  Requirements Language
• .  Use of the PMSI Tunnel Attribute
  • .  IP-Based Tunnel and BIER PHP
  • .  Explicit Tracking
    • .  Using IMET/SMET Routes
    • .  Using S-PMSI/Leaf A-D Routes
  • .  MPLS Label in the PTA
• .  Multihoming Split Horizon
• .  Data Plane
  • .  Encapsulation and Transmission
    • .  At a BFIR That Is an Ingress PE
    • .  At a BFIR That Is a P-Tunnel Segmentation Point
  • .  Disposition
    • .  At a BFER That Is an Egress PE
    • .  At a BFER That Is a P-Tunnel Segmentation Point
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction and specify the protocols and procedures for Ethernet VPNs (EVPNs). For Broadcast, Unknown Unicast, or Multicast (BUM) traffic, provider/underlay tunnels are used to carry the BUM traffic. Several kinds of tunnel technologies can be used as specified in and , and this document specifies the protocols and procedures to use Bit Index Explicit Replication (BIER) as provider tunnels for EVPN BUM traffic. BIER is an architecture that provides optimal multicast forwarding through a "multicast domain" without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The EVPN BUM procedures specified in and extended in , , and are much aligned with Multicast VPN (MVPN) procedures , and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN. As such, this document is also very much aligned with , which specifies MVPN with BIER. For terseness, some background, terms, and concepts are not repeated here. Additionally, some text is borrowed verbatim from .

Terminology

ES:

Ethernet Segment

ESI:

Ethernet Segment Identifier

BFR:

Bit-Forwarding Router

BFIR:

Bit-Forwarding Ingress Router

BFER:

Bit-Forwarding Egress Router

BFR-Prefix:

An IP address that uniquely identifies a BFR and is routable in a BIER domain.

C-S:

A multicast source address identifying a multicast source located at an EVPN customer site. "C-" stands for "Customer-".

C-G:

A multicast group address used by an EVPN customer.

C-flow:

A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S, C-G). Sets of C-flows can be denoted by the use of the "C-*" wildcard (see ), e.g., (C-*, C-G).

P-tunnel:

A multicast tunnel through the network of one or more service providers used to transport C-flows. "P-" stands for "Provider-".

IMET A-D Route:

Inclusive Multicast Ethernet Tag Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the "default" P-tunnel for a particular BD.

SMET A-D Route:

Selective Multicast Ethernet Tag Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the C-flows that the advertising Provider Edge (PE) is interested in.

PMSI:

Provider Multicast Service Interface . A conceptual interface used by a PE to send customer multicast traffic to all or some PEs in the same VPN.

I-PMSI:

Inclusive PMSI. For all PEs in the same VPN.

S-PMSI:

Selective PMSI. For some of the PEs in the same VPN.

I-PMSI A-D Route:

Inclusive PMSI Auto-Discovery route used to advertise the tunnels that instantiate an I-PMSI.

S-PMSI A-D Route:

Selective PMSI Auto-Discovery route used to advertise that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels.

PTA:

PMSI Tunnel Attribute. A BGP attribute used to identify a particular P-tunnel.

VXLAN:

Virtual eXtensible Local Area Network

NVGRE:

Network Virtualization Using Generic Routing Encapsulation

GENEVE:

Generic Network Virtualization Encapsulation

VNI:

VXLAN Network Identifier

VSID:

Virtual Subnet Identifier

RSVP-TE P2MP:

Resource Reservation Protocol for Point-to-Multipoint TE Label Switched Paths (LSPs)

mLDP P2MP:

Multipoint Label Distribution Protocol extensions for Point-to-Multipoint LSPs

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Use of the PMSI Tunnel Attribute specifies that Inclusive Multicast Ethernet Tag (IMET) routes carry a PMSI Tunnel Attribute (PTA) to identify the particular P-tunnel to which one or more BUM flows are being assigned, which is the same as specified in for MVPN. specifies the encoding of the PTA for the use of BIER with MVPN. Much of that specification is reused for the use of BIER with EVPN, and much of the text below is borrowed verbatim from . The PTA contains the following fields:

• Tunnel Type. The same codepoint 0x0B that IANA has assigned for BIER for MVPN is used for EVPN as well.
• Tunnel Identifier. This field contains three subfields for BIER. The text below is exactly as in .
  1. The first subfield is a single octet, containing a BIER sub-domain-id (see ). This indicates that packets sent on the PMSI will be sent on the specified BIER sub-domain. How that sub-domain is chosen is outside the scope of this document.
  2. The second subfield is a two-octet field containing the BFR-id in the sub-domain identified in the first subfield of the router that is constructing the PTA.
  3. The third subfield is the BFR-Prefix (see ) of the router (a BFIR) that is constructing the PTA. The BFR-Prefix will either be a /32 IPv4 address or a /128 IPv6 address. Whether the address is IPv4 or IPv6 can be inferred from the total length of the PTA. The BFR-Prefix need not be the same IP address that is carried in any other field of the x-PMSI A-D route, even if the BFIR is the originating router of the x-PMSI A-D route.
• MPLS Label. For EVPN-MPLS , this field contains an upstream-assigned MPLS label. It is assigned by the BFIR. Constraints on how the originating router selects this label are discussed in . For EVPN-VXLAN/NVGRE/GENEVE , this field is a 24-bit VNI/VSID of global significance.
• Flags. When the tunnel type is BIER, two of the flags in the PTA Flags field are meaningful. Details about the use of these flags can be found in .
  • Leaf Info Required per Flow (LIR-pF)
  • Leaf Info Required (LIR)

Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D, or per-region I-PMSI A-D route, the route MUST NOT be distributed beyond the boundaries of a BIER domain. That is, any routers that receive the route must be in the same BIER domain as the originator of the route. If the originator is in more than one BIER domain, the route must be distributed only within the BIER domain in which the BFR-Prefix in the PTA uniquely identifies the originator. As with all MVPN routes, the distribution of these routes is controlled by the provisioning of Route Targets.

IP-Based Tunnel and BIER PHP When VXLAN/NVGRE/GENEVE is used for EVPN, by default, the outer IP header (and UDP header in the case of VXLAN/GENEVE) is not included in the BIER payload, except when it is known a priori that BIER Penultimate Hop Popping (PHP) is used in the BIER domain and the encapsulation (after the BIER header is popped) between the BIER Penultimate Hop and the egress PE does not have a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case, the full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer IP header, a well-known IP multicast address (224.0.0.122 in the case of IPv4 or FF02:0:0:0:0:0:0:14 in the case of IPv6) is used as the destination address, and the egress PEs MUST be set up to receive and process packets addressed to the destination address. The address is used for all BDs, and the inner VXLAN/NVGRE/GENEVE header will be used to identify BDs.

Explicit Tracking When using BIER to transport an EVPN BUM data packet through a BIER domain, an ingress PE functions as a BFIR (see ). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done in either of two ways as described in the following two sections.

Using IMET/SMET Routes Both IMET and SMET routes provide explicit tracking functionality. For an inclusive PMSI, the set of BFERs (egress PEs) includes the originators of all IMET routes for a BD. For a selective PMSI, the set of BFERs (egress PEs) includes the originators of corresponding SMET routes. The SMET routes do not carry a PTA. When an ingress PE sends traffic on a selective tunnel using BIER, it uses the upstream-assigned label that is advertised in its IMET route. When only selective forwarding is used for all flows and without tunnel segmentation, SMET routes are used without the need for S-PMSI A-D routes. Otherwise, the procedures in the following section apply.

Using S-PMSI/Leaf A-D Routes There are two cases where S-PMSI/Leaf A-D routes are used as discussed in the following two sections.

Selective Forwarding Only for Some Flows With the SMET procedure, a PE advertises a SMET route for each (C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits (ACs), and each SMET route is tracked by every PE in the same BD. It may be desired that SMET routes are not used in order to reduce the burden of explicit tracking. In this case, most multicast traffic will follow the I-PMSI (advertised via the IMET route) and only some flows will follow S-PMSIs. To achieve that, S-PMSI/Leaf A-D routes can be used, as specified in . The rules specified in Sections and of apply.

Tunnel Segmentation Another case where S-PMSI/Leaf A-D routes are necessary is tunnel segmentation, which is also specified in and further clarified in for segmentation with SMET routes. This is only applicable to EVPN-MPLS. The rules specified in apply. does not apply, because like in MVPN, the LIR-pF flag cannot be used with segmentation.

Applicability of Additional MVPN Specifications As with the MVPN case, "Use of the PMSI Tunnel Attribute in Leaf A-D Routes" () applies. Notice that refers to procedures specified in and . Those two documents were specified for MVPN but apply to IP multicast payload in EVPN as well.

MPLS Label in the PTA Rules in apply, EXCEPT the following three bullets (they do NOT apply to EVPN) in that section:

• If the two routes do not have the same Address Family Identifier (AFI) value, then their respective PTAs MUST contain different MPLS label values. This ensures that when an egress PE receives a data packet with the given label, the egress PE can infer from the label whether the payload is an IPv4 packet or an IPv6 packet.
• If the BFIR is an ingress PE supporting MVPN extranet functionality, and if the two routes originate from different VRFs on this ingress PE, then the respective PTAs of the two routes MUST contain different MPLS label values.
• If the BFIR is an ingress PE supporting the "Extranet Separation" feature of MVPN extranet (see ), and if one of the routes carries the "Extranet Separation" extended community but the other does not, then the respective PTAs of the two routes MUST contain different MPLS label values.

Multihoming Split Horizon For EVPN-MPLS, specifies the use of ESI labels to identify the ES from which a BUM packet originates. A PE receiving that packet from the core side will not forward it to the same ES. The procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels, using downstream- and upstream-assigned ESI labels, respectively. For EVPN-VXLAN/NVGRE/GENEVE, specifies local bias procedures, where a PE receiving a BUM packet from the core side knows the ingress PE due to encapsulation; therefore, the PE does not forward the packet to any multihoming ESes that the ingress PE is on. This is because the ingress PE already forwarded the packet to those ESes, regardless of whether the ingress PE is a Designated Forwarder for those ESes. With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/GENEVE, as the BFIR-id in the BIER header identifies the ingress PE. For EVPN-MPLS, ESI label procedures also still apply, though two upstream-assigned labels will be used (one for identifying the BD and one for identifying the ES) -- the same as in the case of using a single P2MP tunnel for multiple BDs. The BFIR-id in the BIER header identifies the ingress PE that assigned those two labels.

Data Plane Like MVPN, the EVPN application plays the role of the "multicast flow overlay" as described in .

Encapsulation and Transmission A BFIR could be either an ingress PE or a P-tunnel segmentation point. The procedures are slightly different as described below.

At a BFIR That Is an Ingress PE To transmit a BUM data packet, an ingress PE first determines the route matched for transmission and routes for tracking leaves according to the following rules.

1. If selective forwarding is not used or is not an IP multicast packet after the Ethernet header, the IMET route originated for the BD by the ingress PE is the route matched for transmission. Leaf-tracking routes are all other received IMET routes for the BD.
2. Otherwise, if selective forwarding is used for all IP multicast traffic based on SMET routes, the IMET route originated for the BD by the ingress PE is the route matched for transmission. Received SMET routes for the BD, whose source and destination address fields match the packet's source and destination IP address, are leaf-tracking routes.
3. Otherwise, the route matched for transmission is the S-PMSI A-D route originated by the ingress PE for the BD, whose source and destination address fields match the packet's source and destination IP address and have a PTA specifying a valid tunnel type that is not "no tunnel info". Leaf-tracking routes are determined as follows:
   1. If the match for the transmission route carries a PTA that has the LIR flag set but does not have the LIR-pF flag set, the routes matched for tracking are Leaf A-D routes whose Route Key field is identical to the NLRI of the S-PMSI A-D route.
   2. If the match for the transmission route carries a PTA that has the LIR-pF flag, the leaf-tracking routes are Leaf A-D routes whose Route Key field is derived from the NLRI of the S-PMSI A-D route according to the procedures described in .
   Note that in both cases, SMET routes may be used in lieu of Leaf A-D routes, as a PE may omit the Leaf A-D route in response to an S-PMSI A-D route with the LIR or LIR-pF bit set if a SMET route with the corresponding Tag, Source, and Group fields is already originated . In particular, in the second case above, even though the SMET route does not have a PTA attached, it is still considered a Leaf A-D route in response to a wildcard S-PMSI A-D route with the LIR-pF bit set.
4. Otherwise, the route matched for transmission and leaf-tracking routes are determined as in rule .

If no route is matched for transmission, the packet is not forwarded onto a P-tunnel. If the tunnel that the ingress determines to use based on the route matched for transmission (and considering interworking with PEs that do not support certain tunnel types per procedures in ) requires leaf tracking (e.g., Ingress Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf-tracking routes, the packet will not be forwarded onto a P-tunnel either. The following text assumes that BIER is the determined tunnel type. The ingress PE pushes an upstream-assigned ESI label per if the following conditions are all met:

• The packet is received on a multihomed ES.
• It is EVPN-MPLS.
• The ESI label procedure is used for split horizon.

The MPLS label from the PTA of the route matched for transmission is then pushed onto the packet's label stack for EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the packet with the VNI/VSID set to the value in the PTA's Label field, and then an IP/UDP header is prepended if needed (e.g., for PHP purposes). Then, the packet is encapsulated in a BIER header and forwarded according to the procedures of and . Specifically, see "Imposing and Processing the BIER Encapsulation" (). The Proto field in the BIER header is set to 2 in the case of EVPN-MPLS, 7/8/9 in the case of EVPN-VXLAN/NVGRE/GENEVE () when an IP header is not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE. To create the proper BIER header for a given packet, the BFIR must know all the BFERs that need to receive that packet. This is determined from the set of leaf-tracking routes.

At a BFIR That Is a P-Tunnel Segmentation Point In this case, the encapsulation for the upstream segment of the P-tunnel includes (among other things) a label that identifies the x-PMSI or IMET A-D route that is the match for reception on the upstream segment. The segmentation point re-advertised the route into one or more downstream regions. Each instance of the re-advertised route for a downstream region has a PTA that specifies the tunnel for that region. For any particular downstream region, the route matched for transmission is the re-advertised route, and the leaf-tracking routes are determined as follows, if needed, for the tunnel type:

• If the route matched for transmission is an x-PMSI route, it must have the LIR flag set in its PTA, and the leaf-tracking routes are all the matching Leaf A-D and SMET routes received in the downstream region.
• If the route matched for transmission is an IMET route, the leaf-tracking routes are all the IMET routes for the same BD received in the downstream region.

If the downstream region uses BIER, the packet is forwarded as follows: the upstream segmentation's encapsulation is removed and the above-mentioned label is swapped to the upstream-assigned label in the PTA of the route matched for transmission, and then a BIER header is imposed as in .

Disposition The same procedures in are followed for EVPN-MPLS, except for some EVPN specifics that are discussed in the following two subsections of this document. For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the payload is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID field in the VXLAN/NVGRE/GENEVE header is used to determine the corresponding BD.

At a BFER That Is an Egress PE Once the corresponding BD is determined from the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per or are followed. In the case of EVPN-MPLS, if there is an inner label in the label stack following the BIER header, that inner label is considered the upstream-assigned ESI label for split-horizon purposes.

At a BFER That Is a P-Tunnel Segmentation Point This is only applicable to EVPN-MPLS. The same procedures in are followed, subject to multihoming procedures specified in .

IANA Considerations Per this document, IANA has registered the following three values in the "BIER Next Protocol Identifiers" registry: BIER Next Protocol Identifiers Registry

Value	Description	Reference
7	Payload is VXLAN encapsulated (no IP/UDP header)	RFC 9624
8	Payload is NVGRE encapsulated (no IP header)	RFC 9624
9	Payload is GENEVE encapsulated (no IP/UDP header)	RFC 9624

IANA has also assigned an IPv4 and an IPv6 multicast address for the case discussed in . The following entry has been added to the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:

Address(es):

224.0.0.122

Description:

Network Virtualization Overlay (NVO) BUM Traffic

Reference:

RFC 9624

The following entry has been added to the "Link-Local Scope Multicast Addresses" registry for IPv6:

Address(es):

FF02:0:0:0:0:0:0:14

Description:

Network Virtualization Overlay (NVO) BUM Traffic

Reference:

RFC 9624

Security Considerations This document is about using BIER as provider tunnels for EVPN. It is very similar to using BIER as MVPN provider tunnels and does not introduce additional security implications beyond what have been discussed in the EVPN base protocol specification and MVPN using BIER .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK] This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK] In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK] This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network. This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices. The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900. The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network. Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs. This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs). This document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. This document updates RFC 7432. Informative References Juniper Networks Work in Progress Juniper Networks Juniper Networks Juniper Networks Work in Progress This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK] This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK] This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.

Acknowledgements The authors thank for his review and suggestions. Additionally, much of the text is borrowed verbatim from .

Authors' Addresses Juniper Networks

zzhang@juniper.net

Juniper Networks

prz@juniper.net

Cisco Systems

sajassi@cisco.com

Nokia

jorge.rabadan@nokia.com