rfc9624.original   rfc9624.txt 
BIER Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Internet-Draft A. Przygienda Request for Comments: 9624 T. Przygienda
Intended status: Standards Track Juniper Networks Category: Standards Track Juniper Networks
Expires: 5 July 2024 A. Sajassi ISSN: 2070-1721 A. Sajassi
Cisco Systems Cisco Systems
J. Rabadan J. Rabadan
Nokia Nokia
2 January 2024 August 2024
EVPN BUM Using BIER EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index
draft-ietf-bier-evpn-14 Explicit Replication (BIER)
Abstract Abstract
This document specifies protocols and procedures for forwarding This document specifies protocols and procedures for forwarding
broadcast, unknown unicast, and multicast (BUM) traffic of Ethernet Broadcast, Unknown Unicast, or Multicast (BUM) traffic of Ethernet
VPNs (EVPN) using Bit Index Explicit Replication (BIER). VPNs (EVPNs) using Bit Index Explicit Replication (BIER).
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 5 July 2024. 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/rfc9624.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 1.2. Requirements Language
2.1. IP-Based Tunnel and BIER PHP . . . . . . . . . . . . . . 6 2. Use of the PMSI Tunnel Attribute
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 6 2.1. IP-Based Tunnel and BIER PHP
2.2.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 6 2.2. Explicit Tracking
2.2.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 7 2.2.1. Using IMET/SMET Routes
2.3. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Using S-PMSI/Leaf A-D Routes
3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 8 2.3. MPLS Label in the PTA
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Multihoming Split Horizon
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 9 4. Data Plane
4.1.1. At a BFIR that is an Ingress PE . . . . . . . . . . . 9 4.1. Encapsulation and Transmission
4.1.2. At a BFIR that is a P-tunnel Segmentation Point . . . 11 4.1.1. At a BFIR That Is an Ingress PE
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. At a BFIR That Is a P-Tunnel Segmentation Point
4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 12 4.2. Disposition
4.2.2. At a BFER that is a P-tunnel Segmentation Point . . . 12 4.2.1. At a BFER That Is an Egress PE
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. At a BFER That Is a P-Tunnel Segmentation Point
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
[RFC7432] and [RFC8365] specify the protocols and procedures for [RFC7432] and [RFC8365] specify the protocols and procedures for
Ethernet VPNs (EVPNs). For broadcast, unknown unicast and multicast Ethernet VPNs (EVPNs). For Broadcast, Unknown Unicast, or Multicast
(BUM) traffic, provider/underlay tunnels are used to carry the BUM (BUM) traffic, provider/underlay tunnels are used to carry the BUM
traffic. Several kinds of tunnel technologies can be used as traffic. Several kinds of tunnel technologies can be used as
specified in [RFC7432] and [RFC8365], and this document specifies the specified in [RFC7432] and [RFC8365], and this document specifies the
protocols and procedures to use Bit Index Explicit Replication (BIER) protocols and procedures to use Bit Index Explicit Replication (BIER)
[RFC8279] as provider tunnels for EVPN BUM traffic. [RFC8279] as provider tunnels for EVPN BUM traffic.
BIER is an architecture that provides optimal multicast forwarding BIER is an architecture that provides optimal multicast forwarding
through a "multicast domain", without requiring intermediate routers through a "multicast domain" without requiring intermediate routers
to maintain any per-flow state or to engage in an explicit tree- to maintain any per-flow state or to engage in an explicit tree-
building protocol. building protocol.
The EVPN BUM procedures specified in [RFC7432] and extended in The EVPN BUM procedures specified in [RFC7432] and extended in
[I-D.ietf-bess-evpn-bum-procedure-updates], [RFC9251], and [RFC9572], [RFC9251], and [CMCAST-ENHANCEMENTS] are much aligned with
[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with Multicast VPN (MVPN) procedures [RFC6514], and an EVPN Broadcast
Multicast VPN (MVPN) procedures [RFC6514] and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN. As such, this document is
Domain corresponds to a VPN in MVPN. As such, this document is also also very much aligned with [RFC8556], which specifies MVPN with
very much aligned with [RFC8556] that specifies MVPN with BIER. For BIER. For terseness, some background, terms, and concepts are not
terseness, some background, terms and concepts are not repeated here. repeated here. Additionally, some text is borrowed verbatim from
Additionally, some text is borrowed verbatim from [RFC8556]. [RFC8556].
1.1. Terminologies 1.1. Terminology
* ES: Ethernet Segment. ES: Ethernet Segment
* ESI: Ethernet Segment Identifier. ESI: Ethernet Segment Identifier
* BFR: Bit-Forwarding Router. BFR: Bit-Forwarding Router
* BFIR: Bit-Forwarding Ingress Router. BFIR: Bit-Forwarding Ingress Router
* BFER: Bit-Forwarding Egress Router. BFER: Bit-Forwarding Egress Router
* BFR-Prefix: An IP address that uniquely identifies a BFR and is BFR-Prefix: An IP address that uniquely identifies a BFR and is
routable in a BIER domain. routable in a BIER domain.
* C-S: A multicast source address identifying a multicast source C-S: A multicast source address identifying a multicast source
located at an EVPN customer site. "C-" stands for "Customer-". located at an EVPN customer site. "C-" stands for "Customer-".
* C-G: A multicast group address used by an EVPN customer. C-G: A multicast group address used by an EVPN customer.
* C-flow: A customer multicast flow. Each C-flow is identified by C-flow: A customer multicast flow. Each C-flow is identified by the
the ordered pair (source address, group address), where each ordered pair (source address, group address), where each address
address is in the customer's address space. The identifier of a is in the customer's address space. The identifier of a
particular C-flow is usually written as (C-S, C-G). Sets of 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 C-flows can be denoted by the use of the "C-*" wildcard (see
[RFC6625]), e.g., (C-*, C-G). [RFC6625]), e.g., (C-*, C-G).
* P-tunnel. A multicast tunnel through the network of one or more P-tunnel: A multicast tunnel through the network of one or more
service providers used to transport C-flows. "P-" stands for service providers used to transport C-flows. "P-" stands for
"Provider-". "Provider-".
* IMET Route: Inclusive Multicast Ethernet Tag Auto-Discovery route. IMET A-D Route: Inclusive Multicast Ethernet Tag Auto-Discovery
Carried in BGP Update messages, these routes are used to advertise route. Carried in BGP Update messages, these routes are used to
the "default" P-tunnel for a particular broadcast domain. advertise the "default" P-tunnel for a particular BD.
* SMET Route: Selective Multicast Ethernet Tag Auto-Discovery route. SMET A-D Route: Selective Multicast Ethernet Tag Auto-Discovery
Carried in BGP Update messages, these routes are used to advertise route. Carried in BGP Update messages, these routes are used to
the C-flows that the advertising PE is interested in. advertise the C-flows that the advertising Provider Edge (PE) is
interested in.
* PMSI [RFC6513]: Provider Multicast Service Interface - a PMSI: Provider Multicast Service Interface [RFC6513]. A conceptual
conceptual interface for a PE to send customer multicast traffic interface used by a PE to send customer multicast traffic to all
to all or some PEs in the same VPN. or some PEs in the same VPN.
* I-PMSI: Inclusive PMSI - to all PEs in the same VPN. I-PMSI: Inclusive PMSI. For all PEs in the same VPN.
* S-PMSI: Selective PMSI - to some of the 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 I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to
advertise the tunnels that instantiate an I-PMSI. advertise the tunnels that instantiate an I-PMSI.
* S-PMSI A-D route: Selective PMSI Auto-Discovery route used to S-PMSI A-D Route: Selective PMSI Auto-Discovery route used to
advertise that particular C-flows are bound to (i.e., are advertise that particular C-flows are bound to (i.e., are
traveling through) particular P-tunnels. traveling through) particular P-tunnels.
* PMSI Tunnel attribute (PTA): A BGP attribute used to identify a PTA: PMSI Tunnel Attribute. A BGP attribute used to identify a
particular P-tunnel. particular P-tunnel.
* VXLAN [RFC7348]: Virtual eXtensible Local Area Network. VXLAN: Virtual eXtensible Local Area Network [RFC7348]
* NVGRE [RFC7637]: Network Virtualization using Generic Routing NVGRE: Network Virtualization Using Generic Routing Encapsulation
Encapsulation. [RFC7637]
* GENEVE [RFC8926]: Generic Network Virtualization Encapsulation. GENEVE: Generic Network Virtualization Encapsulation [RFC8926]
* VNI: VXLAN Network Identifier. VNI: VXLAN Network Identifier
* VSID: Virtual Subnet IDentifier. VSID: Virtual Subnet Identifier
* RSVP-P2MP [RFC4875]: Resource ReserVation Protocol for Point-to- RSVP-TE P2MP: Resource Reservation Protocol for Point-to-Multipoint
Multipoint TE Label Switched Paths. TE Label Switched Paths (LSPs) [RFC4875]
* mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for mLDP P2MP: Multipoint Label Distribution Protocol extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Point-to-Multipoint LSPs [RFC6388]
Paths.
1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Use of the PMSI Tunnel Attribute 2. Use of the PMSI Tunnel Attribute
[RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET) [RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET)
routes carry a PMSI Tunnel Attribute (PTA) to identify the particular routes carry a PMSI Tunnel Attribute (PTA) to identify the particular
P-tunnel to which one or more BUM flows are being assigned, the same P-tunnel to which one or more BUM flows are being assigned, which is
as specified in [RFC6514] for MVPN. [RFC8556] specifies the encoding the same as specified in [RFC6514] for MVPN. [RFC8556] specifies the
of PTA for the use of BIER with MVPN. Much of that specification is encoding of the PTA for the use of BIER with MVPN. Much of that
reused for the use of BIER with EVPN and much of the text below is specification is reused for the use of BIER with EVPN, and much of
borrowed verbatim from [RFC8556]. the text below is borrowed verbatim from [RFC8556].
The PMSI Tunnel Attribute (PTA) contains the following fields: The PTA contains the following fields:
* "Tunnel Type". The same codepoint 0x0B that IANA has assigned for * Tunnel Type. The same codepoint 0x0B that IANA has assigned for
BIER for MVPN [RFC8556] is used for EVPN as well. BIER for MVPN [RFC8556] is used for EVPN as well.
* "Tunnel Identifier". This field contains three subfields for * Tunnel Identifier. This field contains three subfields for BIER.
BIER. The text below is exactly as in [RFC8556]. The text below is exactly as in [RFC8556].
1 The first subfield is a single octet, containing the sub- 1. The first subfield is a single octet, containing a BIER sub-
domain-id of the sub-domain to which the BFIR will assign the domain-id (see [RFC8279]). This indicates that packets sent
packets that it transmits on the PMSI identified by the Network on the PMSI will be sent on the specified BIER sub-domain.
Layer Reachability Information (NLRI) of the IMET, S-PMSI A-D, How that sub-domain is chosen is outside the scope of this
or per-region I-PMSI A-D route that contains this PTA. How document.
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, 2. The second subfield is a two-octet field containing the BFR-id
in the sub-domain identified in the first subfield, of the in the sub-domain identified in the first subfield of the
router that is constructing the PTA. router that is constructing the PTA.
3 The third subfield is the BFR-Prefix (see [RFC8279]) of the 3. The third subfield is the BFR-Prefix (see [RFC8279]) of the
originator of the route that is carrying this PTA. This will router (a BFIR) that is constructing the PTA. The BFR-Prefix
either be a /32 IPv4 address or a /128 IPv6 address. Whether will either be a /32 IPv4 address or a /128 IPv6 address.
the address is IPv4 or IPv6 can be inferred from the total Whether the address is IPv4 or IPv6 can be inferred from the
length of the PMSI Tunnel attribute. total length of the PTA.
The BFR-prefix need not be the same IP address that is carried 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 in any other field of the x-PMSI A-D route, even if the BFIR
the originating router of the x-PMSI A-D route. is the originating router of the x-PMSI A-D route.
* "MPLS label". For EVPN-MPLS [RFC7432], this field contains an * MPLS Label. For EVPN-MPLS [RFC7432], this field contains an
upstream-assigned MPLS label. It is assigned by the BFIR. upstream-assigned MPLS label. It is assigned by the BFIR.
Constraints on how the originating router selects this label are Constraints on how the originating router selects this label are
discussed in Section 2.3. For EVPN-VXLAN/NVGRE/GENEVE [RFC8365] discussed in Section 2.3. For EVPN-VXLAN/NVGRE/GENEVE [RFC8365]
[RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of [RFC7348] [RFC7637] [RFC8926], this field is a 24-bit VNI/VSID of
global significance. global significance.
* "Flags". When the tunnel type is BIER, two of the flags in the * Flags. When the tunnel type is BIER, two of the flags in the PTA
PTA Flags field are meaningful. Details about the use of these Flags field are meaningful. Details about the use of these flags
flags can be found in Section 2.2. can be found in Section 2.2.
- "Leaf Info Required per Flow (LIR-pF)" [RFC8534] - Leaf Info Required per Flow (LIR-pF) [RFC8534]
- "Leaf Info Required Bit (LIR)" - Leaf Info Required (LIR)
Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI 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 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 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 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 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 domain, the route must be distributed only within the BIER domain in
which the BFR-Prefix in the PTA uniquely identifies the originator. which the BFR-Prefix in the PTA uniquely identifies the originator.
As with all MVPN routes, the distribution of these routes is As with all MVPN routes, the distribution of these routes is
controlled by the provisioning of Route Targets. controlled by the provisioning of Route Targets.
2.1. IP-Based Tunnel and BIER PHP 2.1. IP-Based Tunnel and BIER PHP
When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP 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 header (and UDP header in the case of VXLAN/GENEVE) is not included
in the BIER payload, except when it is known apriori that BIER in the BIER payload, except when it is known a priori that BIER
Penultimate Hop Popping (PHP) [I-D.ietf-bier-php] is used in the BIER Penultimate Hop Popping (PHP) [BIER-PHP] is used in the BIER domain
domain and the encapsulation (after the BIER header is popped) and the encapsulation (after the BIER header is popped) between the
between the BIER Penultimate Hop and the egress PE does not have a BIER Penultimate Hop and the egress PE does not have a way to
way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case indicate the next header is VXLAN/NVGRE/GENEVE. In that case, the
the full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer IP
IP header, a well-known IP multicast address (to be assigned by IANA) header, a well-known IP multicast address (224.0.0.122 in the case of
is used as the destination address and the egress PEs MUST be set up IPv4 or FF02:0:0:0:0:0:0:14 in the case of IPv6) is used as the
to receive and process packets addressed to the address. The address destination address, and the egress PEs MUST be set up to receive and
is used for all Broadcast Domains (BDs) and the inner VXLAN/NVGRE/ process packets addressed to the destination address. The address is
GENEVE header will be used to identify BDs. used for all BDs, and the inner VXLAN/NVGRE/GENEVE header will be
used to identify BDs.
2.2. Explicit Tracking 2.2. Explicit Tracking
When using BIER to transport an EVPN BUM data packet through a BIER When using BIER to transport an EVPN BUM data packet through a BIER
domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR
must determine the set of BFERs to which the packet needs to be must determine the set of BFERs to which the packet needs to be
delivered. This can be done in either of two ways in the following delivered. This can be done in either of two ways as described in
two sections. the following two sections.
2.2.1. Using IMET/SMET routes 2.2.1. Using IMET/SMET Routes
Both IMET and SMET routes provide explicit tracking functionality. Both IMET and SMET routes provide explicit tracking functionality.
For an inclusive PMSI, the set of BFERs (egress PEs) includes the For an inclusive PMSI, the set of BFERs (egress PEs) includes the
originators of all IMET routes for a broadcast domain. For a originators of all IMET routes for a BD. For a selective PMSI, the
selective PMSI, the set of BFERs (egress PEs) includes the set of BFERs (egress PEs) includes the originators of corresponding
originators of corresponding SMET routes. SMET routes.
The SMET routes do not carry a PTA. When an ingress PE sends traffic 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 on a selective tunnel using BIER, it uses the upstream-assigned label
that is advertised in its IMET route. that is advertised in its IMET route.
Only when selectively forwarding is for all flows and without tunnel When only selective forwarding is used for all flows and without
segmentation, SMET routes are used without the need for S-PMSI A-D tunnel segmentation, SMET routes are used without the need for S-PMSI
routes. Otherwise, the procedures in the following section apply. A-D routes. Otherwise, the procedures in the following section
apply.
2.2.2. Using S-PMSI/Leaf A-D Routes 2.2.2. Using S-PMSI/Leaf A-D Routes
There are two cases where S-PMSI/Leaf A-D routes are used as There are two cases where S-PMSI/Leaf A-D routes are used as
discussed in the following two sections. discussed in the following two sections.
2.2.2.1. Selective Forwarding Only for Some Flows 2.2.2.1. Selective Forwarding Only for Some Flows
With the SMET procedure, a PE advertises an SMET route for each (C-S, 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 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 (ACs), and each SMET route is tracked by every PE in the same BD. It
broadcast domain. It may be desired that SMET routes are not used, may be desired that SMET routes are not used in order to reduce the
in order to reduce the burden of explicit tracking. burden of explicit tracking.
In this case, most multicast traffic will follow the I-PMSI In this case, most multicast traffic will follow the I-PMSI
(advertised via IMET route) and only some flows follow S-PMSIs. To (advertised via the IMET route) and only some flows will follow
achieve that, S-PMSI/Leaf A-D routes can be used, as specified in S-PMSIs. To achieve that, S-PMSI/Leaf A-D routes can be used, as
[I-D.ietf-bess-evpn-bum-procedure-updates]. specified in [RFC9572].
The rules specified in Section 2.2.1 and Section 2.2.2 of [RFC8556] The rules specified in Sections 2.2.1 and 2.2.2 of [RFC8556] apply.
apply.
2.2.2.2. Tunnel Segmentation 2.2.2.2. Tunnel Segmentation
Another case where S-PMSI/Leaf A-D routes are necessary is tunnel Another case where S-PMSI/Leaf A-D routes are necessary is tunnel
segmentation, which is also specified in segmentation, which is also specified in [RFC9572] and further
[I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in clarified in [CMCAST-ENHANCEMENTS] for segmentation with SMET routes.
[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with This is only applicable to EVPN-MPLS.
SMET routes. This is only applicable to EVPN-MPLS.
The rules specified in Section 2.2.1 of [RFC8556] apply. The rules specified in Section 2.2.1 of [RFC8556] apply.
Section 2.2.2 of [RFC8556] does not apply, because like in MVPN, the Section 2.2.2 of [RFC8556] does not apply, because like in MVPN, the
LIR-pF flag cannot be used with segmentation. LIR-pF flag cannot be used with segmentation.
2.2.2.3. Applicability of Additional MVPN Specifications 2.2.2.3. Applicability of Additional MVPN Specifications
As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute As with the MVPN case, "Use of the PMSI Tunnel Attribute in Leaf A-D
in Leaf A-D routes" of [RFC8556] apply. Routes" (Section 3 of [RFC8556]) applies.
Notice that, [RFC8556] refers to procedures specified in [RFC6625] Notice that [RFC8556] refers to procedures specified in [RFC6625] and
and [RFC8534]. Those two documents were specified for MVPN but apply [RFC8534]. Those two documents were specified for MVPN but apply to
to IP multicast payload in EVPN as well. IP multicast payload in EVPN as well.
2.3. MPLS Label in PTA 2.3. MPLS Label in the PTA
Rules in section 2.1 of [RFC8556] apply, EXCEPT the following three Rules in Section 2.1 of [RFC8556] apply, EXCEPT the following three
bullets (they do NOT apply to EVPN) in that section: bullets (they do NOT apply to EVPN) in that section:
* If the two routes do not have the same Address Family Identifier * If the two routes do not have the same Address Family Identifier
(AFI) value, then their respective PTAs MUST contain different (AFI) value, then their respective PTAs MUST contain different
MPLS label values. This ensures that when an egress PE receives a 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 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. label whether the payload is an IPv4 packet or an IPv6 packet.
* If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) * If the BFIR is an ingress PE supporting MVPN extranet [RFC7900]
functionality, and if the two routes originate from different VRFs functionality, and if the two routes originate from different VRFs
on this ingress PE, then the respective PTAs of the two routes on this ingress PE, then the respective PTAs of the two routes
MUST contain different MPLS label values. MUST contain different MPLS label values.
* If the BFIR is an ingress PE supporting the "Extranet Separation" * If the BFIR is an ingress PE supporting the "Extranet Separation"
feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if
one of the routes carries the "Extranet Separation" extended one of the routes carries the "Extranet Separation" extended
community but the other does not, then the respective PTAs of the community but the other does not, then the respective PTAs of the
two routes MUST contain different MPLS label values. two routes MUST contain different MPLS label values.
3. Multihoming Split Horizon 3. Multihoming Split Horizon
For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify
the ES from which a BUM packet originates. A PE receiving that 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 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 procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP
P2MP tunnels, using downstream- and upstream-assigned ESI labels P2MP tunnels, using downstream- and upstream-assigned ESI labels,
respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local respectively. For EVPN-VXLAN/NVGRE/GENEVE, [RFC8365] specifies local
bias procedures, with which a PE receiving a BUM packet from the core bias procedures, where a PE receiving a BUM packet from the core side
side knows from encapsulation the ingress PE so it does not forward knows the ingress PE due to encapsulation; therefore, the PE does not
the packet to any multihoming ESes that the ingress PE is on. This forward the packet to any multihoming ESes that the ingress PE is on.
is because the ingress PE already forwarded the packet to those ESes This is because the ingress PE already forwarded the packet to those
regardless of whether the ingress PE is a Designated Forwarder for ESes, regardless of whether the ingress PE is a Designated Forwarder
those ESes. for those ESes.
With BIER, the local bias procedure still applies for EVPN- With BIER, the local bias procedure still applies for EVPN-
VXLAN/NVGRE/GENEVE as the BFIR-id in the BIER header identifies the VXLAN/NVGRE/GENEVE, as the BFIR-id in the BIER header identifies the
ingress PE. For EVPN-MPLS, ESI label procedures also still apply ingress PE. For EVPN-MPLS, ESI label procedures also still apply,
though two upstream-assigned labels will be used (one for identifying though two upstream-assigned labels will be used (one for identifying
the broadcast domain and one for identifying the ES) - the same as in the BD and one for identifying the ES) -- the same as in the case of
the case of using a single P2MP tunnel for multiple broadcast using a single P2MP tunnel for multiple BDs. The BFIR-id in the BIER
domains. The BFIR-id in the BIER header identifies the ingress PE header identifies the ingress PE that assigned those two labels.
that assigned those two labels.
4. Data Plane 4. Data Plane
Like MVPN, the EVPN application plays the role of the "multicast flow Like MVPN, the EVPN application plays the role of the "multicast flow
overlay" as described in [RFC8279]. overlay" as described in [RFC8279].
4.1. Encapsulation and Transmission 4.1. Encapsulation and Transmission
A BFIR could be either an ingress PE or a P-tunnel segmentation A BFIR could be either an ingress PE or a P-tunnel segmentation
point. The procedures are slightly different as described below. point. The procedures are slightly different as described below.
4.1.1. At a BFIR that is an Ingress PE 4.1.1. At a BFIR That Is an Ingress PE
To transmit a BUM data packet, an ingress PE first determines the To transmit a BUM data packet, an ingress PE first determines the
route matched for transmission and routes for tracking leaves route matched for transmission and routes for tracking leaves
according to the following rules. according to the following rules.
1. If selective forwarding is not used, or it is not an IP Multicast 1. If selective forwarding is not used or is not an IP multicast
packet after the Ethernet header, the IMET route originated for packet after the Ethernet header, the IMET route originated for
the BD by the ingress PE is the route matched for transmission. the BD by the ingress PE is the route matched for transmission.
Leaf tracking routes are all other received IMET routes for the Leaf-tracking routes are all other received IMET routes for the
BD. BD.
2. Otherwise, if selective forwarding is used for all IP Multicast 2. Otherwise, if selective forwarding is used for all IP multicast
traffic based on SMET routes, the IMET route originated for the traffic based on SMET routes, the IMET route originated for the
BD by the ingress PE is the route matched for transmission. BD by the ingress PE is the route matched for transmission.
Received SMET routes for the BD whose source and destination Received SMET routes for the BD, whose source and destination
address fields match the packet's source and destination IP address fields match the packet's source and destination IP
address are leaf tracking routes. address, are leaf-tracking routes.
3. Otherwise, the route matched for transmission is the S-PMSI A-D 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 route originated by the ingress PE for the BD, whose source and
destination address fields match the packet's source and destination address fields match the packet's source and
destination IP address and has a PTA specifying a valid tunnel destination IP address and have a PTA specifying a valid tunnel
type that is not "no tunnel info". Leaf tracking routes are type that is not "no tunnel info". Leaf-tracking routes are
determined as follows: determined as follows:
1) If the match for transmission route carries a PTA that has a. If the match for the transmission route carries a PTA that
the LIR flag set but does not have the LIR-pF flag set, the has the LIR flag set but does not have the LIR-pF flag set,
routes matched for tracking are Leaf A-D routes whose "route the routes matched for tracking are Leaf A-D routes whose
key" field is identical to the NLRI of the S-PMSI A-D route. Route Key field is identical to the NLRI of the S-PMSI A-D
route.
2) If the match for transmission route carries a PTA that has b. If the match for the transmission route carries a PTA that
the LIR-pF flag, the leaf tracking routes are Leaf A-D routes has the LIR-pF flag, the leaf-tracking routes are Leaf A-D
whose "route key" field is derived from the NLRI of the routes whose Route Key field is derived from the NLRI of the
S-PMSI A-D route according to the procedures described in S-PMSI A-D route according to the procedures described in
Section 5.2 of [RFC8534]. Section 5.2 of [RFC8534].
Note that in both cases, SMET routes may be used in lieu of Leaf 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 A-D routes, as a PE may omit the Leaf A-D route in response to an
S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route 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 with the corresponding Tag, Source, and Group fields is already
originated [I-D.ietf-bess-evpn-bum-procedure-updates]. In originated [RFC9572]. In particular, in the second case above,
particular, in the second case above, even though the SMET route even though the SMET route does not have a PTA attached, it is
does not have a PTA attached, it is still considered a Leaf A-D still considered a Leaf A-D route in response to a wildcard
route in response to a wildcard S-PMSI A-D route with the LIR-pF S-PMSI A-D route with the LIR-pF bit set.
bit set.
4. Otherwise, the route matched for transmission and leaf tracking 4. Otherwise, the route matched for transmission and leaf-tracking
routes are determined as in rule 1. routes are determined as in rule 1.
If no route is matched for transmission, the packet is not forwarded 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 onto a P-tunnel. If the tunnel that the ingress determines to use
based on the route matched for transmission (and considering based on the route matched for transmission (and considering
interworking with PEs that do not support certain tunnel types per interworking with PEs that do not support certain tunnel types per
procedures in [RFC9251]) requires leaf tracking (e.g. Ingress procedures in [RFC9251]) requires leaf tracking (e.g., Ingress
Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf-
tracking routes, the packet will not be forwarded onto a P-tunnel tracking routes, the packet will not be forwarded onto a P-tunnel
either. either.
The following text assumes that BIER is the determined tunnel type. The following text assumes that BIER is the determined tunnel type.
The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if
the following conditions are all met: the following conditions are all met:
* The packet is received on a multihomed ES. * The packet is received on a multihomed ES.
* It's EVPN-MPLS. * It is EVPN-MPLS.
* ESI label procedure is used for split-horizon. * The ESI label procedure is used for split horizon.
The MPLS label from the PTA of the route matched for transmission is 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- 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 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, 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 and then an IP/UDP header is prepended if needed (e.g., for PHP
purpose). purposes).
Then the packet is encapsulated in a BIER header and forwarded, Then, the packet is encapsulated in a BIER header and forwarded
according to the procedures of [RFC8279] and [RFC8296]. See according to the procedures of [RFC8279] and [RFC8296].
especially Section 4, "Imposing and Processing the BIER Specifically, see "Imposing and Processing the BIER Encapsulation"
Encapsulation", of [RFC8296]. The "Proto" field in the BIER header (Section 3 of [RFC8296]). The Proto field in the BIER header is set
is set to 2 in the case of EVPN-MPLS, or a value to be assigned in to 2 in the case of EVPN-MPLS, 7/8/9 in the case of EVPN-VXLAN/NVGRE/
the case of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when an IP header is GENEVE (Section 5) when an IP header is not used, or 4/6 if an IP
not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE. header is used for EVPN-VXLAN/NVGRE/GENEVE.
To create the proper BIER header for a given packet, the BFIR must 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 know all the BFERs that need to receive that packet. This is
determined from the set of leaf tracking routes. determined from the set of leaf-tracking routes.
4.1.2. At a BFIR that is a P-tunnel Segmentation Point 4.1.2. At a BFIR That Is a P-Tunnel Segmentation Point
In this case, the encapsulation for the upstream segment of the In this case, the encapsulation for the upstream segment of the
P-tunnel includes (among other things) a label that identifies 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 x-PMSI or IMET A-D route that is the match for reception on the
upstream segment. The segmentation point re-advertised the route upstream segment. The segmentation point re-advertised the route
into one or more downstream regions. Each instance of the re- into one or more downstream regions. Each instance of the re-
advertised route for a downstream region has a PTA that specifies the advertised route for a downstream region has a PTA that specifies the
tunnel for that region. For any particular downstream region, the tunnel for that region. For any particular downstream region, the
route matched for transmission is the re-advertised route and the route matched for transmission is the re-advertised route, and the
leaf tracking routes are determined as follows if needed for the leaf-tracking routes are determined as follows, if needed, for the
tunnel type: tunnel type:
* If the route matched for transmission is an x-PMSI route, it must * 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 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 all the matching Leaf A-D and SMET routes received in the
downstream region. downstream region.
* If the route matched for transmission is an IMET route, the leaf * If the route matched for transmission is an IMET route, the leaf-
tracking routes are all the IMET routes for the same BD received tracking routes are all the IMET routes for the same BD received
in the downstream region. in the downstream region.
If the downstream region uses BIER, the packet is forwarded as If the downstream region uses BIER, the packet is forwarded as
follows: the upstream segmentation's encapsulation is removed and the follows: the upstream segmentation's encapsulation is removed and the
above-mentioned label is swapped to the upstream-assigned label in above-mentioned label is swapped to the upstream-assigned label in
the PTA of the route matched for transmission, and then a BIER header the PTA of the route matched for transmission, and then a BIER header
is imposed as in Section 4.1.1. is imposed as in Section 4.1.1.
4.2. Disposition 4.2. Disposition
The same procedures in section 4.2 of [RFC8556] are followed for The same procedures in Section 4.2 of [RFC8556] are followed for
EVPN-MPLS, except some EVPN specifics discussed in the following two EVPN-MPLS, except for some EVPN specifics that are discussed in the
sub-sections in this document. following two subsections of this document.
For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the
is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID payload is VXLAN/NVGRE/GENEVE (with or without an IP header) and the
field in the VXLAN/NVGRE/GENEVE header is used to determine the VNI/VSID field in the VXLAN/NVGRE/GENEVE header is used to determine
corresponding broadcast domain. the corresponding BD.
4.2.1. At a BFER that is an Egress PE 4.2.1. At a BFER That Is an Egress PE
Once the corresponding broadcast domain is determined from the Once the corresponding BD is determined from the upstream-assigned
upstream-assigned label or VNI/VSID, EVPN forwarding procedures per label or VNI/VSID, EVPN forwarding procedures per [RFC7432] or
[RFC7432] or [RFC8365] are followed. In the case of EVPN-MPLS, if [RFC8365] are followed. In the case of EVPN-MPLS, if there is an
there is an inner label in the label stack following the BIER header, inner label in the label stack following the BIER header, that inner
that inner label is considered the upstream-assigned ESI label for label is considered the upstream-assigned ESI label for split-horizon
split horizon purpose. purposes.
4.2.2. At a BFER that is a P-tunnel Segmentation Point 4.2.2. At a BFER That Is a P-Tunnel Segmentation Point
This is only applicable to EVPN-MPLS. The same procedures in This is only applicable to EVPN-MPLS. The same procedures in
Section 4.2.2 of [RFC8556] are followed, subject to multihoming Section 4.2.2 of [RFC8556] are followed, subject to multihoming
procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates]. procedures specified in [RFC9572].
5. IANA Considerations 5. IANA Considerations
This document requests three assignments in "BIER Next Protocol Per this document, IANA has registered the following three values in
Identifiers" registry, with the following three recommended values: the "BIER Next Protocol Identifiers" registry:
* 7: Payload is VXLAN encapsulated (no IP/UDP header) +=======+================================+===========+
| Value | Description | Reference |
+=======+================================+===========+
| 7 | Payload is VXLAN encapsulated | RFC 9624 |
| | (no IP/UDP header) | |
+-------+--------------------------------+-----------+
| 8 | Payload is NVGRE encapsulated | RFC 9624 |
| | (no IP header) | |
+-------+--------------------------------+-----------+
| 9 | Payload is GENEVE encapsulated | RFC 9624 |
| | (no IP/UDP header) | |
+-------+--------------------------------+-----------+
* 8: Payload is NVGRE encapsulated (no IP header) Table 1: BIER Next Protocol Identifiers Registry
* 9: Payload is GENEVE encapsulated (no IP/UDP header) IANA has also assigned an IPv4 and an IPv6 multicast address for the
case discussed in Section 2.1.
This document requests assignments of an IPv4 and an IPv6 multicast The following entry has been added to the "Local Network Control
address for the case discussed in Section 2.1. Preferably this is Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:
assigned from the Local Network Control Block (224.0.0/24) for IPv4
and Link-Local Scope Multicast Addresses for IPv6. The description Address(es): 224.0.0.122
is "NVO BUM Traffic". 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
6. Security Considerations 6. Security Considerations
This document is about using BIER as provider tunnels for EVPN. It This document is about using BIER as provider tunnels for EVPN. It
is very similar to using BIER as MVPN provider tunnel, and does not is very similar to using BIER as MVPN provider tunnels and does not
introduce additional security implications beyond what have been introduce additional security implications beyond what have been
discussed in EVPN base protocol specification [RFC7432] and MVPN discussed in the EVPN base protocol specification [RFC7432] and MVPN
using BIER [RFC8556]. using BIER [RFC8556].
7. Acknowledgements 7. References
The authors thank Eric Rosen for his review and suggestions.
Additionally, much of the text is borrowed verbatim from [RFC8556].
8. References
8.1. Normative References
[I-D.ietf-bess-evpn-bum-procedure-updates] 7.1. Normative References
Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
procedure-updates-14, 18 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-bum-procedure-updates-14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
skipping to change at page 14, line 38 skipping to change at line 647
"Geneve: Generic Network Virtualization Encapsulation", "Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020, RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>. <https://www.rfc-editor.org/info/rfc8926>.
[RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., [RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
and W. Lin, "Internet Group Management Protocol (IGMP) and and W. Lin, "Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Proxies for Ethernet Multicast Listener Discovery (MLD) Proxies for Ethernet
VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022, VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
<https://www.rfc-editor.org/info/rfc9251>. <https://www.rfc-editor.org/info/rfc9251>.
8.2. Informative References [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>.
[I-D.ietf-bier-php] 7.2. Informative References
Zhang, Z. J., "BIER Penultimate Hop Popping", Work in
Progress, Internet-Draft, draft-ietf-bier-php-10, 9 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
bier-php-10>.
[I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] [BIER-PHP] Zhang, Z., "BIER Penultimate Hop Popping", Work in
Zhang, Z. J., Kebler, R., Lin, W., and E. C. Rosen, "MVPN/ Progress, Internet-Draft, draft-ietf-bier-php-11, 6
EVPN C-Multicast Routes Enhancements", Work in Progress, February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-php-11>.
[CMCAST-ENHANCEMENTS]
Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN
C-Multicast Routes Enhancements", Work in Progress,
Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast- Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast-
enhancements-03, 1 September 2023, enhancements-04, 17 March 2024,
<https://datatracker.ietf.org/doc/html/draft-zzhang-bess- <https://datatracker.ietf.org/doc/html/draft-zzhang-bess-
mvpn-evpn-cmcast-enhancements-03>. mvpn-evpn-cmcast-enhancements-04>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point- Thomas, "Label Distribution Protocol Extensions for Point-
skipping to change at page 15, line 30 skipping to change at line 693
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
Acknowledgements
The authors thank Eric Rosen for his review and suggestions.
Additionally, much of the text is borrowed verbatim from [RFC8556].
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
Email: zzhang@juniper.net Email: zzhang@juniper.net
Antoni Przygienda Tony Przygienda
Juniper Networks Juniper Networks
Email: prz@juniper.net Email: prz@juniper.net
Ali Sajassi Ali Sajassi
Cisco Systems Cisco Systems
Email: sajassi@cisco.com Email: sajassi@cisco.com
Jorge Rabadan Jorge Rabadan
Nokia Nokia
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
 End of changes. 114 change blocks. 
291 lines changed or deleted 304 lines changed or added

This html diff was produced by rfcdiff 1.48.