< draft-skr-bess-evpn-redundant-mcast-source-00.txt   draft-skr-bess-evpn-redundant-mcast-source-01.txt >
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet Draft J. Kotalwar Internet Draft J. Kotalwar
S. Sathappan S. Sathappan
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
E. Rosen
Z. Zhang Z. Zhang
W. Lin W. Lin
Juniper Juniper
Expires: April 25, 2019 October 22, 2018 E. Rosen
Individual
Expires: January 6, 2020 July 5, 2019
Multicast Source Redundancy in EVPN Networks Multicast Source Redundancy in EVPN Networks
draft-skr-bess-evpn-redundant-mcast-source-00 draft-skr-bess-evpn-redundant-mcast-source-01
Abstract Abstract
EVPN supports intra and inter-subnet IP multicast forwarding. EVPN supports intra and inter-subnet IP multicast forwarding.
However, EVPN (or conventional IP multicast techniques for that However, EVPN (or conventional IP multicast techniques for that
matter) do not have a solution for the case where a given multicast matter) do not have a solution for the case where: a) a given
group carries more than one flow (i.e., more than one source), but multicast group carries more than one flow (i.e., more than one
where it is desired that each receiver gets only one of the several source), and b) it is desired that each receiver gets only one of the
flows. Existing multicast techniques assume there are no redundant several flows. Existing multicast techniques assume there are no
sources sending the same flows to the same IP multicast group, and, redundant sources sending the same flow to the same IP multicast
in case there were redundant sources, the receiver's application group, and, in case there were redundant sources, the receiver's
would deal with the received duplicated packets. This document application would deal with the received duplicated packets. This
extends the existing EVPN specifications and assumes that IP document extends the existing EVPN specifications and assumes that IP
Multicast source redundancy may exist. It also assumes that, in case Multicast source redundancy may exist. It also assumes that, in case
two or more sources send the same IP Multicast flows into the tenant two or more sources send the same IP Multicast flows into the tenant
domain, the EVPN PEs need to avoid that the receivers get packet domain, the EVPN PEs need to avoid that the receivers get packet
duplication by following the described procedures. duplication by following the described procedures.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 16 skipping to change at page 2, line 19
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 April 25, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 45 skipping to change at page 2, line 48
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Background on IP Multicast Delivery in EVPN Networks . . . . 6 1.2 Background on IP Multicast Delivery in EVPN Networks . . . . 6
1.2.1 Intra-subnet IP Multicast Forwarding . . . . . . . . . . 6 1.2.1 Intra-subnet IP Multicast Forwarding . . . . . . . . . . 6
1.2.2 Inter-subnet IP Multicast Forwarding . . . . . . . . . . 7 1.2.2 Inter-subnet IP Multicast Forwarding . . . . . . . . . . 7
1.3 Multi-Homed IP Multicast Sources in EVPN . . . . . . . . . . 9 1.3 Multi-Homed IP Multicast Sources in EVPN . . . . . . . . . . 9
1.4 The Need for Redundant IP Multicast Sources in EVPN . . . . 11 1.4 The Need for Redundant IP Multicast Sources in EVPN . . . . 11
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 11 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 11
3. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . . 13 3. BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . . . 13
4. Warm Standby (WS) Solution for Redundant G-Sources . . . . . . 14 4. Warm Standby (WS) Solution for Redundant G-Sources . . . . . . 14
4.1 WS Example in an OISM Network . . . . . . . . . . . . . . . 15 4.1 WS Example in an OISM Network . . . . . . . . . . . . . . . 16
4.2 WS Example in a Single-BD Tenant Network . . . . . . . . . . 17 4.2 WS Example in a Single-BD Tenant Network . . . . . . . . . . 18
5. Hot Standby (HS) Solution for Redundant G-Sources . . . . . . . 18
5.1 Use of BFD in the HS Solution . . . . . . . . . . . . . . . 21
5.2 HS Example in an OISM Network . . . . . . . . . . . . . . . 21
5.3 HS Example in a Single-BD Tenant Network . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 26 5. Hot Standby (HS) Solution for Redundant G-Sources . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 5.1 Use of BFD in the HS Solution . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2 HS Example in an OISM Network . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 5.3 HS Example in a Single-BD Tenant Network . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Intra and Inter-subnet IP Multicast forwarding are supported in EVPN Intra and Inter-subnet IP Multicast forwarding are supported in EVPN
networks. [IGMP-PROXY] describes the procedures required to optimize networks. [IGMP-PROXY] describes the procedures required to optimize
the delivery of IP Multicast flows when Sources and Receivers are the delivery of IP Multicast flows when Sources and Receivers are
connected to the same EVPN BD (Broadcast Domain), whereas [OISM] connected to the same EVPN BD (Broadcast Domain), whereas [OISM]
specifies the procedures to support Inter-subnet IP Multicast in a specifies the procedures to support Inter-subnet IP Multicast in a
tenant network. Inter-subnet IP Multicast means that IP Multicast tenant network. Inter-subnet IP Multicast means that IP Multicast
Source and Receivers of the same multicast flow are connected to Source and Receivers of the same multicast flow are connected to
different BDs of the same tenant. different BDs of the same tenant.
[IGMP-PROXY], [OISM] or conventional IP multicast techniques do not [IGMP-PROXY], [OISM] or conventional IP multicast techniques do not
have a solution for the case where a given multicast group carries have a solution for the case where a given multicast group carries
more than one flow (i.e., more than one source), but where it is more than one flow (i.e., more than one source) and it is desired
desired that each receiver gets only one of the several flows. that each receiver gets only one of the several flows. Multicast
Multicast techniques assume there are no redundant sources sending techniques assume there are no redundant sources sending the same
the same flows to the same IP multicast group, and, in case there flows to the same IP multicast group, and, in case there were
were redundant sources, the receiver's application would deal with redundant sources, the receiver's application would deal with the
the received duplicated packets. received duplicated packets.
As a workaround in conventional IP multicast (PIM or MVPN networks), As a workaround in conventional IP multicast (PIM or MVPN networks),
if all the redundant sources are given the same IP address, each if all the redundant sources are given the same IP address, each
receiver will get only one flow. The reason is that, in conventional receiver will get only one flow. The reason is that, in conventional
IP multicast, (S,G) state is always created. It is always created by IP multicast, (S,G) state is always created by the RP, and sometimes
the RP, and sometimes by the Last Hop Router (LHR). The (S,G) state by the Last Hop Router (LHR). The (S,G) state always binds the (S,G)
always binds the (S,G) flow to a source-specific tree, rooted at the flow to a source-specific tree, rooted at the source IP address. If
source IP address. If multiple sources have the same IP address, one multiple sources have the same IP address, one may end up with
may end up with multiple (S,G) trees. However, the way the trees are multiple (S,G) trees. However, the way the trees are constructed
constructed ensures that any given LHR or RP is on at most one of ensures that any given LHR or RP is on at most one of them. The use
them. The use of an anycast address assigned to multiple sources may of an anycast address assigned to multiple sources may be useful for
be useful for warm standby redundancy solutions. However, on one warm standby redundancy solutions. However, on one hand, it's not
hand, it's not really helpful for hot standby redundancy solutions really helpful for hot standby redundancy solutions and on the other
and on the other hand, configuring the same IP address (in particular hand, configuring the same IP address (in particular IPv4 address) in
IPv4 address) in multiple sources may bring issues if the sources multiple sources may bring issues if the sources need to be reached
need to be reached by IP unicast traffic or if the sources are by IP unicast traffic or if the sources are attached to the same
attached to the same Broadcast Domain. Broadcast Domain.
In addition, in the scenario where several G-sources are attached via In addition, in the scenario where several G-sources are attached via
EVPN/OISM, there is not necessarily any (S,G) state created for the EVPN/OISM, there is not necessarily any (S,G) state created for the
redundant sources. In general, the LHRs have only (*,G) state, and redundant sources. The LHRs may have only (*,G) state, and there may
there may not be an RP (creating (S,G) state) either. Therefore, this not be an RP (creating (S,G) state) either. Therefore, this document
document extends the above two specifications and assumes that IP extends the above two specifications and assumes that IP Multicast
Multicast source redundancy may exist. It also assumes that, in case source redundancy may exist. It also assumes that, in case two or
two or more sources send the same IP Multicast flows into the tenant more sources send the same IP Multicast flows into the tenant domain,
domain, the EVPN PEs need to avoid that the receivers get packet the EVPN PEs need to avoid that the receivers get packet
duplication. duplication.
The solution provides support for Warm Standby (WS) and Hot Standby The solution provides support for Warm Standby (WS) and Hot Standby
(HS) redundancy. WS is defined as the redundancy scenario in which (HS) redundancy. WS is defined as the redundancy scenario in which
the upstream PEs attached to the redundant sources of the same the upstream PEs attached to the redundant sources of the same
tenant, make sure that only one source of the same flow can send tenant, make sure that only one source of the same flow can send
multicast to the interested downstream PEs at the same time. In HS multicast to the interested downstream PEs at the same time. In HS
the upstream PEs forward the redundant multicast flows to the the upstream PEs forward the redundant multicast flows to the
downstream PEs, and the downstream PEs make sure only one flow is downstream PEs, and the downstream PEs make sure only one flow is
forwarded to the interested attached receivers. forwarded to the interested attached receivers.
skipping to change at page 5, line 22 skipping to change at page 5, line 25
o G-source: any system sourcing traffic to G. o G-source: any system sourcing traffic to G.
o SFG: Single Flow Group, i.e., a multicast group address G which o SFG: Single Flow Group, i.e., a multicast group address G which
represents traffic that contains only a single flow. However, represents traffic that contains only a single flow. However,
multiple sources - with the same or different IP - may be multiple sources - with the same or different IP - may be
transmitting an SFG. transmitting an SFG.
o Redundant G-source: a host or router that transmits an SFG in a o Redundant G-source: a host or router that transmits an SFG in a
tenant network where there are more hosts or routers transmitting tenant network where there are more hosts or routers transmitting
the same SFG. Redundant G-sources for the same SFG SHOULD have the same SFG. Redundant G-sources for the same SFG SHOULD have
different IP addresses when in the same BD, and MAY have the same different IP addresses, although they MAY have the same IP address
IP address when in different BDs of the same tenant network. when in different BDs of the same tenant network. Redundant G-
Redundant G-sources are assumed NOT to be "bursty" in this document sources are assumed NOT to be "bursty" in this document (typical
(typical example are Broadcast TV G-sources or similar). example are Broadcast TV G-sources or similar).
o P-tunnel: Provider tunnel refers to the type of tree a given o P-tunnel: Provider tunnel refers to the type of tree a given
upstream EVPN PE uses to forward multicast traffic to downstream upstream EVPN PE uses to forward multicast traffic to downstream
PEs. Examples of P-tunnels supported in this document are Ingress PEs. Examples of P-tunnels supported in this document are Ingress
Replication (IR), Assisted Replication (AR), BIER, mLDP or P2MP Replication (IR), Assisted Replication (AR), BIER, mLDP or P2MP
RSVP-TE. RSVP-TE.
o Inclusive Multicast Tree or Inclusive Provider Multicast Service o Inclusive Multicast Tree or Inclusive Provider Multicast Service
Interface (I-PMSI): defined in [RFC6513], in this document it is Interface (I-PMSI): defined in [RFC6513], in this document it is
applicable only to EVPN and refers to the default multicast tree applicable only to EVPN and refers to the default multicast tree
skipping to change at page 11, line 8 skipping to change at page 11, line 8
receiving PE on BD1, the IP Multicast flow will be forwarded as soon receiving PE on BD1, the IP Multicast flow will be forwarded as soon
as BD1 creates multicast state for (S1,G1) or (*,G1). In the example as BD1 creates multicast state for (S1,G1) or (*,G1). In the example
of Figure 3, receivers R1, R2 and R3 are interested in the multicast of Figure 3, receivers R1, R2 and R3 are interested in the multicast
flow to G1. R1 will receive (S1,G1) directly via the IRB interface as flow to G1. R1 will receive (S1,G1) directly via the IRB interface as
per [OISM]. Upon receiving IGMP reports from R2 and R3, PE3 will per [OISM]. Upon receiving IGMP reports from R2 and R3, PE3 will
issue an SMET (*,G1) route that will create state in PE1's BD1. PE1 issue an SMET (*,G1) route that will create state in PE1's BD1. PE1
will therefore forward the IP Multicast flow to PE3's SBD and PE3 will therefore forward the IP Multicast flow to PE3's SBD and PE3
will forward to R2 and R3, as per [OISM] procedures. will forward to R2 and R3, as per [OISM] procedures.
When IP Multicast source multi-homing is required, EVPN multi-homed When IP Multicast source multi-homing is required, EVPN multi-homed
Ethernet Segments SHOULD be used. EVPN multi-homing guarantees that Ethernet Segments MUST be used. EVPN multi-homing guarantees that
only one Upstream PE will forward a given multicast flow at the time, only one Upstream PE will forward a given multicast flow at the time,
avoiding packet duplication at the Downstream PEs. In addition, the avoiding packet duplication at the Downstream PEs. In addition, the
SMET route for a given flow creates state in all the multi-homing SMET route for a given flow creates state in all the multi-homing
Upstream PEs. Therefore, in case of failure on the Upstream PE Upstream PEs. Therefore, in case of failure on the Upstream PE
forwarding the flow, the backup Upstream PE can forward the flow forwarding the flow, the backup Upstream PE can forward the flow
immediately. immediately.
This document assumes that multi-homing PEs attached to the same This document assumes that multi-homing PEs attached to the same
source always use multi-homed Ethernet Segments. source always use multi-homed Ethernet Segments.
skipping to change at page 11, line 43 skipping to change at page 11, line 43
location of the receiver systems either. location of the receiver systems either.
c) The redundant G-sources can be single-homed to only one EVPN PE or c) The redundant G-sources can be single-homed to only one EVPN PE or
multi-homed to multiple EVPN PEs. multi-homed to multiple EVPN PEs.
d) The EVPN PEs must avoid duplication of the same SFG on the d) The EVPN PEs must avoid duplication of the same SFG on the
receiver systems. receiver systems.
2. Solution Overview 2. Solution Overview
An SFG is represented as (*,G) if any source that issues multicast
traffic to G is a redundant G-source. Alternatively, this document
allows an SFG to be represented as (S,G), where S is a prefix of any
length. In this case, a source is considered a redundant G-source for
the SFG if it is contained in the prefix. This document allows
variable length prefixes in the Sources advertised in S-PMSI A-D
routes only for the particular application of redundant G-sources.
There are two redundant G-source solutions described in this There are two redundant G-source solutions described in this
document: document:
o Warm Standby (WS) Solution o Warm Standby (WS) Solution
o Hot Standby (HS) Solution o Hot Standby (HS) Solution
The WS solution is an upstream PE based solution (downstream PEs do The WS solution is an upstream PE based solution (downstream PEs do
not participate in the procedures), in which all the upstream PEs not participate in the procedures), in which all the upstream PEs
attached to redundant G-sources for an SFG will elect a "Single attached to redundant G-sources for an SFG represented by (*,G) or
Forwarder" (SF) among themselves. Once a SF is elected, the upstream (S,G) will elect a "Single Forwarder" (SF) among themselves. Once a
PEs add an RPF check to the (*,G) state for the SFG: SF is elected, the upstream PEs add an RPF check to the (*,G) or
(S,G) state for the SFG:
- A non-SF upstream PE discards any (*,G) packets received over a - A non-SF upstream PE discards any (*,G)/(S,G) packets received over
local AC. a local AC.
- The SF accepts and forwards any (*,G) packets it receives over a - The SF accepts and forwards any (*,G)/(S,G) packets it receives
single local AC. In case (*,G) packets are received over multiple over a single local AC (for the SFG). In case (*,G)/(S,G) packets
local ACs, they will be discarded in all the local ACs but one. The for the SFG are received over multiple local ACs, they will be
procedure to choose the local AC that accepts packets is a local discarded in all the local ACs but one. The procedure to choose the
implementation matter. local AC that accepts packets is a local implementation matter.
A failure on the SF will result in the election of a new SF. The A failure on the SF will result in the election of a new SF. The
Election requires BGP extensions on the existing EVPN routes. These Election requires BGP extensions on the existing EVPN routes. These
extensions and associated procedures are described in Sections 3 and extensions and associated procedures are described in Sections 3 and
4 respectively. 4 respectively.
In the HS solution the downstream PEs are the ones avoiding the SFG In the HS solution the downstream PEs are the ones avoiding the SFG
duplication. The upstream PEs are aware of the locally attached G- duplication. The upstream PEs are aware of the locally attached G-
sources and add a unique ESI-label per SFG to the SFG packets sources and add a unique ESI-label per SFG to the SFG packets
forwarded to downstream PEs. The downstream PEs pull the SFG from all forwarded to downstream PEs. The downstream PEs pull the SFG from all
skipping to change at page 12, line 39 skipping to change at page 12, line 48
duplication on the receiver systems by adding an RPF check to the duplication on the receiver systems by adding an RPF check to the
(*,G) state for the SFG: (*,G) state for the SFG:
- A downstream PE discards any (*,G) packets it receives from the - A downstream PE discards any (*,G) packets it receives from the
"wrong G-source". "wrong G-source".
- The wrong G-source is identified in the data path by an ESI-label - The wrong G-source is identified in the data path by an ESI-label
that is different than the ESI-label used for the selected G- that is different than the ESI-label used for the selected G-
source. source.
- Note that the ESI-label is used here for "ingress filtering" as - Note that the ESI-label is used here for "ingress filtering" (at
opposed to the [RFC7432] "egress filtering" used in the split- the egress/downstream PE) as opposed to the [RFC7432] "egress
horizon procedures. In [RFC7432] the ESI-label indicates what filtering" (at the egress/downstream PE) used in the split-horizon
egress ACs must be skipped when forwarding BUM traffic to the procedures. In [RFC7432] the ESI-label indicates what egress ACs
egress. In this document, the ESI-label indicates what ingress must be skipped when forwarding BUM traffic to the egress. In this
traffic must be discarded. document, the ESI-label indicates what ingress traffic must be
discarded at the downstream PE.
The use of ESI-labels for SFGs forwarded by upstream PEs require some The use of ESI-labels for SFGs forwarded by upstream PEs require some
control plane and data plane extensions in the procedures used by control plane and data plane extensions in the procedures used by
[RFC7432] for multi-homing. Upon failure of the selected G-source, [RFC7432] for multi-homing. Upon failure of the selected G-source,
the downstream PE will switch over to a different selected G-source, the downstream PE will switch over to a different selected G-source,
and will therefore change the RPF check for the (*,G) state. The and will therefore change the RPF check for the (*,G) state. The
extensions and associated procedures are described in Sections 3 and extensions and associated procedures are described in Sections 3 and
5 respectively. 5 respectively.
An operator should use the HS solution if they require a fast fail- An operator should use the HS solution if they require a fast fail-
over time and the additional bandwidth consumption is acceptable (SFG over time and the additional bandwidth consumption is acceptable (SFG
packets are received multiple times on the downstream PEs). Otherwise packets are received multiple times on the downstream PEs). Otherwise
the operator should use the WS solution, at the expense of a slower the operator should use the WS solution, at the expense of a slower
fail-over time in case of a G-source or upstream PE failure. Besides fail-over time in case of a G-source or upstream PE failure. Besides
bandwidth efficiency, another advantage of the WS solution is that bandwidth efficiency, another advantage of the WS solution is that
only the upstream PEs attached to the redundant G-sources for the only the upstream PEs attached to the redundant G-sources for the
same SFG need to be upgraded to support the new procedures. same SFG need to be upgraded to support the new procedures.
The support of either solution is OPTIONAL. This document does not impose the support of both solutions on a
system. If one solution is supported, the support of the other
solution is OPTIONAL.
3. BGP EVPN Extensions 3. BGP EVPN Extensions
This document makes use of the following BGP EVPN extensions: This document makes use of the following BGP EVPN extensions:
1. SFG flag in the Multicast Flags Extended Community 1. SFG flag in the Multicast Flags Extended Community
The Single Flow Group (SFG) flag is a new bit requested to IANA The Single Flow Group (SFG) flag is a new bit requested to IANA
out of the registry Multicast Flags Extended Community Flag out of the registry Multicast Flags Extended Community Flag
Values. This new flag is set for S-PMSI routes that carry an SFG Values. This new flag is set for S-PMSI A-D routes that carry a
(*,G) in the NLRI. (*,G)/(S,G) SFG in the NLRI.
2. ESI attribute
The HS solution requires the advertisement of one or more
attributes that encode the Ethernet Segment Identifier(s)
associated to an S-PMSI (*,G) route that advertises the presence
of an SFG. The format of this attribute will be described in
future revisions of this document. The following options are being
considered for the "ESI attribute":
- Use a BGP Large Community (LC) Attribute:
If an Ethernet Segment Type 5 [RFC7432] is used for ESes
attached to redundant G-sources, a LC attribute can be used
where each value encodes the corresponding ESI in the following
format: ASN(4-bytes):Local-Discriminator(4-bytes):0x0(4-bytes);
ASN and Local-Discriminator are the same values that are used at
the upstream PE to construct the type-5 ESI. A PE receiving an
S-PMSI (*,G) route with an SFG indication should interpret the
LC Attribute as a list of ESIs associated with the redundant G-
sources.
- Use a new BGP attribute
Another option is to define a new attribute that can encode one
or more ESI values.
- Use an IPv6 Address Specific BGP Extended Community Attribute
Another Option is to make use of the [RFC5701] IPv6 Address EC 2. ESI Label Extended Community is used in S-PMSI A-D routes
attribute.
This section will be modified in future versions of the document. The HS solution requires the advertisement of one or more ESI
Label Extended Communities [RFC7432] that encode the Ethernet
Segment Identifier(s) associated to an S-PMSI A-D (*,G)/(S,G)
route that advertises the presence of an SFG. Only the ESI Label
value in the extended community is relevant to the procedures in
this document. The Flags field in the extended community will be
advertised as 0x00 and ignored on reception. [RFC7432] specifies
that the ESI Label Extended Community is advertised along with the
A-D per ES route. This documents extends the use of this extended
community so that it can be advertised multiple times (with
different ESI values) along with the S-PMSI A-D route.
4. Warm Standby (WS) Solution for Redundant G-Sources 4. Warm Standby (WS) Solution for Redundant G-Sources
The general procedure is described as follows: The general procedure is described as follows:
1. Configuration of the upstream PEs 1. Configuration of the upstream PEs
Upstream PEs where redundant G-sources may exist need to be Upstream PEs (possibly attached to redundant G-sources) need to be
configured to know which groups are carrying only flows from configured to know which groups are carrying only flows from
redundant G-sources, that is, the SFGs in the tenant domain. They redundant G-sources, that is, the SFGs in the tenant domain. They
will also be configured to know which local BDs may be attached to will also be configured to know which local BDs may be attached to a
a redundant G-source. As an example, PE1 is configured to know redundant G-source. The SFGs can be configured for any source, E.g.,
that G1 is an SFG and redundant G-sources for G1 may be attached SFG for "*", or for a prefix that contains multiple sources that will
to BD1 or BD2. issue the same SFG, i.e., "10.0.0.0/30". In the latter case sources
10.0.0.1 and 10.0.0.2 are considered as Redundant G-sources, whereas
10.0.0.10 is not considered a redundant G-source for the same SFG.
As an example:
- PE1 is configured to know that G1 is an SFG for any source and
redundant G-sources for G1 may be attached to BD1 or BD2.
- Or PE1 can also be configured to know that G1 is an SFG for the
sources contained in 10.0.0.0/30, and those redundant G-sources
may be attached to BD1 or BD2.
2. Signaling the location of a G-source for a given SFG 2. Signaling the location of a G-source for a given SFG
Upon receiving G-traffic for an SFG on a BD, an upstream PE Upon receiving G-traffic for a configured SFG on a BD, an
configured to follow this procedure, e.g., PE1: upstream PE configured to follow this procedure, e.g., PE1:
a. Originates an S-PMSI (*,G) route for the SFG that is imported a. Originates an S-PMSI A-D (*,G)/(S,G) route for the SFG. An
by all the PEs attached to the tenant domain. In order to do (*,G) route is advertised if the SFG is configured for any
that, the route will use the SBD-RT (Supplementary Broadcast source, and an (S,G) route is advertised (where the Source can
Domain Route-Target) in addition to the BD-RT of the BD over have any length) if the SFG is configured for a prefix.
which the G-traffic is received. The route SHOULD also carry a
DF Election Extended Community (EC) and a flag indicating that
it conveys an SFG. The DF Election EC and its use is specified
in [DF].
b. The above S-PMSI route MAY be advertised with or without PMSI b. The S-PMSI A-D route is imported by all the PEs attached to the
Tunnel Attribute (PTA): tenant domain. In order to do that, the route will use the SBD-
RT (Supplementary Broadcast Domain Route-Target) in addition to
the BD-RT of the BD over which the G-traffic is received. The
route SHOULD also carry a DF Election Extended Community (EC)
and a flag indicating that it conveys an SFG. The DF Election
EC and its use is specified in [RFC8584].
- With no PTA if an I-PMSI or S-PMSI with IR/AR/BIER are to be c. The above S-PMSI A-D route MAY be advertised with or without
used. PMSI Tunnel Attribute (PTA):
- With no PTA if an I-PMSI or S-PMSI A-D with IR/AR/BIER are to
be used.
- With PTA in any other case. - With PTA in any other case.
c. The S-PMSI (*,G) route is triggered by the first packet of the d. The S-PMSI A-D route is triggered by the first packet of the
SFG and withdrawn when the flow is not received anymore. SFG and withdrawn when the flow is not received anymore.
Detecting when the G-source is no longer active is a local Detecting when the G-source is no longer active is a local
implementation matter. The use of a timer is RECOMMENDED. The implementation matter. The use of a timer is RECOMMENDED. The
timer is started when the traffic to G1 is not received. Upon timer is started when the traffic to G1 is not received. Upon
expiration of the timer, the PE will withdraw the route. expiration of the timer, the PE will withdraw the route.
3. Single Forwarder (SF) Election 3. Single Forwarder (SF) Election
If the PE with a local G-source receives an S-PMSI route for the If the PE with a local G-source receives one or more S-PMSI A-D
same SFG from a remote PE, it will run a Single Forwarder (SF) routes for the same SFG from a remote PE, it will run a Single
Election based on the information encoded in the DF Election EC. Forwarder (SF) Election based on the information encoded in the DF
Election EC. Two S-PMSI A-D routes are considered for the same SFG
if they are advertised for the same tenant, and their Multicast
Source Length, Multicast Source, Multicast Group Length and
Multicast Group fields match.
a. A given DF Alg can only be used if all the PEs running the DF
Alg have consistent input. For example, in an OISM network, if
the redundant G-sources for an SFG are attached to BDs with
different Ethernet Tags, the Default DF Election Alg MUST NOT
be used.
b. In case the there is a mismatch in the DF Election Alg or
capabilities advertised by two PEs competing for the SF, the
lowest PE IP address (given by the Originator Address in the S-
PMSI A-D route) will be used as a tie-breaker.
4. RPF check on the PEs attached to a redundant G-source 4. RPF check on the PEs attached to a redundant G-source
All the PEs with a local G-source for the SFG will add an RPF All the PEs with a local G-source for the SFG will add an RPF
check to the (*,G) state for the SFG. That RPF check depends on check to the (*,G)/(S,G) state for the SFG. That RPF check depends
the SF Election result: on the SF Election result:
a. The non-SF PEs discard any (*,G) packets received over a local a. The non-SF PEs discard any (*,G)/(S,G) packets for the SFG
AC. received over a local AC.
b. The SF accepts any (*,G) packets it receives over one (and only b. The SF accepts any (*,G)/(S,G) packets for the SFG it receives
one) local AC. over one (and only one) local AC.
The solution above provides redundancy for SFGs and it does not The solution above provides redundancy for SFGs and it does not
require an upgrade of the downstream PEs (PEs where there is require an upgrade of the downstream PEs (PEs where there is
certainty that no redundant G-sources are connected). Other G-sources certainty that no redundant G-sources are connected). Other G-sources
for non-SFGs may exist in the same tenant domain. This document does for non-SFGs may exist in the same tenant domain. This document does
not change the existing procedures for non-SFG G-sources. not change the existing procedures for non-SFG G-sources.
The redundant G-sources can be single-homed or multi-homed to a BD in The redundant G-sources can be single-homed or multi-homed to a BD in
the tenant domain. Multi-homing does not change the above procedures. the tenant domain. Multi-homing does not change the above procedures.
skipping to change at page 16, line 44 skipping to change at page 17, line 44
| ^ | ^ | ^ | ^
| | IGMP | | IGMP | | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
Figure 4 - WS Solution for Redundant G-Sources Figure 4 - WS Solution for Redundant G-Sources
The WS solution works as follows: The WS solution works as follows:
1. Configuration of the upstream PEs, PE1 and PE2 1. Configuration of the upstream PEs, PE1 and PE2
PE1 and PE2 are configured to know that G1 is an SFG and redundant PE1 and PE2 are configured to know that G1 is an SFG for any
G-sources for G1 may be attached to BD1 or BD2, respectively. source and redundant G-sources for G1 may be attached to BD1 or
BD2, respectively.
2. Signaling the location of S1 and S2 for (*,G1) 2. Signaling the location of S1 and S2 for (*,G1)
Upon receiving (S1,G1) traffic on a local AC, PE1 and PE2 Upon receiving (S1,G1) traffic on a local AC, PE1 and PE2
originate S-PMSI (*,G1) routes with the SBD-RT, DF Election originate S-PMSI A-D (*,G1) routes with the SBD-RT, DF Election
Extended Community (EC) and a flag indicating that it conveys an Extended Community (EC) and a flag indicating that it conveys an
SFG. SFG.
3. Single Forwarder (SF) Election 3. Single Forwarder (SF) Election
Based on the DF Election EC content, PE1 and PE2 elect an SF for Based on the DF Election EC content, PE1 and PE2 elect an SF for
(*,G1). Assuming both PEs agree on e.g., Preference based Election (*,G1). Assuming both PEs agree on e.g., Preference based Election
as the algorithm to use [DF-PREF], and PE1 has a higher as the algorithm to use [DF-PREF], and PE1 has a higher
preference, PE1 becomes the SF for (*,G1). preference, PE1 becomes the SF for (*,G1).
skipping to change at page 17, line 24 skipping to change at page 18, line 25
a. The non-SF, PE2, discards any (*,G1) packets received over a a. The non-SF, PE2, discards any (*,G1) packets received over a
local AC. local AC.
b. The SF, PE1 accepts (*,G1) packets it receives over a one (and b. The SF, PE1 accepts (*,G1) packets it receives over a one (and
only one) local AC. only one) local AC.
The end result is that, upon receiving reports for (*,G1) or (S,G1), The end result is that, upon receiving reports for (*,G1) or (S,G1),
the downstream PEs (PE3 and PE5) will issue SMET routes and will pull the downstream PEs (PE3 and PE5) will issue SMET routes and will pull
the multicast SFG from PE1, and PE1 only. A failure on S1, the AC the multicast SFG from PE1, and PE1 only. A failure on S1, the AC
connected to S1 or PE1 itself will trigger the S-PMSI (*,G1) connected to S1 or PE1 itself will trigger the S-PMSI A-D (*,G1)
withdrawal from PE1 and PE2 will be promoted to SF. withdrawal from PE1 and PE2 will be promoted to SF.
4.2 WS Example in a Single-BD Tenant Network 4.2 WS Example in a Single-BD Tenant Network
Figure 5 illustrates an example in which S1 and S2 are redundant G- Figure 5 illustrates an example in which S1 and S2 are redundant G-
sources for the SFG (*,G1), however, now all the G-sources and sources for the SFG (*,G1), however, now all the G-sources and
receivers are connected to the same BD1 and there is no SBD. receivers are connected to the same BD1 and there is no SBD.
S1 (Single S2 S1 (Single S2
| Forwarder) | | Forwarder) |
skipping to change at page 18, line 42 skipping to change at page 19, line 42
| | | | | | | | | | | |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| ^ | ^ | ^ | ^
| | IGMP | | IGMP | | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
Figure 5 - WS Solution for Redundant G-Sources in the same BD Figure 5 - WS Solution for Redundant G-Sources in the same BD
The same procedure as in Section 4.1 is valid here, being this a sub- The same procedure as in Section 4.1 is valid here, being this a sub-
case of the one in Section 4.1. Upon receiving traffic for the SFG case of the one in Section 4.1. Upon receiving traffic for the SFG
G1, PE1 and PE2 advertise the S-PMSI routes with BD1-RT only, since G1, PE1 and PE2 advertise the S-PMSI A-D routes with BD1-RT only,
there is no SBD. since there is no SBD.
5. Hot Standby (HS) Solution for Redundant G-Sources 5. Hot Standby (HS) Solution for Redundant G-Sources
If fast-failover time is desired upon the failure of a G-source or PE If fast-failover time is desired upon the failure of a G-source or PE
attached to the G-source, and in spite of the extra bandwidth attached to the G-source, and in spite of the extra bandwidth
consumption in the tenant network, the HS solution should be used. consumption in the tenant network, the HS solution should be used.
The procedure is as follows: The procedure is as follows:
1. Configuration of the PEs 1. Configuration of the PEs
As in the WS case, the upstream PEs where redundant G-sources may As in the WS case, the upstream PEs where redundant G-sources may
exist need to be configured to know which groups are carrying only exist need to be configured to know which groups (for any source
or a prefix containing the intended sources) are carrying only
flows from redundant G-sources, that is, the SFGs in the tenant flows from redundant G-sources, that is, the SFGs in the tenant
domain. In addition (and this is not done in WS) the individual domain.
redundant G-sources for an SFG need to be associated with an
Ethernet Segment (ES) on the upstream PEs:
- This is irrespective of the redundant G-source being multi-homed
or single-homed. Even for single-homed redundant G-sources the
HS procedure relies on the ESI labels for the RPF check on
downstream PEs. The term "S-ESI" is used in this document to
refer to an ESI associated to a redundant G-source.
- The S-ESI SHOULD be a Type 5 ESI [RFC7432] so that it can be In addition (and this is not done in WS mode), the individual
mapped to a value in a BGP LC attribute, as described in Section redundant G-sources for an SFG need to be associated with an
3. The S-ESI MAY also be configured. Ethernet Segment (ES) on the upstream PEs. This is irrespective of
the redundant G-source being multi-homed or single-homed. Even for
single-homed redundant G-sources the HS procedure relies on the
ESI labels for the RPF check on downstream PEs. The term "S-ESI"
is used in this document to refer to an ESI associated to a
redundant G-source.
Contrary to the WS method (that is transparent to the downstream Contrary to the WS method (that is transparent to the downstream
PEs), the support for the HS procedure in all downstream PEs PEs), the support for the HS procedure in all downstream PEs
connected to the receivers in the tenant network is REQUIRED. The connected to the receivers in the tenant network is REQUIRED. The
downstream PEs do not need to be configured to know the connected downstream PEs do not need to be configured to know the connected
SFGs or their ESIs, since they get that information from the SFGs or their ESIs, since they get that information from the
upstream PEs. The downstream PEs will locally select an ESI for a upstream PEs. The downstream PEs will locally select an ESI for a
given SFG, and will program an RPF check to the (*,G) state for given SFG, and will program an RPF check to the (*,G)/(S,G) state
the SFG that will discard (*,G) packets from the rest of the ESIs. for the SFG that will discard (*,G)/(S,G) packets from the rest of
The selection of the ESI for the SFG is based on local policy. the ESIs. The selection of the ESI for the SFG is based on local
policy.
2. Signaling the location of a G-source for a given SFG and its 2. Signaling the location of a G-source for a given SFG and its
association to the local ESIs association to the local ESIs
Based on the configuration in step 1, an upstream PE configured to Based on the configuration in step 1, an upstream PE configured to
follow the HS procedures: follow the HS procedures:
a. Advertises an S-PMSI (*,G) route per each configured SFG. These a. Advertises an S-PMSI A-D (*,G)/(S,G) route per each configured
routes need to be imported by all the PEs of the tenant domain, SFG. These routes need to be imported by all the PEs of the
therefore they will carry the BD-RT and SBD-RT (if the SBD tenant domain, therefore they will carry the BD-RT and SBD-RT
exists). The route also carries the ESI attribute that conveys (if the SBD exists). The route also carries the ESI Label
all the S-ESIs associated to the SFG in the PE. Extended Communities needed to convey all the S-ESIs associated
to the SFG in the PE.
b. The S-PMSI route will convey a PTA if the same cases as in the b. The S-PMSI A-D route will convey a PTA in the same cases as in
WS procedure. the WS procedure.
c. The S-PMSI (*,G) route is triggered by the configuration of the c. The S-PMSI A-D (*,G)/(S,G) route is triggered by the
SFG and not by the reception of G-traffic. configuration of the SFG and not by the reception of G-traffic.
3. Distribution of DCB (Domain-wide Common Block) ESI-labels and G- 3. Distribution of DCB (Domain-wide Common Block) ESI-labels and G-
source ES routes source ES routes
An upstream PE advertises the corresponding ES, A-D per-EVI and A- An upstream PE advertises the corresponding ES, A-D per EVI and A-
D per-ES routes for the local S-ESIs. D per ES routes for the local S-ESIs.
a. ES routes are used for regular DF Election for the S-ES. This a. ES routes are used for regular DF Election for the S-ES. This
document does not introduce any change in the procedures document does not introduce any change in the procedures
related to the ES routes. related to the ES routes.
b. The A-D per-EVI and A-D per-ES routes MUST include the SBD-RT b. The A-D per EVI and A-D per ES routes MUST include the SBD-RT
since they have to be imported by all the PEs in the tenant since they have to be imported by all the PEs in the tenant
domain. domain.
c. The A-D per-ES routes convey the S-ESI labels that the c. The A-D per ES routes convey the S-ESI labels that the
downstream PEs use to add the RPF check for the (*,G) downstream PEs use to add the RPF check for the (*,G)/(S,G)
associated to the SFGs. This RPF check requires that all the associated to the SFGs. This RPF check requires that all the
packets for a given G-source are received with the same S-ESI packets for a given G-source are received with the same S-ESI
label value on the downstream PEs. For example, if two label value on the downstream PEs. For example, if two
redundant G-sources are multi-homed to PE1 and PE2 via S-ES-1 redundant G-sources are multi-homed to PE1 and PE2 via S-ES-1
and S-ES-2, PE1 and PE2 MUST allocate the same ESI label "Lx" and S-ES-2, PE1 and PE2 MUST allocate the same ESI label "Lx"
for S-ES-1 and they MUST allocate the same ESI label "Ly" for for S-ES-1 and they MUST allocate the same ESI label "Ly" for
S-ES-2. In addition, Lx and Ly MUST be different. These ESI S-ES-2. In addition, Lx and Ly MUST be different. These ESI
labels are Domain-wide Common Block (DCB) labels and follow the labels are Domain-wide Common Block (DCB) labels and follow the
procedures in [DCB]. allocation procedures in [DCB].
4. Processing of A-D routes and RPF check on the downstream PEs 4. Processing of A-D per ES/EVI routes and RPF check on the
downstream PEs
Unless described otherwise, "A-D routes" in this section refers to The A-D per ES/EVI routes are received and imported in all the PEs
both types, A-D per-ES and A-D per-EVI routes. The A-D routes are in the tenant domain. The processing of the A-D per ES/EVI routes
received and imported in all the PEs in the tenant domain. The on a given PE depends on its configuration:
processing of the A-D routes on a given PE depends on its
configuration:
a. The PEs attached to the same BD of the BD-RT that is included a. The PEs attached to the same BD of the BD-RT that is included
in the A-D routes will process the routes as in [RFC7432] and in the A-D per ES/EVI routes will process the routes as in
[DF]. If the receiving PE is attached to the same ES as [RFC7432] and [RFC8584]. If the receiving PE is attached to the
indicated in the route, [RFC7432] split-horizon procedures will same ES as indicated in the route, [RFC7432] split-horizon
be followed and the DF Election candidate list may be modified procedures will be followed and the DF Election candidate list
as in [DF] if the ES supports the AC-DF capability. may be modified as in [RFC8584] if the ES supports the AC-DF
capability.
b. The PEs that are not attached to the BD-RT but are attached to b. The PEs that are not attached to the BD-RT but are attached to
the SBD of the received SBD-RT, will import the A-D routes and the SBD of the received SBD-RT, will import the A-D per ES/EVI
use them for redundant G-source mass withdrawal, as explained routes and use them for redundant G-source mass withdrawal, as
later. explained later.
c. Upon importing A-D per-ES routes corresponding to different S- c. Upon importing A-D per ES routes corresponding to different S-
ESes, a PE MUST select a primary S-ES and add an RPF check to ESes, a PE MUST select a primary S-ES and add an RPF check to
the (*,G) state in the BD or SBD. This RPF check will discard the (*,G)/(S,G) state in the BD or SBD. This RPF check will
all ingress packets to (*,G) that are not received with the discard all ingress packets to (*,G)/(S,G) that are not
ESI-label of the primary S-ES. The selection of the primary S- received with the ESI-label of the primary S-ES. The selection
ES is a matter of local policy. of the primary S-ES is a matter of local policy.
5. G-traffic forwarding for redundant G-sources and fault detection 5. G-traffic forwarding for redundant G-sources and fault detection
Assuming there is (*,G) or (S,G) state for the SFG with OIF list Assuming there is (*,G) or (S,G) state for the SFG with OIF list
entries associated to remote EVPN PEs, upon receiving G-traffic on entries associated to remote EVPN PEs, upon receiving G-traffic on
a S-ES, the upstream PE will add a S-ESI label at the bottom of a S-ES, the upstream PE will add a S-ESI label at the bottom of
the stack before forwarding the traffic to the remote EVPN PEs. the stack before forwarding the traffic to the remote EVPN PEs.
This label is allocated from a DCB as described in step 3. If P2MP This label is allocated from a DCB as described in step 3. If P2MP
or BIER PMSIs are used, this is not adding any new data path or BIER PMSIs are used, this is not adding any new data path
procedures on the upstream PEs (except that the ESI-label is procedures on the upstream PEs (except that the ESI-label is
allocated from a DCB). However, if IR/AR are used, this document allocated from a DCB). However, if IR/AR are used, this document
extends the [RFC7432] procedures by pushing the S-ESI labels not extends the [RFC7432] procedures by pushing the S-ESI labels not
only on packets sent to the PEs that shared the ES but also to the only on packets sent to the PEs that shared the ES but also to the
rest of the PEs in the tenant domain. This allows the downstream rest of the PEs in the tenant domain. This allows the downstream
PEs to receive all the multicast packets from the redundant G- PEs to receive all the multicast packets from the redundant G-
sources with a S-ESI label (irrespective of the PMSI type and the sources with a S-ESI label (irrespective of the PMSI type and the
local ESes), and discard any packet that conveys a S-ESI label local ESes), and discard any packet that conveys a S-ESI label
different from the primary S-ESI label (that is, the label different from the primary S-ESI label (that is, the label
associated to the selected primary S-ES), as discussed in step 4. associated to the selected primary S-ES), as discussed in step 4.
If the last A-D per-EVI or the last A-D per-ES route for the If the last A-D per EVI or the last A-D per ES route for the
primary S-ES is withdrawn, the downstream PE will immediately primary S-ES is withdrawn, the downstream PE will immediately
select a new primary S-ES and will change the RPF check. Note that select a new primary S-ES and will change the RPF check. Note that
if the S-ES is re-used for multiple tenant domains by the upstream if the S-ES is re-used for multiple tenant domains by the upstream
PEs, the withdrawal of all the A-D per-ES routes for a S-ES PEs, the withdrawal of all the A-D per-ES routes for a S-ES
provides a mass withdrawal capability that makes a downstream PE provides a mass withdrawal capability that makes a downstream PE
to change the RPF check in all the tenant domains using the same to change the RPF check in all the tenant domains using the same
S-ES. S-ES.
The withdrawal of the last S-PMSI route for a given (*,G) SHOULD The withdrawal of the last S-PMSI A-D route for a given
make the downstream PE remove the S-ESI label based RPF check on (*,G)/(S,G) that represents a SFG SHOULD make the downstream PE
(*,G). remove the S-ESI label based RPF check on (*,G)/(S,G).
5.1 Use of BFD in the HS Solution 5.1 Use of BFD in the HS Solution
This section will be completed in a future version of this document. The BGP-BFD Attribute (advertised along with the S-PMSI A-D routes)
and similar procedures as the ones described in [MVPN-FAST-FAILOVER]
MAY be used to bootstrap multipoint BFD sessions on the downstream
PEs.
5.2 HS Example in an OISM Network 5.2 HS Example in an OISM Network
Figure 6 illustrates the HS model in an OISM network. As in previous Figure 6 illustrates the HS model in an OISM network. Consider S1 and
examples, S1 and S2 are redundant G-sources for the SFG (*,G1) in S2 are redundant G-sources for the SFG (*,G1) in BD1 (any source
BD1. S1 and S2 are (all-active) multi-homed to upstream PEs, PE1 and using G1 is assumed to transmit an SFG). S1 and S2 are (all-active)
PE2. The receivers are attached to downstream PEs, PE3 and PE5, in multi-homed to upstream PEs, PE1 and PE2. The receivers are attached
BD3 and BD1, respectively. S1 and S2 are assumed to be connected by a to downstream PEs, PE3 and PE5, in BD3 and BD1, respectively. S1 and
LAG to the multi-homing PEs, and the multicast traffic can use the S2 are assumed to be connected by a LAG to the multi-homing PEs, and
link to either upstream PE. The diagram illustrates how S1 sends the the multicast traffic can use the link to either upstream PE. The
G-traffic to PE1 and PE1 forwards to the remote interested downstream diagram illustrates how S1 sends the G-traffic to PE1 and PE1
PEs, whereas S2 sends to PE2 and PE2 forwards further. In this HS forwards to the remote interested downstream PEs, whereas S2 sends to
model, the interested downstream PEs will get duplicate G-traffic PE2 and PE2 forwards further. In this HS model, the interested
from the two G-sources for the same SFG. While the diagram shows that downstream PEs will get duplicate G-traffic from the two G-sources
the two flows are forwarded by different upstream PEs, the all-active for the same SFG. While the diagram shows that the two flows are
multi-homing procedures may cause that the two flows come from the forwarded by different upstream PEs, the all-active multi-homing
same upstream PE. Therefore, finding out the upstream PE for the flow procedures may cause that the two flows come from the same upstream
is not enough for the downstream PEs to program the required RPF PE. Therefore, finding out the upstream PE for the flow is not enough
check to avoid duplicate packets on the receiver. for the downstream PEs to program the required RPF check to avoid
duplicate packets on the receiver.
S1(ESI-1) S2(ESI-2) S1(ESI-1) S2(ESI-2)
| | | |
| +----------------------+ | +----------------------+
(S1,G1)| | (S2,G1)| (S1,G1)| | (S2,G1)|
+----------------------+ | +----------------------+ |
PE1 | | PE2 | | PE1 | | PE2 | |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
| +---+ | | +---+ | S-PMSI | +---+ | | +---+ | S-PMSI
S-PMSI | +---|BD1| | | +---|BD1| | (*,G1) S-PMSI | +---|BD1| | | +---|BD1| | (*,G1)
skipping to change at page 23, line 45 skipping to change at page 24, line 45
| ^ | ^ | ^ | ^
| | IGMP | | IGMP | | IGMP | | IGMP
R1 | J(*,G1) R3 | J(*,G1) R1 | J(*,G1) R3 | J(*,G1)
Figure 6 - HS Solution for Multi-homed Redundant G-Sources in OISM Figure 6 - HS Solution for Multi-homed Redundant G-Sources in OISM
In this scenario, the HS solution works as follows: In this scenario, the HS solution works as follows:
1. Configuration of the upstream PEs, PE1 and PE2 1. Configuration of the upstream PEs, PE1 and PE2
PE1 and PE2 are configured to know that G1 is an SFG and the PE1 and PE2 are configured to know that G1 is an SFG for any
redundant G-sources for G1 use S-ESIs ESI-1 and ESI-2 source (a source prefix length could have been configured instead)
and the redundant G-sources for G1 use S-ESIs ESI-1 and ESI-2
respectively. Both ESes are configured in both PEs and the ESI respectively. Both ESes are configured in both PEs and the ESI
value can be configured or auto-derived as an ES type 5. The ESI- value can be configured or auto-derived. The ESI-label values are
label values are allocated from a DCB [DCB] and are configured allocated from a DCB [DCB] and are configured either locally or by
either locally or by a centralized controller. We assume ESI-1 is a centralized controller. We assume ESI-1 is configured to use
configured to use ESI-label-1 and ESI-2 to use ESI-label-2. ESI-label-1 and ESI-2 to use ESI-label-2.
The downstream PEs, PE3, PE4 and PE5 are configured to support HS The downstream PEs, PE3, PE4 and PE5 are configured to support HS
mode and select the G-source with e.g., lowest ESI value. mode and select the G-source with e.g., lowest ESI value.
2. PE1 and PE2 advertise S-PMSI (*,G1) and ES/A-D routes 2. PE1 and PE2 advertise S-PMSI A-D (*,G1) and ES/A-D per ES/EVI
routes
Based on the configuration of step 1, PE1 and PE2 advertise an S- Based on the configuration of step 1, PE1 and PE2 advertise an S-
PMSI (*,G1) route each. The route from each of the two PEs will PMSI A-D (*,G1) route each. The route from each of the two PEs
include the ESI attribute with ESI-1 and ESI-2, as well as BD1-RT will include TWO ESI Label Extended Communities with ESI-1 and
plus SBD-RT and a flag that indicates that G1 is an SFG. ESI-2 respectively, as well as BD1-RT plus SBD-RT and a flag that
indicates that (*,G1) is an SFG.
In addition, PE1 and PE2 advertise ES and A-D routes for ESI-1 and In addition, PE1 and PE2 advertise ES and A-D per ES/EVI routes
ESI-2. The A-D per-ES and per-EVI routes will include the SBD-RT for ESI-1 and ESI-2. The A-D per ES and per EVI routes will
so that they can be imported by the downstream PEs that are not include the SBD-RT so that they can be imported by the downstream
attached to BD1, e.g., PE3 and PE4. The A-D per-ES routes will PEs that are not attached to BD1, e.g., PE3 and PE4. The A-D per
convey ESI-label-1 for ESI-1 (on both PEs) and ESI-label-2 for ES routes will convey ESI-label-1 for ESI-1 (on both PEs) and ESI-
ESI-2 (also on both PEs). label-2 for ESI-2 (also on both PEs).
3. Processing of A-D routes and RPF check 3. Processing of A-D per ES/EVI routes and RPF check
PE1 and PE2 received each other's ES and A-D routes. Regular PE1 and PE2 received each other's ES and A-D per ES/EVI routes.
[RFC7432] [DF] procedures will be followed for DF Election and Regular [RFC7432] [RFC8584] procedures will be followed for DF
programming of the ESI-labels for egress split-horizon filtering. Election and programming of the ESI-labels for egress split-
PE3/PE4 import the A-D routes in the SBD. Since PE3 has created a horizon filtering. PE3/PE4 import the A-D per ES/EVI routes in the
(*,G1) state based on local interest, PE3 will add an RPF check to SBD. Since PE3 has created a (*,G1) state based on local interest,
(*,G1) so that packets coming with ESI-label-2 are discarded PE3 will add an RPF check to (*,G1) so that packets coming with
(lowest ESI value is assumed to give the primary S-ES). ESI-label-2 are discarded (lowest ESI value is assumed to give the
primary S-ES).
4. G-traffic forwarding and fault detection 4. G-traffic forwarding and fault detection
PE1 receives G-traffic (S1,G1) on ES-1 that is forwarded within PE1 receives G-traffic (S1,G1) on ES-1 that is forwarded within
the context of BD1. Irrespective of the tunnel type, PE1 pushes the context of BD1. Irrespective of the tunnel type, PE1 pushes
ESI-label-1 at the bottom of the stack and the traffic gets to PE3 ESI-label-1 at the bottom of the stack and the traffic gets to PE3
and PE5 with the mentioned ESI-label (PE4 has no local interested and PE5 with the mentioned ESI-label (PE4 has no local interested
receivers). The G-traffic with ESI-label-1 passes the RPF check receivers). The G-traffic with ESI-label-1 passes the RPF check
and it is forwarded to R1. In the same way, PE2 sends (S2,G1) with and it is forwarded to R1. In the same way, PE2 sends (S2,G1) with
ESI-label-2, but this G-traffic does not pass the RPF check and ESI-label-2, but this G-traffic does not pass the RPF check and
gets discarded at PE3/PE5. gets discarded at PE3/PE5.
If the link from S1 to PE1 fails, S1 will forward the (S1,G1) If the link from S1 to PE1 fails, S1 will forward the (S1,G1)
traffic to PE2 instead. PE1 withdraws the ES and A-D routes for traffic to PE2 instead. PE1 withdraws the ES and A-D routes for
ESI-1. Now both flows will be originated by PE2, however the RPF ESI-1. Now both flows will be originated by PE2, however the RPF
checks don't change in PE3/PE5. checks don't change in PE3/PE5.
If subsequently, the link from S1 to PE2 fails, PE2 also withdraws If subsequently, the link from S1 to PE2 fails, PE2 also withdraws
the ES and A-D routes for ESI-1. Since PE3 and PE5 have no longer the ES and A-D routes for ESI-1. Since PE3 and PE5 have no longer
A-D routes for ESI-1, they immediately change the RPF check so A-D per ES/EVI routes for ESI-1, they immediately change the RPF
that packets with ESI-label-2 are now accepted. check so that packets with ESI-label-2 are now accepted.
Figure 7 illustrates a scenario where S1 and S2 are single-homed to Figure 7 illustrates a scenario where S1 and S2 are single-homed to
PE1 and PE2 respectively. This scenario is a sub-case of the one in PE1 and PE2 respectively. This scenario is a sub-case of the one in
Figure 6. Now ES-1 only exists in PE1, hence only PE1 advertises the Figure 6. Now ES-1 only exists in PE1, hence only PE1 advertises the
A-D routes for ESI-1. Similarly, ES-2 only exists in PE2 and PE2 is A-D per ES/EVI routes for ESI-1. Similarly, ES-2 only exists in PE2
the only PE advertising A-D routes for ESI-2. The same procedures as and PE2 is the only PE advertising A-D routes for ESI-2. The same
in Figure 6 applies to this use-case. procedures as in Figure 6 applies to this use-case.
S1(ESI-1) S2(ESI-2) S1(ESI-1) S2(ESI-2)
| | | |
(S1,G1)| (S2,G1)| (S1,G1)| (S2,G1)|
| | | |
PE1 | PE2 | PE1 | PE2 |
+--------v---+ +--------v---+ +--------v---+ +--------v---+
| +---+ | | +---+ | S-PMSI | +---+ | | +---+ | S-PMSI
S-PMSI | +---|BD1| | | +---|BD2| | (*,G1) S-PMSI | +---|BD1| | | +---|BD2| | (*,G1)
(*,G1) | |VRF+---+ | | |VRF+---+ | SFG (*,G1) | |VRF+---+ | | |VRF+---+ | SFG
skipping to change at page 26, line 17 skipping to change at page 27, line 20
include any SBD-RT and all the procedures apply to BD1 only. include any SBD-RT and all the procedures apply to BD1 only.
6. Security Considerations 6. Security Considerations
The same Security Considerations described in [OISM] are valid for The same Security Considerations described in [OISM] are valid for
this document. this document.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate a Bit in the Multicast Flags Extended IANA is requested to allocate a Bit in the Multicast Flags Extended
Community. Community to indicate that a given (*,G) or (S,G) in an S-PMSI A-D
route is associated with an SFG.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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>.
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012,
<https://www.rfc-editor.org/info/rfc6513>. <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC
6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc- 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-
editor.org/info/rfc6514>. editor.org/info/rfc6514>.
[IGMP-PROXY] Sajassi, A. et al, "IGMP and MLD Proxy for EVPN", June [IGMP-PROXY] Sajassi, A. et al, "IGMP and MLD Proxy for EVPN", June
2018, work-in-progress, draft-ietf-bess-evpn-igmp-mld-proxy-02. 2019, work-in-progress, draft-ietf-bess-evpn-igmp-mld-proxy-03.
[OISM] Rosen, E. et al, "EVPN Optimized Inter-Subnet Multicast [OISM] Rosen, E. et al, "EVPN Optimized Inter-Subnet Multicast
(OISM) Forwarding", June 2018, work-in-progress, draft-ietf-bess- (OISM) Forwarding", January 2019, work-in-progress, draft-ietf-bess-
evpn-irb-mcast-01. evpn-irb-mcast-02.
[DF] Rabadan, J., Mohanty, S., Sajassi, A., Drake, J., Nagaraj, K., [RFC8584] Rabadan, J., Mohanty, S., Sajassi, A., Drake, J., Nagaraj,
and S. Sathappan, "Framework for EVPN Designated Forwarder Election K., and S. Sathappan, "Framework for Ethernet VPN Designated
Extensibility", internet-draft draft-ietf-bess-evpn-df-election- Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584,
framework-05.txt, October 2018. April 2019, <https://rfc-editor.org/rfc/rfc8584.txt>.
[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, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/info/rfc2119>. 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.
[DCB] Zhang, Z. et al, "MVPN/EVPN Tunnel Aggregation with Common [DCB] Zhang, Z. et al, "MVPN/EVPN Tunnel Aggregation with Common
Labels", April 2018, work-in-progress, draft-zzhang-bess-mvpn-evpn- Labels", April 2018, work-in-progress, draft-zzhang-bess-mvpn-evpn-
aggregation-label-01. aggregation-label-01.
[MVPN-FAST-FAILOVER] Morin, T., Kebler, R., and G. Mirsky,
"Multicast VPN fast upstream failover", draft-ietf-bess-mvpn-fast-
failover-06 (work in progress), July 2019.
8.2. Informative References 8.2. Informative References
[EVPN-RT5] Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. [EVPN-RT5] Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", internet-draft ietf-bess- Sajassi, "IP Prefix Advertisement in EVPN", internet-draft ietf-bess-
evpn-prefix-advertisement-11.txt, May 2018. evpn-prefix-advertisement-11.txt, May 2018.
[EVPN-BUM] Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates [EVPN-BUM] Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates
on EVPN BUM Procedures", internet-draft ietf-bess-evpn-bum-procedure- on EVPN BUM Procedures", internet-draft ietf-bess-evpn-bum-procedure-
updates-03, April 2018. updates-06, June 2019.
[DF-PREF] Rabadan, J., Sathappan, S., Przygienda, T., Lin, W., [DF-PREF] Rabadan, J., Sathappan, S., Przygienda, T., Lin, W.,
Drake, J., Sajassi, A., and S. Mohanty, "Preference-based EVPN DF Drake, J., Sajassi, A., and S. Mohanty, "Preference-based EVPN DF
Election", internet-draft ietf-bess-evpn-pref-df-02.txt, October Election", internet-draft ietf-bess-evpn-pref-df-04.txt, June 2019.
2018.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
<https://www.rfc-editor.org/info/rfc5701>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
<https://www.rfc-editor.org/info/rfc4364>. <https://www.rfc-editor.org/info/rfc4364>.
9. Acknowledgments 9. Acknowledgments
10. Contributors The authors would like to thank Mankamana Mishra and Ali Sajassi for
their review and valuable comments.
10. Contributors
Authors' Addresses Authors' Addresses
Jorge Rabadan Jorge Rabadan
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
701 E. Middlefield Road 701 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
skipping to change at page 28, line 23 skipping to change at page 29, line 25
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
Jayant Kotalwar Jayant Kotalwar
Nokia Nokia
701 E. Middlefield Road 701 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jayant.kotalwar@nokia.com Email: jayant.kotalwar@nokia.com
Eric C. Rosen Eric C. Rosen
Juniper Networks, Inc. EMail: erosen52@gmail.com
EMail: erosen@juniper.net
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Wen Lin Wen Lin
Juniper Networks, Inc. Juniper Networks, Inc.
EMail: wlin@juniper.net EMail: wlin@juniper.net
 End of changes. 78 change blocks. 
261 lines changed or deleted 298 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/