draft-ietf-bess-evpn-optimized-ir-03.txt   draft-ietf-bess-evpn-optimized-ir-04.txt 
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet Draft S. Sathappan Internet Draft S. Sathappan
Intended status: Standards Track W. Henderickx Intended status: Standards Track Nokia
Nokia
R. Shekhar W. Lin
N. Sheth A. Sajassi
W. Lin Cisco
Juniper
A. Isaac
Juniper Juniper
M. Tufail
Citibank M. Katiyar M. Katiyar
Versa Networks Versa Networks
Expires: August 27, 2018 February 23, 2018 A. Sajassi
Cisco
Expires: April 3, 2019 September 30, 2018
Optimized Ingress Replication solution for EVPN Optimized Ingress Replication solution for EVPN
draft-ietf-bess-evpn-optimized-ir-03 draft-ietf-bess-evpn-optimized-ir-04
Abstract Abstract
Network Virtualization Overlay (NVO) networks using EVPN as control Network Virtualization Overlay (NVO) networks using EVPN as control
plane may use ingress replication (IR) or PIM-based trees to convey plane may use ingress replication (IR) or PIM-based trees to convey
the overlay BUM traffic. PIM provides an efficient solution to avoid the overlay BUM traffic. PIM provides an efficient solution to avoid
sending multiple copies of the same packet over the same physical sending multiple copies of the same packet over the same physical
link, however it may not always be deployed in the NVO core network. link, however it may not always be deployed in the NVO core network.
IR avoids the dependency on PIM in the NVO network core. While IR IR avoids the dependency on PIM in the NVO network core. While IR
provides a simple multicast transport, some NVO networks with provides a simple multicast transport, some NVO networks with
skipping to change at page 2, line 13 skipping to change at page 2, line 13
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 27, 2018. This Internet-Draft will expire on April 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 4 2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 4
3. EVPN BGP Attributes for optimized-IR . . . . . . . . . . . . . 5 3. EVPN BGP Attributes for optimized-IR . . . . . . . . . . . . . 5
4. Non-selective Assisted-Replication (AR) Solution Description . 7 4. Non-selective Assisted-Replication (AR) Solution Description . 8
4.1. Non-selective AR-REPLICATOR procedures . . . . . . . . . . 8 4.1. Non-selective AR-REPLICATOR procedures . . . . . . . . . . 8
4.2. Non-selective AR-LEAF procedures . . . . . . . . . . . . . 9 4.2. Non-selective AR-LEAF procedures . . . . . . . . . . . . . 9
4.3. RNVE procedures . . . . . . . . . . . . . . . . . . . . . . 11 4.3. RNVE procedures . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Forwarding behavior in non-selective AR EVIs . . . . . . . 11 4.4. Forwarding behavior in non-selective AR EVIs . . . . . . . 11
4.4.1. Broadcast and Multicast forwarding behavior . . . . . . 11 4.4.1. Broadcast and Multicast forwarding behavior . . . . . . 11
4.4.1.1. Non-selective AR-REPLICATOR BM forwarding . . . . . 11 4.4.1.1. Non-selective AR-REPLICATOR BM forwarding . . . . . 11
4.4.1.2. Non-selective AR-LEAF BM forwarding . . . . . . . . 12 4.4.1.2. Non-selective AR-LEAF BM forwarding . . . . . . . . 12
4.4.1.3. RNVE BM forwarding . . . . . . . . . . . . . . . . 12 4.4.1.3. RNVE BM forwarding . . . . . . . . . . . . . . . . 12
4.4.2. Unknown unicast forwarding behavior . . . . . . . . . . 13 4.4.2. Unknown unicast forwarding behavior . . . . . . . . . . 13
4.4.2.1. Non-selective AR-REPLICATOR/LEAF Unknown unicast 4.4.2.1. Non-selective AR-REPLICATOR/LEAF Unknown unicast
skipping to change at page 3, line 11 skipping to change at page 3, line 11
4.4.2.2. RNVE Unknown unicast forwarding . . . . . . . . . . 13 4.4.2.2. RNVE Unknown unicast forwarding . . . . . . . . . . 13
5. Selective Assisted-Replication (AR) Solution Description . . . 13 5. Selective Assisted-Replication (AR) Solution Description . . . 13
5.1. Selective AR-REPLICATOR procedures . . . . . . . . . . . . 14 5.1. Selective AR-REPLICATOR procedures . . . . . . . . . . . . 14
5.2. Selective AR-LEAF procedures . . . . . . . . . . . . . . . 15 5.2. Selective AR-LEAF procedures . . . . . . . . . . . . . . . 15
5.3. Forwarding behavior in selective AR EVIs . . . . . . . . . 16 5.3. Forwarding behavior in selective AR EVIs . . . . . . . . . 16
5.3.1. Selective AR-REPLICATOR BM forwarding . . . . . . . . . 16 5.3.1. Selective AR-REPLICATOR BM forwarding . . . . . . . . . 16
5.3.2. Selective AR-LEAF BM forwarding . . . . . . . . . . . . 17 5.3.2. Selective AR-LEAF BM forwarding . . . . . . . . . . . . 17
6. Pruned-Flood-Lists (PFL) . . . . . . . . . . . . . . . . . . . 18 6. Pruned-Flood-Lists (PFL) . . . . . . . . . . . . . . . . . . . 18
6.1. A PFL example . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. A PFL example . . . . . . . . . . . . . . . . . . . . . . . 18
7. AR Procedures for single-IP AR-REPLICATORS . . . . . . . . . . 19 7. AR Procedures for single-IP AR-REPLICATORS . . . . . . . . . . 19
8. AR Procedures and EVPN Multi-homing Split-Horizon . . . . . . . 20 8. AR Procedures and EVPN All-Active Multi-homing Split-Horizon . 20
9. Out-of-band distribution of Broadcast/Multicast traffic . . . . 21 8.1. Ethernet Segments on AR-LEAF nodes . . . . . . . . . . . . 20
10. Benefits of the optimized-IR solution . . . . . . . . . . . . 21 8.2. Ethernet Segments on AR-REPLICATOR nodes . . . . . . . . . 21
11. Conventions used in this document . . . . . . . . . . . . . . 21 9. Benefits of the optimized-IR solution . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Conventions used in this document . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1 Normative References . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.2 Informative References . . . . . . . . . . . . . . . . . . 23 14.1 Normative References . . . . . . . . . . . . . . . . . . . 23
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 14.2 Informative References . . . . . . . . . . . . . . . . . . 24
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 15.0 Contributors . . . . . . . . . . . . . . . . . . . . . . . 24
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
1. Problem Statement 1. Introduction
EVPN may be used as the control plane for a Network Virtualization EVPN may be used as the control plane for a Network Virtualization
Overlay (NVO) network. Network Virtualization Edge (NVE) devices and Overlay (NVO) network. Network Virtualization Edge (NVE) devices and
PEs that are part of the same EVI use Ingress Replication (IR) or PEs that are part of the same EVI use Ingress Replication (IR) or
PIM-based trees to transport the tenant's BUM traffic. In NVO PIM-based trees to transport the tenant's BUM traffic. In NVO
networks where PIM-based trees cannot be used, IR is the only networks where PIM-based trees cannot be used, IR is the only
alternative. Examples of these situations are NVO networks where the alternative. Examples of these situations are NVO networks where the
core nodes don't support PIM or the network operator does not want to core nodes don't support PIM or the network operator does not want to
run PIM in the core. run PIM in the core.
skipping to change at page 4, line 41 skipping to change at page 4, line 43
2. Solution requirements 2. Solution requirements
The IR optimization solution (optimized-IR hereafter) MUST meet the The IR optimization solution (optimized-IR hereafter) MUST meet the
following requirements: following requirements:
a) The solution MUST provide an IR optimization for BM (Broadcast and a) The solution MUST provide an IR optimization for BM (Broadcast and
Multicast) traffic, while preserving the packet order for unicast Multicast) traffic, while preserving the packet order for unicast
applications, i.e. known and unknown unicast traffic SHALL follow applications, i.e. known and unknown unicast traffic SHALL follow
the same path. the same path.
b) The solution MUST be compatible with [RFC7432] and [EVPN-OVERLAY] b) The solution MUST be compatible with [RFC7432] and [RFC8365] and
and have no impact on the EVPN procedures for BM traffic. In have no impact on the EVPN procedures for BM traffic. In
particular, the solution SHOULD support the following EVPN particular, the solution SHOULD support the following EVPN
functions: functions:
o All-active multi-homing, including the split-horizon and o All-active multi-homing, including the split-horizon and
Designated Forwarder (DF) functions. Designated Forwarder (DF) functions.
o Single-active multi-homing, including the DF function. o Single-active multi-homing, including the DF function.
o Handling of multi-destination traffic and processing of o Handling of multi-destination traffic and processing of
broadcast and multicast as per [RFC7432]. broadcast and multicast as per [RFC7432].
skipping to change at page 9, line 11 skipping to change at page 9, line 13
to the AR-REPLICATOR role: to the AR-REPLICATOR role:
a) The AR-REPLICATOR role SHOULD be an administrative choice in any a) The AR-REPLICATOR role SHOULD be an administrative choice in any
NVE/PE that is part of an AR-enabled EVI. This administrative NVE/PE that is part of an AR-enabled EVI. This administrative
option to enable AR-REPLICATOR capabilities MAY be implemented as option to enable AR-REPLICATOR capabilities MAY be implemented as
a system level option as opposed to as a per-MAC-VRF option. a system level option as opposed to as a per-MAC-VRF option.
b) An AR-REPLICATOR MUST advertise a Replicator-AR route and MAY b) An AR-REPLICATOR MUST advertise a Replicator-AR route and MAY
advertise a Regular-IR route. The AR-REPLICATOR MUST NOT generate advertise a Regular-IR route. The AR-REPLICATOR MUST NOT generate
a Regular-IR route if it does not have local attachment circuits a Regular-IR route if it does not have local attachment circuits
(AC). (AC). If the Regular-IR route is advertised, the AR Type field MAY
be set to AR-REPLICATOR.
c) The Replicator-AR and Regular-IR routes will be generated c) The Replicator-AR and Regular-IR routes will be generated
according to section 3. The AR-IP and IR-IP used by the according to section 3. The AR-IP and IR-IP used by the
Replicator-AR will be different routable IP addresses. Replicator-AR will be different routable IP addresses.
d) When a node defined as AR-REPLICATOR receives a packet on an d) When a node defined as AR-REPLICATOR receives a packet on an
overlay tunnel, it will do a tunnel destination IP lookup and overlay tunnel, it will do a tunnel destination IP lookup and
apply the following procedures: apply the following procedures:
o If the destination IP is the AR-REPLICATOR IR-IP Address the o If the destination IP is the AR-REPLICATOR IR-IP Address the
node will process the packet normally as in [RFC7432]. node will process the packet normally as in [RFC7432].
o If the destination IP is the AR-REPLICATOR AR-IP Address the o If the destination IP is the AR-REPLICATOR AR-IP Address the
node MUST replicate the packet to local ACs and overlay node MUST replicate the packet to local ACs and overlay
tunnels (excluding the overlay tunnel to the source of the tunnels (excluding the overlay tunnel to the source of the
packet). When replicating to remote AR-REPLICATORs the tunnel packet). When replicating to remote AR-REPLICATORs the tunnel
destination IP will be an IR-IP. That will be an indication destination IP will be an IR-IP. That will be an indication
for the remote AR-REPLICATOR that it MUST NOT replicate to for the remote AR-REPLICATOR that it MUST NOT replicate to
overlay tunnels. The tunnel source IP will be the AR-IP of the overlay tunnels. The tunnel source IP used by the AR-
AR-REPLICATOR. REPLICATOR MUST be its IR-IP.
4.2. Non-selective AR-LEAF procedures 4.2. Non-selective AR-LEAF procedures
AR-LEAF is defined as an NVE/PE that - given its poor replication AR-LEAF is defined as an NVE/PE that - given its poor replication
performance - sends all the BM traffic to an AR-REPLICATOR that can performance - sends all the BM traffic to an AR-REPLICATOR that can
replicate the traffic further on its behalf. It MAY signal its AR- replicate the traffic further on its behalf. It MAY signal its AR-
LEAF capability in the control plane and understands where the other LEAF capability in the control plane and understands where the other
roles are located (AR-REPLICATOR and RNVEs). A given service can have roles are located (AR-REPLICATOR and RNVEs). A given service can have
zero, one or more AR-LEAF nodes. Figure 1 shows NVE1 and NVE3 (both zero, one or more AR-LEAF nodes. Figure 1 shows NVE1 and NVE3 (both
residing in hypervisors) acting as AR-LEAF. The following residing in hypervisors) acting as AR-LEAF. The following
skipping to change at page 10, line 44 skipping to change at page 10, line 47
o When an AR-REPLICATOR is selected, the AR-LEAF MUST send all o When an AR-REPLICATOR is selected, the AR-LEAF MUST send all
the BM packets to that AR-REPLICATOR using the forwarding the BM packets to that AR-REPLICATOR using the forwarding
information given by the Replicator-AR route for the chosen information given by the Replicator-AR route for the chosen
AR-REPLICATOR, with tunnel type = 0x0A (AR tunnel). The AR-REPLICATOR, with tunnel type = 0x0A (AR tunnel). The
underlay destination IP address MUST be the AR-IP advertised underlay destination IP address MUST be the AR-IP advertised
by the AR-REPLICATOR in the Replicator-AR route. by the AR-REPLICATOR in the Replicator-AR route.
o AR-LEAF nodes SHALL send service-level BM control plane o AR-LEAF nodes SHALL send service-level BM control plane
packets following regular IR procedures. An example would be packets following regular IR procedures. An example would be
IGMP, MLD or PIM multicast packets. The AR-REPLICATORs MUST IGMP, MLD or PIM multicast packets. The AR-REPLICATORs MUST
not replicate these control plane packets to other overlay NOT replicate these control plane packets to other overlay
tunnels since they will use the regular IR-IP Address. tunnels since they will use the regular IR-IP Address.
e) The use of an AR-REPLICATOR-activation-timer (in seconds) on the e) The use of an AR-REPLICATOR-activation-timer (in seconds) on the
AR-LEAF nodes is RECOMMENDED. Upon receiving a new Replicator-AR AR-LEAF nodes is RECOMMENDED. Upon receiving a new Replicator-AR
route where the AR-REPLICATOR is selected, the AR-LEAF will run a route where the AR-REPLICATOR is selected, the AR-LEAF will run a
timer before programming the new AR-REPLICATOR. This will give the timer before programming the new AR-REPLICATOR. This will give the
AR-REPLICATOR some time to program the AR-LEAF nodes before the AR-REPLICATOR some time to program the AR-LEAF nodes before the
AR-LEAF sends BM traffic. AR-LEAF sends BM traffic.
4.3. RNVE procedures 4.3. RNVE procedures
skipping to change at page 12, line 10 skipping to change at page 12, line 12
forward the BM packet to its flooding list (including local ACs and forward the BM packet to its flooding list (including local ACs and
remote NVE/PEs), skipping the non-BM overlay tunnels. remote NVE/PEs), skipping the non-BM overlay tunnels.
o When an AR-REPLICATOR receives a BM packet on an overlay tunnel, it o When an AR-REPLICATOR receives a BM packet on an overlay tunnel, it
will check the destination IP of the underlay IP header and: will check the destination IP of the underlay IP header and:
- If the destination IP matches its AR-IP, the AR-REPLICATOR will - If the destination IP matches its AR-IP, the AR-REPLICATOR will
forward the BM packet to its flooding list (ACs and overlay forward the BM packet to its flooding list (ACs and overlay
tunnels) excluding the non-BM overlay tunnels. The AR-REPLICATOR tunnels) excluding the non-BM overlay tunnels. The AR-REPLICATOR
will do source squelching to ensure the traffic is not sent back will do source squelching to ensure the traffic is not sent back
to the originating AR-LEAF. If the encapsulation is MPLSoGRE (or to the originating AR-LEAF.
MPLSoUDP) and the EVI label is not the bottom of the stack, the
AR-REPLICATOR MUST copy the rest of the labels and forward them
to the egress overlay tunnels.
- If the destination IP matches its IR-IP, the AR-REPLICATOR will - If the destination IP matches its IR-IP, the AR-REPLICATOR will
skip all the overlay tunnels from the flooding list, i.e. it skip all the overlay tunnels from the flooding list, i.e. it
will only replicate to local ACs. This is the regular IR will only replicate to local ACs. This is the regular IR
behavior described in [RFC7432]. behavior described in [RFC7432].
4.4.1.2. Non-selective AR-LEAF BM forwarding 4.4.1.2. Non-selective AR-LEAF BM forwarding
The AR-LEAF nodes will build two flood-lists: The AR-LEAF nodes will build two flood-lists:
skipping to change at page 20, line 27 skipping to change at page 20, line 24
o An AR-REPLICATOR will perform IR or AR forwarding mode for the o An AR-REPLICATOR will perform IR or AR forwarding mode for the
incoming Overlay packets based on an ingress VNI lookup, as opposed incoming Overlay packets based on an ingress VNI lookup, as opposed
to the tunnel IP DA lookup described in sections 4 and 5. Note to the tunnel IP DA lookup described in sections 4 and 5. Note
that, when replicating to remote AR-REPLICATOR nodes, the use of that, when replicating to remote AR-REPLICATOR nodes, the use of
the IR-VNI or AR-VNI advertised by the egress node will determine the IR-VNI or AR-VNI advertised by the egress node will determine
the IR or AR forwarding mode at the subsequent AR-REPLICATOR. the IR or AR forwarding mode at the subsequent AR-REPLICATOR.
The rest of the procedures will follow what is described in sections The rest of the procedures will follow what is described in sections
4 and 5. 4 and 5.
8. AR Procedures and EVPN Multi-homing Split-Horizon 8. AR Procedures and EVPN All-Active Multi-homing Split-Horizon
8.1. Ethernet Segments on AR-LEAF nodes
If VXLAN or NVGRE are used, and if the Split-horizon is based on the If VXLAN or NVGRE are used, and if the Split-horizon is based on the
tunnel IP SA and "Local-Bias" as described in [EVPN-OVERLAY], the tunnel IP SA and "Local-Bias" as described in [RFC8365], the Split-
Split-horizon check will not work if there is an Ethernet-Segment horizon check will not work if there is an Ethernet-Segment shared
shared between two AR-LEAF nodes, and the AR-REPLICATOR changes the between two AR-LEAF nodes, and the AR-REPLICATOR changes the tunnel
tunnel IP SA of the packets with its own AR-IP. IP SA of the packets with its own AR-IP.
In order to be compatible with the IP SA split-horizon check, the AR- In order to be compatible with the IP SA split-horizon check, the AR-
REPLICATOR MAY keep the original received tunnel IP SA when REPLICATOR MAY keep the original received tunnel IP SA when
replicating packets to a remote AR-LEAF or AR-REPLICATOR. This will replicating packets to a remote AR-LEAF or RNVE. This will allow DF
allow DF (Designated Forwarder) AR-LEAF nodes to apply Split-horizon (Designated Forwarder) AR-LEAF nodes to apply Split-horizon check
check procedures for BM packets, before sending them to the local procedures for BM packets, before sending them to the local Ethernet-
Ethernet-Segment. Segment. Even if the AR-LEAF's IP SA is preserved when replicating to
AR-LEAFs or RNVEs, the AR-REPLICATOR MUST always use its IR-IP as IP
SA when replicating to other AR-REPLICATORs.
When EVPN is used for MPLS over GRE (or UDP), the ESI-label based When EVPN is used for MPLS over GRE (or UDP), the ESI-label based
split-horizon procedure as in [RFC7432] will not work for multi-homed split-horizon procedure as in [RFC7432] will not work for multi-homed
Ethernet-Segments defined on AR-LEAF nodes. "Local-Bias" is Ethernet-Segments defined on AR-LEAF nodes. "Local-Bias" is
recommended in this case, as in the case of VXLAN or NVGRE explained recommended in this case, as in the case of VXLAN or NVGRE explained
above. The "Local-Bias" and tunnel IP SA preservation mechanisms above. The "Local-Bias" and tunnel IP SA preservation mechanisms
provide the required split-horizon behavior in non-selective or provide the required split-horizon behavior in non-selective or
selective AR. selective AR.
Note that if the AR-REPLICATOR implementation keeps the received Note that if the AR-REPLICATOR implementation keeps the received
tunnel IP SA, the use of uRPF in the IP fabric based on the tunnel IP tunnel IP SA, the use of uRPF (unicast Reverse Path Forwarding)
SA MUST be disabled. checks in the IP fabric based on the tunnel IP SA MUST be disabled.
9. Out-of-band distribution of Broadcast/Multicast traffic 8.2. Ethernet Segments on AR-REPLICATOR nodes
The use of out-of-band mechanisms to distribute BM traffic between Ethernet Segments associated to one or more AR-REPLICATOR nodes
AR-REPLICATORS MAY be used. SHOULD follow "Local-Bias" procedures for EVPN all-active multi-
homing, as follows:
10. Benefits of the optimized-IR solution o For BUM traffic received on a local AR-REPLICATOR's AC, "Local-
Bias" procedures as in [RFC8365] SHOULD be followed.
o For BUM traffic received on an AR-REPLICATOR overlay tunnel with
AR-IP as the IP DA, "Local-Bias" SHOULD also be followed. That is,
traffic received with AR-IP as IP DA will be treated as though it
had been received on a local AC that is part of the ES and will be
forwarded to all local ES, irrespective of their DF or NDF state.
o BUM traffic received on an AR-REPLICATOR overlay tunnel with IR-IP
as the IP DA, will follow regular [RFC8365] "Local-Bias" rules and
will not be forwarded to local ESes that are shared with the AR-LEF
or AR-REPLICATOR originating the traffic.
9. Benefits of the optimized-IR solution
A solution for the optimization of Ingress Replication in EVPN is A solution for the optimization of Ingress Replication in EVPN is
described in this document (optimized-IR). The solution brings the described in this document (optimized-IR). The solution brings the
following benefits: following benefits:
o Optimizes the multicast forwarding in low-performance NVEs, by o Optimizes the multicast forwarding in low-performance NVEs, by
relaying the replication to high-performance NVEs (AR-REPLICATORs) relaying the replication to high-performance NVEs (AR-REPLICATORs)
and while preserving the packet ordering for unicast applications. and while preserving the packet ordering for unicast applications.
o Reduces the flooded traffic in NVO networks where some NVEs do not o Reduces the flooded traffic in NVO networks where some NVEs do not
need broadcast/multicast and/or unknown unicast traffic. need broadcast/multicast and/or unknown unicast traffic.
o It is fully compatible with existing EVPN implementations and EVPN o It is fully compatible with existing EVPN implementations and EVPN
functions for NVO overlay tunnels. Optimized-IR NVEs and regular functions for NVO overlay tunnels. Optimized-IR NVEs and regular
NVEs can be even part of the same EVI. NVEs can be even part of the same EVI.
o It does not require any PIM-based tree in the NVO core of the o It does not require any PIM-based tree in the NVO core of the
network. network.
11. Conventions used in this document 10. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
12. Security Considerations 11. Security Considerations
This section will be added in future versions. This section will be added in future versions.
13. IANA Considerations 12. IANA Considerations
IANA has allocated the following Border Gateway Protocol (BGP) IANA has allocated the following Border Gateway Protocol (BGP)
Parameters: Parameters:
1) Allocation in the P-Multicast Service Interface Tunnel (PMSI 1) Allocation in the P-Multicast Service Interface Tunnel (PMSI
Tunnel) Tunnel Types registry: Tunnel) Tunnel Types registry:
Value Meaning Reference Value Meaning Reference
0x0A Assisted-Replication Tunnel [This document] 0x0A Assisted-Replication Tunnel [This document]
2) Allocations in the P-Multicast Service Interface (PMSI) Tunnel 2) Allocations in the P-Multicast Service Interface (PMSI) Tunnel
Attribute Flags registry: Attribute Flags registry:
Value Name Reference Value Name Reference
3-4 Assisted-Replication Type (T) [This document] 3-4 Assisted-Replication Type (T) [This document]
5 Broadcast and Multicast (BM) [This document] 5 Broadcast and Multicast (BM) [This document]
6 Unknown (U) [This document] 6 Unknown (U) [This document]
14. Terminology 13. Terminology
AC: Attachment Circuit
Regular-IR: Refers to Regular Ingress Replication, where the source Regular-IR: Refers to Regular Ingress Replication, where the source
NVE/PE sends a copy to each remote NVE/PE part of the EVI. NVE/PE sends a copy to each remote NVE/PE part of the EVI.
AR-IP: IP address owned by the AR-REPLICATOR and used to AR-IP: IP address owned by the AR-REPLICATOR and used to
differentiate the ingress traffic that must follow the AR differentiate the ingress traffic that must follow the AR
procedures. procedures.
IR-IP: IP address used for Ingress Replication as in [RFC7432]. IR-IP: IP address used for Ingress Replication as in [RFC7432].
skipping to change at page 23, line 4 skipping to change at page 23, line 19
was previously received from an overlay tunnel. was previously received from an overlay tunnel.
IR forwarding mode: it refers to the Ingress Replication behavior IR forwarding mode: it refers to the Ingress Replication behavior
explained in [RFC7432]. It means sending an AC BM packet copy explained in [RFC7432]. It means sending an AC BM packet copy
to each remote PE/NVE in the EVI and sending an overlay BM to each remote PE/NVE in the EVI and sending an overlay BM
packet only to the ACs and not other overlay tunnels. packet only to the ACs and not other overlay tunnels.
PTA: PMSI Tunnel Attribute PTA: PMSI Tunnel Attribute
RT-3: EVPN Route Type 3, Inclusive Multicast Ethernet Tag route RT-3: EVPN Route Type 3, Inclusive Multicast Ethernet Tag route
RT-11: EVPN Route Type 11, Leaf Auto-Discovery (AD) route RT-11: EVPN Route Type 11, Leaf Auto-Discovery (AD) route
15. References 14. References
15.1 Normative References 14.1 Normative References
[RFC6514]Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [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>.
[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>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Encodings and Procedures for Multicast in MPLS/BGP IP VPNs",
RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc- RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-
editor.org/info/rfc6514>. editor.org/info/rfc6514>.
[RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,
<https://www.rfc-editor.org/info/rfc7432>. <https://www.rfc-editor.org/info/rfc7432>.
[RFC7902]Rosen, E. and T. Morin, "Registry and Extensions for P- [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for P-
Multicast Service Interface Tunnel Attribute Flags", RFC 7902, DOI Multicast Service Interface Tunnel Attribute Flags", RFC 7902, DOI
10.17487/RFC7902, June 2016, <https://www.rfc- 10.17487/RFC7902, June 2016, <https://www.rfc-
editor.org/info/rfc7902>. editor.org/info/rfc7902>.
[RFC7902]Rosen, E. and Morin, T., "Registry and Extensions for P-
Multicast Service Interface Tunnel Attribute Flags", June 2016,
<http://www.rfc-editor.org/info/rfc7902>.
[EVPN-BUM] Zhang et al., "Updates on EVPN BUM Procedures", draft- [EVPN-BUM] Zhang et al., "Updates on EVPN BUM Procedures", draft-
ietf-bess-evpn-bum-procedure-updates-01.txt, work in progress, ietf-bess-evpn-bum-procedure-updates-04.txt, work in progress, June
December 2016. 2018.
15.2 Informative References 14.2 Informative References
[EVPN-OVERLAY] Sajassi-Drake et al., "A Network Virtualization [RFC8365] Sajassi et al., "A Network Virtualization Overlay Solution
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-07.txt, Using Ethernet VPN (EVPN)", RFC 8365, March, 2018.
work in progress, December 2016.
15.0 Contributors
In addition to the names in the front page, the following co-authors
also contributed to this document:
Wim Henderickx
Nokia
Kiran Nagaraj
Nokia
Ravi Shekhar
Juniper Networks
Nischal Sheth
Juniper Networks
Aldrin Isaac
Juniper
Mudassir Tufail
Citibank
16. Acknowledgments 16. Acknowledgments
The authors would like to thank Neil Hart, David Motz, Kiran Nagaraj, The authors would like to thank Neil Hart, David Motz, Dai Truong,
Dai Truong, Thomas Morin, Jeffrey Zhang and Shankar Murthy for their Thomas Morin, Jeffrey Zhang and Shankar Murthy for their valuable
valuable feedback and contributions. feedback and contributions.
17. Authors' Addresses 17. Authors' Addresses
Jorge Rabadan (Editor) Jorge Rabadan (Editor)
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
skipping to change at page 24, line 12 skipping to change at page 25, line 4
Jorge Rabadan (Editor) Jorge Rabadan (Editor)
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Nokia Nokia
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
Mukul Katiyar Mukul Katiyar
Versa Networks Versa Networks
Email: mukul@versa-networks.com Email: mukul@versa-networks.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Ravi Shekhar
Juniper Networks
Email: rshekhar@juniper.net
Nischal Sheth
Juniper Networks
Email: nsheth@juniper.net
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net Email: wlin@juniper.net
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Aldrin Isaac
Juniper
Email: aisaac@juniper.net
Mudassir Tufail
Citibank
mudassir.tufail@citi.com
 End of changes. 39 change blocks. 
87 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/