draft-ietf-bess-evpn-virtual-eth-segment-05.txt   draft-ietf-bess-evpn-virtual-eth-segment-06.txt 
BESS WorkGroup A. Sajassi BESS WorkGroup A. Sajassi
Internet-Draft P. Brissette Internet-Draft P. Brissette
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: September 3, 2020 R. Schell Expires: September 10, 2020 R. Schell
Verizon Verizon
J. Drake J. Drake
Juniper Juniper
J. Rabadan J. Rabadan
Nokia Nokia
March 2, 2020 March 9, 2020
EVPN Virtual Ethernet Segment EVPN Virtual Ethernet Segment
draft-ietf-bess-evpn-virtual-eth-segment-05 draft-ietf-bess-evpn-virtual-eth-segment-06
Abstract Abstract
EVPN and PBB-EVPN introduce a family of solutions for multipoint EVPN and PBB-EVPN introduce a family of solutions for multipoint
Ethernet services over MPLS/IP network with many advanced features Ethernet services over MPLS/IP network with many advanced features
among which their multi-homing capabilities. These solutions among which their multi-homing capabilities. These solutions
introduce Single-Active and All-Active for an Ethernet Segment (ES), introduce Single-Active and All-Active for an Ethernet Segment (ES),
itself defined as a set of physical links between the multi-homed itself defined as a set of physical links between the multi-homed
device/network and a set of PE devices that they are connected to. device/network and a set of PE devices that they are connected to.
This document extends the Ethernet Segment concept so that an ES can This document extends the Ethernet Segment concept so that an ES can
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 3, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Local Switching . . . . . . . . . . . . . . . . . . . . . 8 3.3. Local Switching . . . . . . . . . . . . . . . . . . . . . 8
3.4. EVC Service Types . . . . . . . . . . . . . . . . . . . . 9 3.4. EVC Service Types . . . . . . . . . . . . . . . . . . . . 9
3.5. Designated Forwarder (DF) Election . . . . . . . . . . . 9 3.5. Designated Forwarder (DF) Election . . . . . . . . . . . 9
3.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Failure and Recovery . . . . . . . . . . . . . . . . . . 10 3.7. Failure and Recovery . . . . . . . . . . . . . . . . . . 10
3.8. Fast Convergence . . . . . . . . . . . . . . . . . . . . 10 3.8. Fast Convergence . . . . . . . . . . . . . . . . . . . . 10
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 11
4.1. EVPN DF Election for vES . . . . . . . . . . . . . . . . 12 4.1. EVPN DF Election for vES . . . . . . . . . . . . . . . . 12
5. Failure Handling and Recovery . . . . . . . . . . . . . . . . 13 5. Failure Handling and Recovery . . . . . . . . . . . . . . . . 13
5.1. Failure Handling for Single-Active vES in EVPN . . . . . 14 5.1. EVC Failure Handling for Single-Active vES in EVPN . . . 15
5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . 15 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . 15
5.3. Port Failure Handling for Single-Active vESes in EVPN . . 16 5.3. Port Failure Handling for Single-Active vESes in EVPN . . 16
5.4. Port Failure Handling for Single-Active vESes in PBB-EVPN 17 5.4. Port Failure Handling for Single-Active vESes in PBB-EVPN 17
5.5. Fast Convergence in (PBB-)EVPN . . . . . . . . . . . . . 18 5.5. Fast Convergence in (PBB-)EVPN . . . . . . . . . . . . . 18
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
6.1. I-SID Extended Community . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Intellectual Property Considerations . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Intellectual Property Considerations . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[RFC7432] and [RFC7623] introduce a family of solutions for [RFC7432] and [RFC7623] introduce a family of solutions for
multipoint Ethernet services over MPLS/IP network with many advanced multipoint Ethernet services over MPLS/IP network with many advanced
features among which their multi-homing capabilities. These features among which their multi-homing capabilities. These
solutions introduce Single-Active and All-Active for an Ethernet solutions introduce Single-Active and All-Active for an Ethernet
Segment (ES), itself defined as a set of links between the multi- Segment (ES), itself defined as a set of links between the multi-
homed device/network and a set of PE devices that they are connected homed device/network and a set of PE devices that they are connected
to. to.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
LSPs, this document extends Single-Active multi-homing procedures of LSPs, this document extends Single-Active multi-homing procedures of
[RFC7432] and [RFC7623] to vES. The vES extension to All-Active [RFC7432] and [RFC7623] to vES. The vES extension to All-Active
multi- homing is outside of the scope of this document for MPLS/IP multi- homing is outside of the scope of this document for MPLS/IP
access networks. access networks.
This draft describes requirements and the extensions needed to This draft describes requirements and the extensions needed to
support a vES in [RFC7432] and [RFC7623]. Section 3 lists the set of support a vES in [RFC7432] and [RFC7623]. Section 3 lists the set of
requirements for a vES. Section 4 describes extensions for a vES requirements for a vES. Section 4 describes extensions for a vES
that are applicable to EVPN solutions including [RFC7432] and that are applicable to EVPN solutions including [RFC7432] and
[RFC7209]. Furthermore, these extensions meet the requirements [RFC7209]. Furthermore, these extensions meet the requirements
described in section 3. Section 4 gives solution overview and described in Section 3. Section 4 gives solution overview and
section 5 describes failure handling, recovery, scalability, and fast Section 5 describes failure handling, recovery, scalability, and fast
convergence of [RFC7432] and [RFC7623] for vESes. Section 6 convergence of [RFC7432] and [RFC7623] for vESes.
introduces a new BGP extended community and its encoding.
2. Terminology 2. Terminology
AC: Attachment Circuit AC: Attachment Circuit
BEB: Backbone Edge Bridge BEB: Backbone Edge Bridge
B-MAC: Backbone MAC Address B-MAC: Backbone MAC Address
CE: Customer Edge CE: Customer Edge
skipping to change at page 10, line 26 skipping to change at page 10, line 26
(R6b) A single EVC failure (among many aggregated on a single (R6b) A single EVC failure (among many aggregated on a single
physical port/ENNI) MUST trigger DF election for its associated vES. physical port/ENNI) MUST trigger DF election for its associated vES.
3.7. Failure and Recovery 3.7. Failure and Recovery
(R7a) Failure and failure recovery of an EVC for a Single-homed vES (R7a) Failure and failure recovery of an EVC for a Single-homed vES
SHALL NOT impact any other EVCs within its service instance or any SHALL NOT impact any other EVCs within its service instance or any
other service instances. In other words, for PBB-EVPN, it SHALL NOT other service instances. In other words, for PBB-EVPN, it SHALL NOT
trigger any MAC flushing both within its own I-SID as well as other trigger any MAC flushing both within its own I-SID as well as other
I-SIDs. (R7b) In case of All-Active vES, failure and failure I-SIDs.
recovery of an EVC for that vES SHALL NOT impact any other EVCs
within its service instance or any other service instances. In other (R7b) In case of All-Active vES, failure and failure recovery of an
words, for PBB-EVPN, it SHALL NOT trigger any MAC flushing both EVC for that vES SHALL NOT impact any other EVCs within its service
within its own I-SID as well as other I-SIDs. (R7c) Failure and instance or any other service instances. In other words, for PBB-
failure recovery of an EVC for a Single-Active vES SHALL impact only EVPN, it SHALL NOT trigger any MAC flushing both within its own I-SID
its own service instance. In other words, for PBB- EVPN, MAC as well as other I-SIDs.
flushing SHALL be limited to the associated I-SID only and SHALL NOT
impact any other I-SIDs. (R7d) Failure and failure recovery of an (R7c) Failure and failure recovery of an EVC for a Single-Active vES
EVC for a Single-Active vES MAY only impact C-MACs associated with SHALL impact only its own service instance. In other words, for PBB-
MHD/MHNs for that service instance. In other words, MAC flushing EVPN, MAC flushing SHALL be limited to the associated I-SID only and
SHOULD be limited to single service instance (I-SID in the case of SHALL NOT impact any other I-SIDs.
PBB-EVPN) and only CMACs for Single-Active MHD/MHNs.
(R7d) Failure and failure recovery of an EVC for a Single-Active vES
MAY only impact C-MACs associated with MHD/MHNs for that service
instance. In other words, MAC flushing SHOULD be limited to single
service instance (I-SID in the case of PBB-EVPN) and only CMACs for
Single-Active MHD/MHNs.
3.8. Fast Convergence 3.8. Fast Convergence
Since large number of EVCs (and their associated vESes) are Since large number of EVCs (and their associated vESes) are
aggregated via a single physical port (e.g., ENNI), then the failure aggregated via a single physical port (e.g., ENNI), then the failure
of that physical port impacts large number of vESes and triggers of that physical port impacts large number of vESes and triggers
large number of ES route withdrawals. Formulating, sending, large number of ES route withdrawals. Formulating, sending,
receiving, and processing such large number of BGP messages can receiving, and processing such large number of BGP messages can
introduce delay in DF election and convergence time. As such, it is introduce delay in DF election and convergence time. As such, it is
highly desirable to have a mass-withdraw mechanism similar to the one highly desirable to have a mass-withdraw mechanism similar to the one
skipping to change at page 11, line 13 skipping to change at page 11, line 19
such that upon an ENNI failure, only a single BGP message is needed such that upon an ENNI failure, only a single BGP message is needed
to indicate to the remote PEs to trigger DF election for all impacted to indicate to the remote PEs to trigger DF election for all impacted
vES associated with that ENNI. vES associated with that ENNI.
4. Solution Overview 4. Solution Overview
The solutions described in [RFC7432] and [RFC7623] are leveraged as- The solutions described in [RFC7432] and [RFC7623] are leveraged as-
is with the modification that the ESI assignment is performed for an is with the modification that the ESI assignment is performed for an
EVC or a group of EVCs or LSPs/PWs instead of a link or a group of EVC or a group of EVCs or LSPs/PWs instead of a link or a group of
physical links. In other words, the ESI is associated with a virtual physical links. In other words, the ESI is associated with a virtual
ES (vES), hereby referred to as vESI. For the EVPN solution, ES (vES), hereby referred to as vESI.
everything basically remains the same except for the handling of
physical port failure where many vESes can be impacted. Section 5.1 For the EVPN solution, everything basically remains the same except
and 5.3 below describe the handling of physical port/link failure for for the handling of physical port failure where many vESes can be
EVPN. In a typical multi-homed operation, MAC addresses are learned impacted. Sections 5.1 and 5.3 below describe the handling of
behind a vES and are advertised with the ESI corresponding to the vES physical port/link failure for EVPN. In a typical multi-homed
(i.e., vESI). EVPN aliasing and mass- withdraw operations are operation, MAC addresses are learned behind a vES and are advertised
performed with respect to vES. In other words, the Ethernet A-D with the ESI corresponding to the vES (i.e., vESI). EVPN aliasing
routes for these operations are advertised with vESI instead of ESI. and mass- withdraw operations are performed with respect to vES. In
other words, the Ethernet A-D routes for these operations are
advertised with vESI instead of ESI.
For PBB-EVPN solution, the main change is with respect to the BMAC For PBB-EVPN solution, the main change is with respect to the BMAC
address assignment which is performed similar to what is described in address assignment which is performed similar to what is described in
section 7.2.1.1 of [RFC7623] with the following refinements: section 7.2.1.1 of [RFC7623] with the following refinements:
o One shared BMAC address SHOULD used per PE for the single-homed o One shared BMAC address SHOULD be used per PE for the single-homed
vESes. In other words, a single BMAC is shared for all single- vESes. In other words, a single BMAC is shared for all single-
homed vESes on that PE. homed vESes on that PE.
o One shared BMAC address SHOULD be used per PE per physical port o One shared BMAC address SHOULD be used per PE per physical port
(e.g., ENNI) for the Single-Active vESes. In other words, a (e.g., ENNI) for the Single-Active vESes. In other words, a
single BMAC is shared for all Single-Active vESes that share the single BMAC is shared for all Single-Active vESes that share the
same ENNI. same ENNI.
o One shared BMAC address MAY be used for all Single-Active vESes on o One shared BMAC address MAY be used for all Single-Active vESes on
that PE. that PE.
skipping to change at page 14, line 9 skipping to change at page 14, line 14
C: PE access-facing port or link failure C: PE access-facing port or link failure
D: PE node failure D: PE node failure
E: PE isolation from IP/MPLS network E: PE isolation from IP/MPLS network
[RFC7432], [RFC7623], and [RFC8214] solutions provide protection [RFC7432], [RFC7623], and [RFC8214] solutions provide protection
against such failures as described in the corresponding references. against such failures as described in the corresponding references.
In the presence of virtual Ethernet Segments (vESes) in these In the presence of virtual Ethernet Segments (vESes) in these
solutions, besides the above failure scenarios, EVC failure is an solutions, besides the above failure scenarios, EVC failure is an
additional scenario to consider. Handing vES failure scenarios additional scenario to consider. Handling vES failure scenarios
implies that individual EVCs or PWs need to be monitored and upon implies that individual EVCs or PWs need to be monitored and upon
detection of failure or restoration of services, appropriate DF detection of failure or restoration of services, appropriate DF
election and failure recovery mechanisms are executed. election and failure recovery mechanisms are executed.
[ETH-OAM] is used for monitoring EVCs and upon failure detection of a [ETH-OAM] is used for monitoring EVCs and upon failure detection of a
given EVC, DF election procedure per section [4.1] is executed. For given EVC, DF election procedure per section [4.1] is executed. For
PBB-EVPN, some extensions are needed to handle the failure and PBB-EVPN, some extensions are needed to handle the failure and
recovery procedures of [RFC7623] in order to meet the above recovery procedures of [RFC7623] in order to meet the above
requirements. These extensions are described in the next section. requirements. These extensions are described in the next section.
skipping to change at page 14, line 43 skipping to change at page 15, line 5
| CE2 | | | +---+ | | | CE2 | | | +---+ | |
| |EVC3--0=====0--ENNI2|PE2|---| | | |EVC3--0=====0--ENNI2|PE2|---| |
+-----+ | | | | +-------+ +-----+ | | | | +-------+
+-----+ +---+ +-----+ +---+
/\ /\ /\ /\ /\ /\
|| || || || || ||
A C E A C E
Figure 4: Failure Scenarios A,B,C,D and E Figure 4: Failure Scenarios A,B,C,D and E
5.1. Failure Handling for Single-Active vES in EVPN 5.1. EVC Failure Handling for Single-Active vES in EVPN
In RFC7432, when a DF PE connected to a Single-Active multi-homed In RFC7432, when a DF PE connected to a Single-Active multi-homed
Ethernet Segment loses connectivity to the segment, due to link or Ethernet Segment loses connectivity to the segment, due to link or
port failure, it signals to the remote PEs to withdraw all MAC port failure, it signals to the remote PEs to withdraw all MAC
addresses associated with that Ethernet Segment. This is done by addresses associated with that Ethernet Segment. This is done by
advertising a mass-withdraw message using Ethernet A-D per-ES route. advertising a mass-withdraw message using Ethernet A-D per-ES route.
It should be noted that for dual-homing use cases where there is only It should be noted that for dual-homing use cases where there is only
a single backup path, MAC withdraw can be avoided by the remote PEs a single backup path, MAC withdraw can be avoided by the remote PEs
as they can simply update their nexthop associated with the affected as they can simply update their nexthop associated with the affected
MAC entries to the backup path per procedure described in section 8.2 MAC entries to the backup path per procedure described in section 8.2
of [RFC7432]. of [RFC7432].
In case of an EVC failure which impacts a single vES, the exact same In case of an EVC failure which impacts a single vES, the exact same
EVPN procedure is used. In this case, the message using Ethernet A-D EVPN procedure is used. In this case, the message using Ethernet A-D
per vES route carries the vESI representing the vES which in turn is per-vES route carries the vESI representing the vES which in turn is
associated with the failed EVC. The remote PEs upon receiving this associated with the failed EVC. The remote PEs upon receiving this
message perform the same procedures outlined in section 8.2 of message perform the same procedures outlined in section 8.2 of
[RFC7432]. [RFC7432].
5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN
When a PE connected to a Single-Active Ethernet Segment loses In [RFC7432], when a PE connected to a Single-Active Ethernet Segment
connectivity to the segment, due to link or port failure, it signals loses connectivity to the segment, due to link or port failure, it
the remote PE to flush all CMAC addresses associated with that signals the remote PE to flush all CMAC addresses associated with
Ethernet Segment. This is done by advertising a BMAC route along that Ethernet Segment. This is done by advertising a BMAC route
with MAC Mobility Extended community. along with MAC Mobility Extended community.
In case of an EVC failure that impacts a single vES, if the above In case of an EVC failure that impacts a single vES, if the above
PBB-EVPN procedure is used, it results in excessive CMAC flushing PBB-EVPN procedure is used, it results in excessive CMAC flushing
because a single physical port can support large number of EVCs (and because a single physical port can support large number of EVCs (and
their associated vESes) and thus advertising a BMAC corresponding to their associated vESes) and thus advertising a BMAC corresponding to
the physical port with MAC mobility Extended community will result in the physical port with MAC mobility Extended community will result in
flushing CMAC addresses not just for the impacted EVC but for all flushing CMAC addresses not just for the impacted EVC but for all
other EVCs on that port. other EVCs on that port.
In order to reduce the scope of CMAC flushing to only the impacted In order to reduce the scope of CMAC flushing to only the impacted
service instances (the service instance(s) impacted by the EVC service instances (the service instance(s) impacted by the EVC
failure), the BGP flush message is sent along with a list of impacted failure), the PBB-EVPN CMAC flushing needs to be adapted on a per
I-SID(s) represented by the new EVPN I-SID Extended Community as service instance basis (i.e., per I-SID).
defined in section 6. Since typically an EVC maps to a single [I-D.ietf-bess-pbb-evpn-isid-cmacflush] introduces BMAC/I-SID route
broadcast domain and thus a single service instance, the list only where existing PBB-EVPN BMAC route is modified to carry an I-SID in
contains a single I-SID. However, if the failed EVC carries multiple the "Ethernet Tag ID" field instead of NULL value. This field
VLANs each with its own broadcast domain, then the list contains indicates to the receiving PE, to flush all CMAC addresses associated
several I-SIDs - one for each broadcast domain. This new BGP flush with that I-SID for that BMAC. This CMAC flushing mechanism per
message basically instructs the remote PE to perform flushing for I-SID SHOULD be used in case of EVC failure impacting a vES. Since
CMACs corresponding to the advertised BMAC only across the advertised typically an EVC maps to a single broadcast domain and thus a single
list of I-ISIDs. service instance, the affected PE only needs to advertise a single
BMAC/I-SID route. However, if the failed EVC carries multiple VLANs
The new I-SID Extended Community provides a way to encode upto 24 I- each with its own broadcast domain, then the affected PE needs to
SIDs in each Extended Community if the impacted I-SIDs are sequential advertise multiple BMAC/I-SID routes - one for each VLAN (broadcast
(the base I-SID value plus the next 23 I-SID values). If the number domain) - i.e., one for each I-SID. Each BMAC/I-SID route basically
of I-SIDs associated with a failed EVC is large or if the affected I- instructs the remote PEs to perform flushing for CMACs corresponding
SIDs are not sequential, then multiple I-SID Extended Communities can to the advertised BMAC only for the advertised I-SID.
be sent along with the flush message. However, if the number of
affected I-SIDs is very large such that the corresponding I-SID
Extended Communities cannot be fitted in a single BGP attribute, then
the EVC failure can be treated as a port failure and the procedures
of section 5.4 can be exercised (i.e., a single BGP flush message
without the I-SID list can be transmitted). When the BGP flush
message is transmitted without the I-SID list, then it instructs the
receiving PEs to flush CMACs associated with that BMAC across all I-
SIDs.
There can be scenarios (although unlikely) where multiple EVCs within
the same physical port can fail within a short time resulting in the
PE advertising multiple BGP flush messages each with their own list
of I-SIDs; however, the route reflector receiving these messages will
only send the last flush message. This results in PEs receiving such
flush messages not to properly flush all the affected I-SIDs. In
order to address such scenarios, a timer T1 is started upon an EVC1
failure on the advertising PE. If there is another EVC2 failure
within T1, affected I-SIDs are aggregated for both EVC1 and EVC2 to
be sent along the new flush message. Furthermore when EVC2 failure
occurs, another timer T2 (with the same value as T1) is started to
keep track of the affected I-SIDs for EVC2. Such I-SID aggregation
may result in multiple flushing for the same I-SID(s) on the
receiving PEs. The default value for this timer T is 10 seconds.
The I-SID dependent flushing mechanism described in this section is
also backward compatible for the PEs supporting [RFC7623] such that
the PEs that don't understand the I-SID list (i.e., the new I-SID
Extended Community) simply ignore it and default to flushing all the
I-SIDs for the B-MAC - i.e., the PEs default to per-port flushing
described in section 5.4.
The above BMAC route that is advertised with the MAC Mobility The CMAC flushing based on BMAC/I-SID route works fine when there are
Extended Community, can either represent the MAC address of the only a few VLANs (e.g., I-SIDs) per EVC. However if the number of
physical port that the failed EVC is associated with, or it can I-SIDs associated with a failed EVC is large, then it is recommended
represent the MAC address of the PE. In the latter case, this is the to assign a BMAC per vES and upon EVC failure, the affected PE simply
dedicated per-PE MAC address used for all Single-Active vESes on that advertise BMAC withdraw message to other PEs.
PE. The former one performs better than the latter one in terms of
reducing the scope of flushing and thus it is the recommended
approach because only CMAC addresses for the impacted service
instances on the failed EVC are flushed.
5.3. Port Failure Handling for Single-Active vESes in EVPN 5.3. Port Failure Handling for Single-Active vESes in EVPN
When a large number of EVCs are aggregated via a single physical port When a large number of EVCs are aggregated via a single physical port
on a PE; where each EVC corresponds to a vES, then the port failure on a PE; where each EVC corresponds to a vES, then the port failure
impacts all the associated EVCs and their corresponding vESes. If impacts all the associated EVCs and their corresponding vESes. If
the number of EVCs corresponding to the Single-Active vESes for that the number of EVCs corresponding to the Single-Active vESes for that
physical port is in thousands, then thousands of service instances physical port is in thousands, then thousands of service instances
are impacted. Therefore, the BGP flush message need to be inclusive are impacted. Therefore, the BGP flush message need to be inclusive
of all these impacted service instances. In order to achieve this, of all these impacted service instances. In order to achieve this,
the following extensions are added to the baseline EVPN mechanism: the following extensions are added to the baseline EVPN mechanism:
1. When a PE advertises an Ethernet A-D per ES route for a given 1. When a PE advertises an Ethernet A-D per-ES route for a given
vES, it colors it with the MAC address of the physical port which vES, it colors it with the MAC address of the physical port which
is associated with that vES using EVPN Router's MAC Extended is associated with that vES using EVPN Router's MAC Extended
Community per [EVPN-IRB]. The receiving PEs take note of this Community per [EVPN-IRB]. The receiving PEs take note of this
color and create a list of vESes for this color. color and create a list of vESes for this color.
2. Upon a port failure (e.g., ENNI failure), the PE advertise a 2. Upon a port failure (e.g., ENNI failure), the PE advertise a
special mass-withdraw message with the MAC address of the failed special mass-withdraw message with the MAC address of the failed
port (i.e., the color of the port) encoded in the ESI field. For port (i.e., the color of the port) encoded in the ESI field. For
this encoding, type 3 ESI (RFC7432 section 5) is used with the this encoding, type 3 ESI (RFC7432 section 5) is used with the
MAC field set to the MAC address of the port and the 3-octet MAC field set to the MAC address of the port and the 3-octet
skipping to change at page 18, line 17 skipping to change at page 17, line 35
use the EVPN MAC route withdrawal message to signal the flush. use the EVPN MAC route withdrawal message to signal the flush.
2. If the PE shared MAC address is used for PBB encapsulation as 2. If the PE shared MAC address is used for PBB encapsulation as
BMAC SA, then upon the port failure, the PE MUST re-advertise BMAC SA, then upon the port failure, the PE MUST re-advertise
this MAC route with the MAC Mobility Extended Community to signal this MAC route with the MAC Mobility Extended Community to signal
the flush. the flush.
The first method is recommended because it reduces the scope of The first method is recommended because it reduces the scope of
flushing the most. flushing the most.
If there are large number of service instances (i.e., I-SIDs)
associated with each EVC, and if there is a BMAC assigned per vES as
recommended in the above section, then in order to handle port
failure efficiently, each vES MAY be color with another MAC
representing the physical port similar to the coloring mechanism for
EVPN. In other words, each BMAC representing a vES is advertised
with the EVPN Router's MAC Extended Community carrying the MAC
address of the physical port.The difference between coloring
mechanism for EVPN and PBB-EVPN is that for EVPN, the extended
community is advertised with the Ethernet A-D per ES route; whereas,
for PBB-EVPN, the extended community is advertised with the BMAC
route. As noted above, the advertisement of the extended community
along with BMAC route for coloring purpoes is optional and only
recommended when there are many vESes per physical port and each vES
is associated with very large number of service instances (i.e.,
large numbe of I-SIDs).
When coloring mechanism is used, the receiving PEs take note of the
color being advertised along with the BMAC route and for each such
color, they create a list of vESes associated with this color (i.e.,
associated with this MAC address). Now, when a port failure occurs,
the impacted PE needs to notify the other PEs of this color so that
these PEs can identify all the impacted vESes associated with this
color (from the above list) and flush CMACs associated with the
failed physical port. This is accomplished by withdrawing the MAC
route associated with the failed port.
5.5. Fast Convergence in (PBB-)EVPN 5.5. Fast Convergence in (PBB-)EVPN
As described above, when a large number of EVCs are aggregated via a As described above, when a large number of EVCs are aggregated via a
physical port on a PE, and where each EVC corresponds to a vES, then physical port on a PE, and where each EVC corresponds to a vES, then
the port failure impacts all the associated EVCs and their the port failure impacts all the associated EVCs and their
corresponding vESes. Two actions must be taken as the result of such corresponding vESes. Two actions must be taken as the result of such
port failure: port failure:
o For EVPN initiate mass-withdraw procedure for all vESes associated o For EVPN initiate mass-withdraw procedure for all vESes associated
with the failed port and for PBB-EVPN flush all CMACs associated with the failed port and for PBB-EVPN flush all CMACs associated
with the BMAC of the failed port across all the impacted I-SIDs with the failed port across all vESes and the impacted I-SIDs
o DF election for all impacted vESes associated with the failed port o DF election for all impacted vESes associated with the failed port
Section 5.3 already describes how perform mass-withdraw for all Section 5.3 already describes how perform mass-withdraw for all
affected vESes using a single BGP advertisment. Section 5.4 affected vESes using a single BGP advertisment. Section 5.4
describes how to flush CMAC address in the most optimum way - e.g., describes how to only flush CMAC address associated with the failed
to flush least number of CMAC addresses for the impacted I-SIDs. physical port (e.g., optimum CMAC flushing). This section describes
This section describes how to perform DF election in the most optimum how to perform DF election in the most optimum way - e.g., to trigger
way - e.g., to trigger DF election for all impacted vESes (which can DF election for all impacted vESes (which can be very large) among
be in thousands) among the participating PEs via a single BGP message the participating PEs via a single BGP message as opposed to sending
as opposed to sending thousands of BGP messages - one per vES. This large number of BGP messages - one per vES. This section assumes
section assumes that the MAC flushing mechanism described in section that the MAC flushing mechanism described in section 5.4, bullet (1)
5.4, bullet (1) is used. is used.
In order to devise such fast convergence mechanism that can be
triggered via a single BGP message, all vESes associated with a given
physical port (e.g., ENNI) are colored with the same color
representing that physical port. The MAC address of the physical
port is used for this coloring purposes and when the PE advertises an
ES route for a vES associated with that physical port, it advertises
it with an EVPN Router's MAC Extended Community indicating the color
of that port.
The receiving PEs take note of this color and for each such color,
they create a list of vESes associated with this color (i.e.,
associated with this MAC address). Now, when a port failure occurs,
the impacted PE needs to notify the other PEs of this color so that
these PEs can identify all the impacted vESes associated with this
color (from the above list) and re-execute DF election procedures for
all the impacted vESes. This is done by withdrawing the BMAC address
associated with the failed port.
+-----+ +-----+
+----+ | | +---+ +----+ | | +---+
| CE1|AC1--0=====0--ENNI1| | +-------+ | CE1|AC1--0=====0--ENNI1| | +-------+
| |AC2--0 | |PE1|--| | | |AC2--0 | |PE1|--| |
+----+ |\ ==0--ENNI2| | | | +----+ |\ ==0--ENNI2| | | |
| \/ | +---+ | | | \/ | +---+ | |
| /\ | |IP/MPLS| | /\ | |IP/MPLS|
+----+ |/ \ | +---+ |Network| +---+ +---+ +----+ |/ \ | +---+ |Network| +---+ +---+
| CE2|AC4--0 =0--ENNI3| | | |---|PE4|--|CE4| | CE2|AC4--0 =0--ENNI3| | | |---|PE4|--|CE4|
skipping to change at page 19, line 33 skipping to change at page 19, line 27
0 | | | 0 | | |
+----+ /| | +---+ | | +----+ /| | +---+ | |
| CE3|AC5- | | |PE3|--| | | CE3|AC5- | | |PE3|--| |
| |AC6--0=====0--ENNI4| | +-------+ | |AC6--0=====0--ENNI4| | +-------+
+----+ | | +---+ +----+ | | +---+
+-----+ +-----+
Figure 5: Fast Convergence Upon ENNI Failure Figure 5: Fast Convergence Upon ENNI Failure
The following describes the procedure for coloring vESes and fast The following describes the procedure for coloring vESes and fast
convergence using this color in more details: convergence for DF election using this color:
1. When a vES is configured, the PE colors the vES with the MAC 1. When a vES is configured, the PE colors the vES with the MAC
address of the corresponding physical port and advertises the address of the corresponding physical port and advertises the
Ethernet Segment route for this vES with this color. Ethernet Segment route for this vES with this color.
2. All other PEs (in the redundancy group) take note of this color 2. All other PEs (in the redundancy group) take note of this color
and add the vES to the list for this color. and add the vES to the list for this color.
3. Upon the occurrence of a port failure (e.g., an ENNI failure), 3. Upon the occurrence of a port failure (e.g., an ENNI failure),
for PBB-EVPN the PE sends the flush message by withdrawing the the PE withdraw the previously advertised MAC address associated
BMAC address associated with the failed port and for EVPN, the PE with the failed port. The PE should prioritize sending this MAC
withdraws Ethernet Segment route associated with the failed port. address withdraw message over vES route withdrawal messages of
The PE should prioritize sending this flush message over ES route impacted vESes.
withdrawal messages of impacted vESes.
4. On reception of the flush message, other PEs use this info to 4. On reception of this MAC withdraw message, other PEs in the
flush their impacted MACs and to initiate DF election procedures redundancy group use this info to initiate DF election procedures
across all their affected vESes. across all their affected vESes.
5. The PE with the physical port failure (ENNI failure), also sends 5. The PE with the physical port failure (ENNI failure), also sends
vES route withdrawal for every impacted vESes. The other PEs vES route withdrawal for every impacted vESes. The other PEs
upon receiving these messages, clear up their BGP tables. It upon receiving these messages, clear up their BGP tables. It
should be noted the vES route withdrawal messages are not used should be noted the vES route withdrawal messages are not used
for executing DF election procedures by the receiving PEs. for executing DF election procedures by the receiving PEs.
6. BGP Encoding 6. Acknowledgements
This document defines one new BGP Extended Community for EVPN.
6.1. I-SID Extended Community
A new EVPN BGP Extended Community called I-SID is introduced. This
new extended community is a transitive extended community with the
Type field of 0x06 (EVPN) and the Sub-Type of 0x07.
The I-SID Extended Community is encoded as an 8-octet value as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x07 | Base I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. | Bit Map (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: I-SID Extended Community
This extended community is used to indicate the list of I-SIDs
associated with a given Ethernet Segment.
24-bit map represents the next 24 I-SID after the base I-SID. For
example based I-SID of 10025 with 24-bit map of zero means, only a
single I-SID of 10025. I-SID of 10025 with bit map of 0x000001 means
there are two I-SIDs, 10025 and 10026.
7. Acknowledgements
The authors would like to thanks Mei Zhang, Jose Liste, and Luc Andre The authors would like to thanks Mei Zhang, Jose Liste, and Luc Andre
Burdet for their reviews and feedbacks of this document. Burdet for their reviews and feedbacks of this document.
8. Security Considerations 7. Security Considerations
All the security considerations in [RFC7432] and [RFC7623] apply All the security considerations in [RFC7432] and [RFC7623] apply
directly to this document because this document leverages the control directly to this document because this document leverages the control
and data plane procedures described in those documents. and data plane procedures described in those documents.
This document does not introduce any new security considerations This document does not introduce any new security considerations
beyond that of [RFC7432] and [RFC7623] because advertisements and beyond that of [RFC7432] and [RFC7623] because advertisements and
processing of Ethernet Segment route for vES in this document follows processing of Ethernet Segment route for vES in this document follows
that of physical ES in those RFCs. that of physical ES in those RFCs.
9. IANA Considerations 8. IANA Considerations
IANA has allocated sub-type value 7 in the "EVPN Extended Community IANA has allocated sub-type value 7 in the "EVPN Extended Community
Sub-Types" registry defined in "https://www.iana.org/assignments/bgp- Sub-Types" registry defined in "https://www.iana.org/assignments/bgp-
extended-communities/bgp-extended-communities.xhtml#evpn" as follows: extended-communities/bgp-extended-communities.xhtml#evpn" as follows:
SUB-TYPE NAME Reference SUB-TYPE NAME Reference
---- -------------- ------------- ---- -------------- -------------
0x07 I-SID Ext Comm [draft-ietf-bess-evpn-virtual-eth-segment] 0x07 I-SID Ext Comm [draft-ietf-bess-evpn-virtual-eth-segment]
It is requested from IANA to update the reference to this document. It is requested from IANA to update the reference to this document.
10. Intellectual Property Considerations 9. Intellectual Property Considerations
This document is being submitted for use in IETF standards This document is being submitted for use in IETF standards
discussions. discussions.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
skipping to change at page 22, line 19 skipping to change at page 21, line 19
[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, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>. <https://www.rfc-editor.org/info/rfc8214>.
11.2. Informative References 10.2. Informative References
[I-D.ietf-bess-pbb-evpn-isid-cmacflush]
Rabadan, J., Sathappan, S., Nagaraj, K., Miyake, M., and
T. Matsuda, "PBB-EVPN ISID-based CMAC-Flush", draft-ietf-
bess-pbb-evpn-isid-cmacflush-00 (work in progress),
October 2019.
[RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual
Private LAN Service (VPLS) Interoperability with Provider Private LAN Service (VPLS) Interoperability with Provider
Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080,
December 2013, <https://www.rfc-editor.org/info/rfc7080>. December 2013, <https://www.rfc-editor.org/info/rfc7080>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<https://www.rfc-editor.org/info/rfc7209>. <https://www.rfc-editor.org/info/rfc7209>.
 End of changes. 31 change blocks. 
181 lines changed or deleted 133 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/