draft-ietf-bess-evpn-virtual-eth-segment-02.txt   draft-ietf-bess-evpn-virtual-eth-segment-03.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Working Group A. Sajassi Internet Working Group A. Sajassi
Internet Draft P. Brissette Internet Draft P. Brissette
Category: Standards Track Cisco Category: Standards Track Cisco
R. Schell R. Schell
Verizon Verizon
J. Drake J. Drake
Juniper Juniper
J. Rabadan J. Rabadan
Nokia Nokia
Expires: July 08, 2019 January 08, 2019 Expires: July 09, 2019 January 09, 2019
EVPN Virtual Ethernet Segment EVPN Virtual Ethernet Segment
draft-ietf-bess-evpn-virtual-eth-segment-02 draft-ietf-bess-evpn-virtual-eth-segment-03
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 Ethernet services over MPLS/IP network with many advanced features
capabilities among which their multi-homing capabilities. These among which their multi-homing capabilities. These solutions define
solutions define two types of multi-homing for an Ethernet Segment two types of multi-homing for an Ethernet Segment (ES): 1) Single-
(ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment Active and 2) All-Active, where an Ethernet Segment is defined as a
is defined as a set of links between the multi-homed device/network set of links between the multi-homed device/network and the set of PE
and the set of PE devices that they are connected to. devices that they are connected to.
Some Service Providers want to extend the concept of the physical Some Service Providers want to extend the concept of the physical
links in an ES to Ethernet Virtual Circuits (EVCs) where many of such links in an ES to Ethernet Virtual Circuits (EVCs) where many of such
EVCs can be aggregated on a single physical External Network-to- EVCs can be aggregated on a single physical External Network-to-
Network Interface (ENNI). An ES that consists of a set of EVCs Network Interface (ENNI). An ES that consists of a set of EVCs
instead of physical links is referred to as a virtual ES (vES). This instead of physical links is referred to as a virtual ES (vES). This
draft describes the requirements and the extensions needed to support draft describes the requirements and the extensions needed to support
vES in EVPN and PBB-EVPN. vES in EVPN and PBB-EVPN.
Status of this Memo Status of this Memo
skipping to change at page 2, line 28 skipping to change at page 2, line 28
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Conventions Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Virtual Ethernet Segments in Access Ethernet Networks . . . 4 1.1 Virtual Ethernet Segments in Access Ethernet Networks . . . 4
1.2 Virtual Ethernet Segments in Access MPLS Networks . . . . . 5 1.2 Virtual Ethernet Segments in Access MPLS Networks . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Single-Homed & Multi-Homed Virtual Ethernet Segments . . . 8 3.1. Single-Homed & Multi-Homed Virtual Ethernet Segments . . . 8
3.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Local Switching . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Local Switching . . . . . . . . . . . . . . . . . . . . . . 9
3.4. EVC Service Types . . . . . . . . . . . . . . . . . . . . . 9 3.4. EVC Service Types . . . . . . . . . . . . . . . . . . . . . 9
3.5. Designated Forwarder (DF) Election . . . . . . . . . . . . 10 3.5. Designated Forwarder (DF) Election . . . . . . . . . . . . 10
3.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Failure & Recovery . . . . . . . . . . . . . . . . . . . . 10 3.7. Failure & Recovery . . . . . . . . . . . . . . . . . . . . 11
3.8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . 11 3.8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . 11
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. EVPN DF Election for vES . . . . . . . . . . . . . . . . . 13 4.1. EVPN DF Election for vES . . . . . . . . . . . . . . . . . 13
5. Failure Handling & Recovery . . . . . . . . . . . . . . . . . . 14 5. Failure Handling & Recovery . . . . . . . . . . . . . . . . . . 14
5.1. Failure Handling for Single-Active vES in EVPN . . . . . . 15 5.1. Failure Handling for Single-Active vES in EVPN . . . . . . 15
5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . . 16 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . . 16
5.3. Port Failure Handling for Single-Active vES's in EVPN . . . 17 5.3. Port Failure Handling for Single-Active vES's in EVPN . . . 17
5.4. Port Failure Handling for Single-Active vES's in PBB-EVPN . 17 5.4. Port Failure Handling for Single-Active vES's in PBB-EVPN . 18
5.5. Fast Convergence in PBB-EVPN . . . . . . . . . . . . . . . 18 5.5. Fast Convergence in PBB-EVPN . . . . . . . . . . . . . . . 18
6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. I-SID Extended Community . . . . . . . . . . . . . . . . . 21 6.1. I-SID Extended Community . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
10. Intellectual Property Considerations . . . . . . . . . . . . . 22 10. Intellectual Property Considerations . . . . . . . . . . . . . 22
11. Normative References . . . . . . . . . . . . . . . . . . . . . 22 11. Normative References . . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . . 22 12. Informative References . . . . . . . . . . . . . . . . . . . . 22
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 13. 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
capabilities among which their multi-homing capabilities. These features among which their multi-homing capabilities. These solutions
solutions define two types of multi-homing for an Ethernet Segment define two types of multi-homing for an Ethernet Segment (ES): 1)
(ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment Single-Active and 2) All-Active, where an Ethernet Segment is defined
is defined as a set of links between the multi-homed device/network as a set of links between the multi-homed device/network and the set
and the set of PE devices that they are connected to. 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
be associated to a set of EVCs (e.g., VLANs) or other objects such as be associated to a set of EVCs (e.g., VLANs) or other objects such as
MPLS Label Switch Paths (LSPs) or Pseudowires (PWs). MPLS Label Switch Paths (LSPs) or Pseudowires (PWs).
1.1 Virtual Ethernet Segments in Access Ethernet Networks 1.1 Virtual Ethernet Segments in Access Ethernet Networks
Some Service Providers (SPs) want to extend the concept of the Some Service Providers (SPs) want to extend the concept of the
physical links in an ES to Ethernet Virtual Circuits (EVCs) where physical links in an ES to Ethernet Virtual Circuits (EVCs) where
many of such EVCs (e.g., VLANs) can be aggregated on a single many of such EVCs (e.g., VLANs) can be aggregated on a single
skipping to change at page 5, line 33 skipping to change at page 5, line 33
Cust. C +---------+ /\ Cust. C +---------+ /\
/\ || /\ ||
|| ENNI || ENNI
EVCs Interface EVCs Interface
<--------802.1Q----------> <-802.1Q-> <--------802.1Q----------> <-802.1Q->
Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI
E-NNIs are commonly used to reach off-network / out-of-franchise E-NNIs are commonly used to reach off-network / out-of-franchise
customer sites via independent Ethernet access networks or third- customer sites via independent Ethernet access networks or third-
party Ethernet Access Providers (EAP) (see above figure). E-NNIs can party Ethernet Access Providers (EAP) (see Figure 1). E-NNIs can
aggregate traffic from hundreds to thousands of vES's; where, each aggregate traffic from hundreds to thousands of vES's; where, each
vES is represented by its associated EVC on that ENNI. As a result, vES is represented by its associated EVC on that ENNI. As a result,
ENNIs and their associated EVCs are a key element of SP off-networks ENNIs and their associated EVCs are a key element of SP off-networks
that are carefully designed and closely monitored. that are carefully designed and closely monitored.
In order to meet customer's Service Level Agreements (SLA), SPs build In order to meet customer's Service Level Agreements (SLA), SPs build
redundancy via multiple E-PEs / ENNIs (as shown in figure above) redundancy via multiple EVPN PEs and across multiple ENNIs (as shown
where a given vES can be multi-homed to two or more PE devices (on in Figure 1) where a given vES can be multi-homed to two or more EVPN
two or more ENNIs) via their associated EVCs. Just like physical ES's PE devices (on two or more ENNIs) via their associated EVCs. Just
in [RFC7432] and [RFC7623] solutions, these vES's can be single-homed like physical ES's in [RFC7432] and [RFC7623] solutions, these vES's
or multi-homed ES's and when multi-homed, then can operate in either can be single-homed or multi-homed ES's and when multi-homed, then
Single-Active or All-Active redundancy modes. In a typical SP off- can operate in either Single-Active or All-Active redundancy modes.
network scenario, an ENNI can be associated with several thousands of In a typical SP off-network scenario, an ENNI can be associated with
single-homed vES's, several hundreds of Single-Active vES's and it several thousands of single-homed vES's, several hundreds of Single-
may also be associated with tens or hundreds of All-Active vES's. Active vES's and it may also be associated with tens or hundreds of
All-Active vES's.
1.2 Virtual Ethernet Segments in Access MPLS Networks 1.2 Virtual Ethernet Segments in Access MPLS Networks
Other Service Providers (SPs) want to extend the concept of the Other Service Providers (SPs) want to extend the concept of the
physical links in an ES to individual Pseudowires (PWs) or to MPLS physical links in an ES to individual Pseudowires (PWs) or to MPLS
Label Switched Paths (LSPs) per [EVPN-VPWS] in Access MPLS networks. Label Switched Paths (LSPs) in Access MPLS networks. Figure 2
Figure 2 illustrates this concept. illustrates this concept.
MPLS Aggregation MPLS Aggregation
Network Network
+-----+ +----------------+ <---- EVPN Network -----> +-----+ +----------------+ <---- EVPN Network ----->
| CE11|EVC1 | | | CE11|EVC1 | |
+-----+ \+AG1--+ PW1 +-----+ +-----+ \+AG1--+ PW1 +-----+
Cust. A -0----|===========| | Cust. A -0----|===========| |
+-----+ | ---+===========| | +-------+ +---+ +-----+ | ---+===========| | +-------+ +---+
| CE12|EVC2-0/ | PW2 /\ | PE1 +---+ | | | | CE12|EVC2-0/ | PW2 /\ | PE1 +---+ | | |
+-----+ ++---+ ==||=| | | +---+PE3+- +-----+ ++---+ ==||=| | | +---+PE3+-
skipping to change at page 7, line 25 skipping to change at page 7, line 25
For MPLS/IP access networks where a vES represents a set of PWs or For MPLS/IP access networks where a vES represents a set of PWs or
LSPs, this document extended Single-Active multi-homing procedures of LSPs, this document extended Single-Active multi-homing procedures of
[RFC7432] and [7623] to vES. The vES extension to All-Active multi- [RFC7432] and [7623] to vES. The vES extension to All-Active multi-
homing is outside of the scope of this document for MPLS/IP access homing is outside of the scope of this document for MPLS/IP access
networks. networks.
This draft describes requirements and the extensions needed to This draft describes requirements and the extensions needed to
support vES in [RFC7432] and [RFC7623]. Section 3 lists the set of support vES in [RFC7432] and [RFC7623]. Section 3 lists the set of
requirements for virtual ES's. Section 4 describes the solution for requirements for virtual ES's. Section 4 describes the solution for
[RFC7432] and [RFC7623] to meet these requirements. Section 5 [RFC7432], [RFC7623], and [RFC8214] to meet these requirements.
describes the failure handling and recovery for Virtual ES's in Section 5 describes the failure handling and recovery for Virtual
[RFC7432] and [RFC7623]. Section 6 covers scalability and fast ES's in [RFC7432] and [RFC7623]. Section 6 covers scalability and
convergence required for Virtual ES's in [RFC7432] and [RFC7623]. fast convergence required for Virtual ES's in [RFC7432] and
[RFC7623].
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
CFM: Connectivity Fault Management CFM: Connectivity Fault Management
C-MAC: Customer/Client MAC Address C-MAC: Customer/Client MAC Address
DHD: Dual-homed Device DHD: Dual-homed Device
DHN: Dual-homed Network DHN: Dual-homed Network
ENNI: External Network-Network Interface ENNI: External Network-Network Interface
ES: Ethernet Segment ES: Ethernet Segment
ESI: Ethernet-Segment Identifier ESI: Ethernet-Segment Identifier
EVC: Ethernet Virtual Circuit EVC: Ethernet Virtual Circuit
EVPN: Ethernet VPN EVPN: Ethernet VPN
I-SID: Service Instance Identifier (24 bits and global within a PBB I-SID: Service Instance Identifier (24 bits and global within a PBB
network see [RFC7080]) network see [RFC7080])
LACP: Link Aggregation Control Protocol LACP: Link Aggregation Control Protocol
PBB: Provider Backbone Bridge PBB: Provider Backbone Bridge
PBB-EVPN: Provider Backbone Bridge EVPN
PE: Provider Edge PE: Provider Edge
SH: Single-Homed SH: Single-Homed
Single-Active Redundancy Mode (SA): When only a single PE, among a Single-Active Redundancy Mode (SA): When only a single PE, among a
group of PEs attached to an Ethernet-Segment, is allowed to forward group of PEs attached to an Ethernet-Segment, is allowed to forward
traffic to/from that Ethernet Segment, then the Ethernet segment is traffic to/from that Ethernet Segment, then the Ethernet segment is
defined to be operating in Single-Active redundancy mode. defined to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode (AA): When all PEs attached to an Ethernet All-Active Redundancy Mode (AA): When all PEs attached to an Ethernet
segment are allowed to forward traffic to/from that Ethernet-Segment, segment are allowed to forward traffic to/from that Ethernet-Segment,
then the Ethernet segment is defined to be operating in All-Active then the Ethernet segment is defined to be operating in All-Active
redundancy mode. redundancy mode.
skipping to change at page 8, line 18 skipping to change at page 8, line 21
All-Active Redundancy Mode (AA): When all PEs attached to an Ethernet All-Active Redundancy Mode (AA): When all PEs attached to an Ethernet
segment are allowed to forward traffic to/from that Ethernet-Segment, segment are allowed to forward traffic to/from that Ethernet-Segment,
then the Ethernet segment is defined to be operating in All-Active then the Ethernet segment is defined to be operating in All-Active
redundancy mode. redundancy mode.
3. Requirements 3. Requirements
This section describes the requirements specific to virtual Ethernet This section describes the requirements specific to virtual Ethernet
Segment (vES) for (PBB-)EVPN solutions. These requirements are in Segment (vES) for (PBB-)EVPN solutions. These requirements are in
addition to the ones described in [EVPN-REQ], [RFC7432], and addition to the ones described in [RFC7209], [RFC7432], and
[RFC7623]. [RFC7623].
3.1. Single-Homed & Multi-Homed Virtual Ethernet Segments 3.1. Single-Homed & Multi-Homed Virtual Ethernet Segments
A PE needs to support the following types of vES's: A PE needs to support the following types of vES's:
(R1a) A PE MUST handle single-homed vES's on a single physical port (R1a) A PE MUST handle single-homed vES's on a single physical port
(e.g., single ENNI) (e.g., single ENNI)
(R1b) A PE MUST handle a mix of Single-Homed vES's and Single-Active (R1b) A PE MUST handle a mix of Single-Homed vES's and Single-Active
skipping to change at page 9, line 29 skipping to change at page 9, line 32
3.3. Local Switching 3.3. Local Switching
Many vES's of different types can be aggregated on a single physical Many vES's of different types can be aggregated on a single physical
port on a PE device and some of these vES can belong to the same port on a PE device and some of these vES can belong to the same
service instance (or customer). This translates into the need for service instance (or customer). This translates into the need for
supporting local switching among the vES's of the same service supporting local switching among the vES's of the same service
instance on the same physical port (e.g., ENNI) of the PE. instance on the same physical port (e.g., ENNI) of the PE.
(R3a) A PE MUST support local switching among different vES's (R3a) A PE MUST support local switching among different vES's
belonging to the same service instance (or customer) on a single belonging to the same service instance (or customer) on a single
physical port. For example, in the above Figure 1, PE1 MUST support physical port. For example, in Figure 1, PE1 MUST support local
local switching between CE11 and CE12 (both belonging to customer A) switching between CE11 and CE12 (both belonging to customer A) that
that are mapped to two Single-homed vES's on ENNI1. are mapped to two Single-homed vES's on ENNI1.
In case of Single-Active vES's, the local switching is performed In case of Single-Active vES's, the local switching is performed
among active EVCs belonging to the same service instance on the same among active EVCs belonging to the same service instance on the same
ENNI. ENNI.
3.4. EVC Service Types 3.4. EVC Service Types
A physical port (e.g., ENNI) of a PE can aggregate many EVCs each of A physical port (e.g., ENNI) of a PE can aggregate many EVCs each of
which is associated with a vES. Furthermore, an EVC may carry one or which is associated with a vES. Furthermore, an EVC may carry one or
more VLANs. Typically, an EVC carries a single VLAN and thus it is more VLANs. Typically, an EVC carries a single VLAN and thus it is
associated with a single broadcast domain. However, there is no associated with a single broadcast domain. However, there is no
restriction on an EVC to carry more than one VLANs. restriction on an EVC to carry more than one VLAN.
(R4a) An EVC can be associated with a single broadcast domain - e.g., (R4a) An EVC can be associated with a single broadcast domain - e.g.,
VLAN-based service or VLAN bundle service VLAN-based service or VLAN bundle service
(R4b) An EVC MAY be associated with several broadcast domains - e.g., (R4b) An EVC MAY be associated with several broadcast domains - e.g.,
VLAN-aware bundle service VLAN-aware bundle service
In the same way, a PE can aggregated many LSPs and PWs. In the case In the same way, a PE can aggregate many LSPs and PWs. In the case of
of individual PWs per vES, typically a PW is associated with a single individual PWs per vES, typically a PW is associated with a single
broadcast domain, but there is no restriction on the PW to carry more broadcast domain, but there is no restriction on the PW to carry more
than one VLAN if the PW is defined as vc-type VLAN. than one VLAN if the PW is defined as vc-type VLAN.
(R4c) A PW can be associated with a single broadcast domain - e.g., (R4c) A PW can be associated with a single broadcast domain - e.g.,
VLAN-based service or VLAN bundle service. VLAN-based service or VLAN bundle service.
(R4b) An PW MAY be associated with several broadcast domains - e.g., (R4d) An PW MAY be associated with several broadcast domains - e.g.,
VLAN-aware bundle service." VLAN-aware bundle service."
3.5. Designated Forwarder (DF) Election 3.5. Designated Forwarder (DF) Election
Section 8.5 of [RFC7432] describes the default procedure for DF Section 8.5 of [RFC7432] describes the default procedure for DF
election in EVPN which is also used in [RFC7623]. This default DF election in EVPN which is also used in [RFC7623] and [RFC8214]. This
election procedure is performed at the granularity of <ESI, EVI>. In default DF election procedure is performed at the granularity of
case of a vES, the same EVPN default procedure for DF election also <ESI, Ethernet Tag>. In case of a vES, the same EVPN default
applies; however, at the granularity of <vESI, EVI>; where vESI is procedure for DF election also applies; however, at the granularity
the virtual Ethernet Segment Identifier. As in [RFC7432], this of <vESI, Ethernet Tag>; where vESI is the virtual Ethernet Segment
default procedure for DF election at the granularity of <vESI, EVI> Identifier. As in [RFC7432], this default procedure for DF election
is also referred to as "service carving"; where, EVI is represented at the granularity of <vESI, Ethernet Tag> is also referred to as
by an I-SID in PBB-EVPN and by a EVI service-id/vpn-id in EVPN. With "service carving"; where, Ethernet Tag is represented by an I-SID in
service carving, it is possible to evenly distribute the DFs for PBB-EVPN and by a VLAN ID (VID) in EVPN. With service carving, it is
different vES's among different PEs, thus distributing the traffic possible to evenly distribute the DFs for different vES's among
among different PEs. The following list the requirements apply to DF different PEs, thus distributing the traffic among different PEs. The
election of vES's for EVPN. following list the requirements apply to DF election of vES's for
EVPN.
(R5a) A vES with m EVCs can be distributed among n ENNIs belonging to (R5a) A vES with m EVCs can be distributed among n ENNIs belonging to
p PEs in any arbitrary oder; where n >= P >= m. For example, if there p PEs in any arbitrary oder; where n >= p >= m. For example, if there
is an vES with 2 EVCs and there are 5 ENNIs on 5 PEs (PE1 through is an vES with 2 EVCs and there are 5 ENNIs on 5 PEs (PE1 through
PE5), then vES can be dual-homed to PE2 and PE4 and the DF election PE5), then vES can be dual-homed to PE2 and PE4 and the DF election
must be performed between PE2 and PE4. must be performed between PE2 and PE4.
(R5b) Each vES MUST be identified by its own virtual ESI (vESI) (R5b) Each vES MUST be identified by its own virtual ESI (vESI)
3.6. OAM 3.6. OAM
In order to detect the failure of individual EVC and perform DF In order to detect the failure of individual EVC and perform DF
election for its associated vES as the result of this failure, each election for its associated vES as the result of this failure, each
skipping to change at page 12, line 5 skipping to change at page 12, line 8
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 one simple modification and that is the ESI assignment is is with one simple modification and that is the ESI assignment is
performed for a group of EVCs or LSPs/PWs instead of a group of performed for a group of EVCs or LSPs/PWs instead of a group of
links. In other words, the ESI is associated with a virtual ES (vES) links. In other words, the ESI is associated with a virtual ES (vES)
and that's why it will be referred to as vESI. and that's why it will be referred to as vESI.
For EVPN solution, everything basically remains the same except for For the EVPN solution, everything basically remains the same except
the handling of physical port failure where many vES's can be for the handling of physical port failure where many vES's can be
impacted. Section 5.1 and 5.3 below describe the handling of physical impacted. Section 5.1 and 5.3 below describe the handling of physical
port/link failure for EVPN. In a typical multi-homed operation, MAC port/link failure for EVPN. In a typical multi-homed operation, MAC
addresses are learned behind a vES are advertised with the ESI addresses are learned behind a vES are advertised with the ESI
corresponding to the vES (i.e., vESI). EVPN aliasing and mass- corresponding to the vES (i.e., vESI). EVPN aliasing and mass-
withdraw operations are performed with respect to vES. In other withdraw operations are performed with respect to vES. In other
words, the Ethernet A-D routes for these operations are advertised words, the Ethernet A-D routes for these operations are advertised
with vESI instead of ESI. 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
skipping to change at page 13, line 50 skipping to change at page 13, line 50
3. When the timer expires, each PE builds an ordered list of the IP 3. When the timer expires, each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the vES (including addresses of all the PE nodes connected to the vES (including
itself), in increasing numeric value. Each IP address in this list is itself), in increasing numeric value. Each IP address in this list is
extracted from the "Originator Router's IP address" field of the extracted from the "Originator Router's IP address" field of the
advertised Ethernet Segment route. Every PE is then given an ordinal advertised Ethernet Segment route. Every PE is then given an ordinal
indicating its position in the ordered list, starting with 0 as the indicating its position in the ordered list, starting with 0 as the
ordinal for the PE with the numerically lowest IP address. The ordinal for the PE with the numerically lowest IP address. The
ordinals are used to determine which PE node will be the DF for a ordinals are used to determine which PE node will be the DF for a
given EVPN instance on the vES using the following rule: Assuming a given EVPN instance on the vES using the following rule: Assuming a
redundancy group of N PE nodes, the PE with ordinal i is the DF for redundancy group of N PE nodes, the PE with ordinal i is the DF for
an EVPN instance with an associated EVI ID value of V when (V mod N) an EVPN instance with an associated Ethernet Tag value of V when (V
= i. mod N) = i.
It should be noted that using "Originator Router's IP address" field It should be noted that using "Originator Router's IP address" field
in the Ethernet Segment route to get the PE IP address needed for the in the Ethernet Segment route to get the PE IP address needed for the
ordered list, allows for a CE to be multi-homed across different ASes ordered list, allows for a CE to be multi-homed across different ASes
if such need ever arises. if such need ever arises.
4. The PE that is elected as a DF for a given EVPN instance will 4. The PE that is elected as a DF for a given EVPN instance will
unblock traffic for that EVPN instance. Note that the DF PE unblocks unblock traffic for that EVPN instance. Note that the DF PE unblocks
all traffic in both ingress and egress directions for Single-Active all traffic in both ingress and egress directions for Single-Active
vES and unblocks multi-destination in egress direction for All-Active vES and unblocks multi-destination in egress direction for All-Active
Multi-homed vES. All non-DF PEs block all traffic in both ingress and Multi-homed vES. All non-DF PEs block all traffic in both ingress and
egress directions for Single-Active vES and block multi-destination egress directions for Single-Active vES and block multi-destination
traffic in the egress direction for All-Active multi-homed vES. traffic in the egress direction for All-Active multi-homed vES.
In the case of an EVC failure, the affected PE withdraws its Ethernet In the case of an EVC failure, the affected PE withdraws its Ethernet
Segment route. This will re-trigger the service carving procedures on Segment route if there are no more EVCs associated to the vES in the
all the PEs in the RG. For PE node failure, or upon PE commissioning PE. This will re-trigger the DF Election procedure on all the PEs in
or decommissioning, the PEs re-trigger the service carving across all the RG. For PE node failure, or upon PE commissioning or
affected vES's. In case of a Single-Active multi-homing, when a decommissioning, the PEs re-trigger the DF Election Procedure across
all affected vES's. In case of a Single-Active multi-homing, when a
service moves from one PE in the Redundancy Group to another PE as a service moves from one PE in the Redundancy Group to another PE as a
result of re-carving, the PE, which ends up being the elected DF for result of DF re-election, the PE, which ends up being the elected DF
the service, SHOULD trigger a MAC address flush notification towards for the service, SHOULD trigger a MAC address flush notification
the associated vES. This can be done, for e.g. using IEEE 802.1ak towards the associated vES. This can be done, for e.g. using IEEE
MVRP 'new' declaration. 802.1ak MVRP 'new' declaration.
For LSP and PW based vES, the non-DF PE SHOULD signal PW-status For LSP and PW based vES, the non-DF PE SHOULD signal PW-status
'standby' signaling to the AG PE, and the new DF MAY send an LDP MAC 'standby' signaling to the AG PE, and the new DF MAY send an LDP MAC
withdraw message as a MAC address flush notification. It should be withdraw message as a MAC address flush notification. It should be
noted that the PW-status is signaled for the scenarios where there is noted that the PW-status is signaled for the scenarios where there is
a one-to-one mapping between EVI and the PW. a one-to-one mapping between EVI/BD and the PW.
5. Failure Handling & Recovery 5. Failure Handling & Recovery
There are a number of failure scenarios to consider such as: There are a number of failure scenarios to consider such as:
A: CE Uplink Port Failure A: CE Uplink Port Failure
B: Ethernet Access Network Failure B: Ethernet Access Network Failure
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] and [RFC7623] solutions provide protection against such [RFC7432], [RFC7623], and [RFC8214] solutions provide protection
failures as described in the corresponding references. In the against such failures as described in the corresponding references.
presence of virtual Ethernet Segments (vES's) in these solutions, In the presence of virtual Ethernet Segments (vES's) in these
besides the above failure scenarios, there is one more scenario to solutions, besides the above failure scenarios, there is one more
consider and that is EVC failure. This implies that individual EVCs scenario to consider and that is EVC failure. This implies that
need to be monitored and upon their failure detection, appropriate DF individual EVCs need to be monitored and upon their failure
election procedures and failure recovery mechanism need to be detection, appropriate DF election procedures and failure recovery
executed. mechanism need to be 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 addition extensions are needed to failure handling 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 describe in the next section. requirements. These extensions are describe in the next section.
[MPLS-OAM] and [PW-OAM] are used for monitoring the status of LSPs [MPLS-OAM] and [PW-OAM] are used for monitoring the status of LSPs
and/or PWs associated to vES. and/or PWs associated to vES.
B D B D
|| || || ||
\/ \/ \/ \/
+-----+ +-----+
skipping to change at page 16, line 32 skipping to change at page 16, line 34
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 BGP flush message is sent along with a list of impacted
I-SID(s) represented by the new EVPN I-SID Extended Community as I-SID(s) represented by the new EVPN I-SID Extended Community as
defined in section 6. Since typically an EVC maps to a single defined in section 6. Since typically an EVC maps to a single
broadcast domain and thus a single service instance, the list only broadcast domain and thus a single service instance, the list only
contains a single I-SID. However, if the failed EVC carries multiple contains a single I-SID. However, if the failed EVC carries multiple
VLANs each with its own broadcast domain, then the list contains VLANs each with its own broadcast domain, then the list contains
several I-SIDs - one for each broadcast domain. This new BGP flush several I-SIDs - one for each broadcast domain. This new BGP flush
message basically instructs the remote PE to perform flushing for message basically instructs the remote PE to perform flushing for
CMACs corresponding to the advertised BMAC only across the advertised CMACs corresponding to the advertised BMAC only across the advertised
list of I-ISIDs (which is typically one). list of I-ISIDs.
The new I-SID Extended Community provides a way to encode upto 24 I-
SIDs in each Extended Community if the impacted I-SIDs are sequential
(the base I-SID value plus the next 23 I-SID values). If the number
of I-SIDs associated with a failed EVC is large or if the affected I-
SIDs are not sequential, then multiple I-SID Extended Communities can
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 don't fit 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 30 seconds.
The I-SID dependent flushing mechanism described in this section is
backward compatible for the PEs only 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 above BMAC route that is advertised with the MAC Mobility
Extended Community, can either represent the MAC address of the Extended Community, can either represent the MAC address of the
physical port that the failed EVC is associated with, or it can physical port that the failed EVC is associated with, or it can
represent the MAC address of the PE. In the latter case, this is the represent the MAC address of the PE. In the latter case, this is the
dedicated MAC address used for all Single-Active vES's on that PE. dedicated per-PE MAC address used for all Single-Active vES's on that
The former one performs better than the latter one in terms of PE. The former one performs better than the latter one in terms of
reducing the scope of flushing as described below and thus it is the reducing the scope of flushing and thus it is the recommended
recommended approach. approach because only CMAC addresses for the impacted service
instances on the failed EVC are flushed.
Advertising the BMAC route that represent the physical port (e.g.,
ENNI) on which the failed EVC reside along with MAC Mobility and I-
SID extended communities provide the most optimum mechanism for CMAC
flushing upon EVC failure in PBB-EVPN for Single-Active vES because:
1) Only CMAC addresses for the impacted service instances are
flushed.
2) Only a subset of CMAC addresses for the impacted service
instances are flushed - only the ones that are learned over the BMAC
associated with the failed EVC. In other words, only a small fraction
of the CMACs for the impacted service instance(s) are flushed.
5.3. Port Failure Handling for Single-Active vES's in EVPN 5.3. Port Failure Handling for Single-Active vES's 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 vES's. If the impacts all the associated EVCs and their corresponding vES's. If the
number of EVCs corresponding to the Single-Active vES's for that number of EVCs corresponding to the Single-Active vES's 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) A PE when advertises an Ether-AD per ES route for a given vES, it 1) When a PE advertises an Ether-AD per ES route for a given vES, it
colors it with the MAC address of the physical port which is colors it with the MAC address of the physical port which is
associated with that vES. The receiving PEs take note of this color associated with that vES using EVPN Router's MAC Extended Community
and create a list of vES's for this color. per [EVPN-IRB]. The receiving PEs take note of this color and create
a list of vES's 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 port 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 this (i.e., the color of the port) encoded in the ESI field. For this
encoding, type 3 ESI is used with the MAC field set to the MAC encoding, type 3 ESI is used with the MAC field set to the MAC
address of the port and the 3-octet local discriminator field set to address of the port and the 3-octet local discriminator field set to
0xFFFFFF. This mass-withdraw route is advertised with a list of Route 0xFFFFFF. This mass-withdraw route is advertised with a list of Route
Targets corresponding to the impacted service instances. If the Targets corresponding to the impacted service instances. If the
number of Route Targets is more than they can fit into a single number of Route Targets is more than they can fit into a single
attribute, then a set of Ethernet A-D per ES routes are advertised. attribute, then a set of Ethernet A-D per ES routes are advertised.
skipping to change at page 17, line 44 skipping to change at page 18, line 26
for the specified color. Next, they initiate mass-withdraw procedure for the specified color. Next, they initiate mass-withdraw procedure
for each of the vES's in the list. for each of the vES's in the list.
5.4. Port Failure Handling for Single-Active vES's in PBB-EVPN 5.4. Port Failure Handling for Single-Active vES's in PBB-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 vES's. If the impacts all the associated EVCs and their corresponding vES's. If the
number of EVCs corresponding to the Single-Active vES's for that number of EVCs corresponding to the Single-Active vES's for that
physical port is in thousands, then thousands of service instances physical port is in thousands, then thousands of service instances
(I-SIDs) are impacted. Therefore, the BGP flush message need to be (I-SIDs) are impacted. In such failure scenarios, the following two
sent with a list of thousands of I-SIDs. The new I-SID Extended MAC flushing mechanisms per [RFC7623] can be performed.
Community provides a way to encode upto 24 I-SIDs in each Extended
Community if the impacted I-SIDs are sequential (the base I-SID value
plus the next 23 I-SID values). So, the packing efficiency can range
from 1 to 24 and there can be up to 400 such Extended Community sent
along with a BGP flush message for a total of 400 to 9600 I-SIDs. If
the number of I-SIDs is large enough to not fit in a single
Attribute, then either a number of BGP flush messages (with different
RDs) can be transmitted or a single BGP flush message without the I-
SID list can be transmitted. If 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. For simplicity, we
opt for the latter option in this document. In other words, if the
number of impacted I-SIDs exceed that of a single BGP flush message,
then the flush message is sent without the I-SID list.
As also described in [RFC7623], there are two ways to signal flush
message upon a physical port failure:
1) If the MAC address of the physical port is used for PBB 1) If the MAC address of the physical port is used for PBB
encapsulation as BMAC SA, then upon the port failure, the PE MUST use encapsulation as BMAC SA, then upon the port failure, the PE MUST use
the EVPN MAC route withdrawal message to signal the flush the EVPN MAC route withdrawal message to signal the flush
2) If the PE shared MAC address is used for PBB encapsulation as BMAC 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 this MAC SA, then upon the port failure, the PE MUST re-advertise this MAC
route with the MAC Mobility Extended Community to signal the flush route with the MAC Mobility Extended Community to signal the flush
The first method is recommended because it reduces the scope of The first method is recommended because it reduces the scope of
skipping to change at page 19, line 9 skipping to change at page 19, line 18
(which can be in thousands) among the participating PEs via a single (which can be in thousands) among the participating PEs via a single
BGP message as opposed to sending thousands of BGP messages - one per BGP message as opposed to sending thousands of BGP messages - one per
vES. vES.
In order to devise such fast convergence mechanism that can be In order to devise such fast convergence mechanism that can be
triggered via a single BGP message, all vES's associated with a given triggered via a single BGP message, all vES's associated with a given
physical port (e.g., ENNI) are colored with the same color physical port (e.g., ENNI) are colored with the same color
representing that physical port. The MAC address of the physical port representing that physical port. The MAC address of the physical port
is used for this coloring purposes and when the PE advertises an ES 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 route for a vES associated with that physical port, it advertises it
with an EVPN MAC Extended Community indicating the color of that with an EVPN Router's MAC Extended Community indicating the color of
port. that port.
The receiving PEs take note of this color and for each such color, The receiving PEs take note of this color and for each such color,
they create a list of vES's associated with this color (with this MAC they create a list of vES's associated with this color (with this MAC
address). Now, when a port failure occurs, the impacted PE needs to 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 notify the other PEs of this color so that these PEs can identify all
the impacted vES's associated with that color (from the above list) the impacted vES's associated with that color (from the above list)
and re-execute DF election procedures for all the impacted vES's. and re-execute DF election procedures for all the impacted vES's.
In PBB-EVPN, there are two ways to convey this color to other PEs In PBB-EVPN, there are two ways to convey this color to other PEs
upon a port failure - one corresponding to each method for signaling upon a port failure - one corresponding to each method for signaling
flush message as described in section 5.4. If for PBB encapsulation, flush message as described in section 5.4. If for PBB encapsulation,
the MAC address of the physical port is used as BMAC SA, then upon the MAC address of the physical port is used as BMAC SA, then upon
the port failure, the PE sends MAC withdrawal message with the MAC the port failure, the PE sends MAC withdrawal message with the MAC
address of the failed port as the color. However, if for PBB address of the failed port as the color. However, if for PBB
encapsulation, the shared MAC address of the PE (dedicated for all encapsulation, the shared MAC address of the PE (dedicated for all
Single-Active vES's) is used as BMAC SA, then upon the port failure, Single-Active vES's) is used as BMAC SA, then upon the port failure,
the PE re-advertises the MAC route (that carries the shared BMAC) the PE re-advertises the MAC route (that carries the shared BMAC)
along with this new EVPN MAC Extended Community to indicate the color along with this new EVPN Router's MAC Extended Community to indicate
along with MAC Mobility Extended Community. the color along with MAC Mobility Extended Community.
+-----+ +-----+
+----+ | | +---+ +----+ | | +---+
| 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 20, line 38 skipping to change at page 20, line 38
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), the 3- Upon the occurrence of a port failure (e.g., an ENNI failure), the
PE sends the flush message in one of the two ways described above PE sends the flush message in one of the two ways described above
indicating this color. indicating this color. The PE should prioritize sending this flush
message over ES route withdrawal messages of impacted vES's.
4- On reception of the flush message, other PEs use this info to 4- On reception of the flush message, other PEs use this info to
flush their impacted CMACs and to initiate DF election procedures flush their impacted CMACs and to initiate DF election procedures
across all their affected vES's. across all their affected vES's.
5- The PE with the physical port failure (ENNI failure), also send ES 5- The PE with the physical port failure (ENNI failure), also sends
route withdrawal for every impacted vES's. The other PEs upon ES route withdrawal for every impacted vES's. The other PEs upon
receiving these messages, clear up their BGP tables. It should be receiving these messages, clear up their BGP tables. It should be
noted the ES route withdrawal messages are not used for executing DF noted the ES route withdrawal messages are not used for executing DF
election procedures by the receiving PEs. election procedures by the receiving PEs.
6. BGP Encoding 6. BGP Encoding
This document defines one new BGP Extended Community for EVPN. This document defines one new BGP Extended Community for EVPN.
6.1. I-SID Extended Community 6.1. I-SID Extended Community
A new EVPN BGP Extended Community called I-SID is introduced. This A new EVPN BGP Extended Community called I-SID is introduced. This
new extended community is a transitive extended community with the new extended community is a transitive extended community with the
Type field of 0x06 (EVPN) and the Sub-Type of 0x07. Type field of 0x06 (EVPN) and the Sub-Type of 0x07.
The I-SID Extended Community is encoded as an 8-octet value as The I-SID Extended Community is encoded as an 8-octet value as
follows: follows:
0 1 2 3 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 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=0x03 | Base I-SID | | Type=0x06 | Sub-Type=0x07 | Base I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. | Bit Map (24 bits) | | Cont. | Bit Map (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: I-SID Extended Community Figure 6: I-SID Extended Community
This extended community is used to indicate the list of I-SIDs This extended community is used to indicate the list of I-SIDs
associated with a given Ethernet Segment. associated with a given Ethernet Segment.
24-bit map represents the next 24 I-SID after the base I-SID. For 24-bit map represents the next 24 I-SID after the base I-SID. For
skipping to change at page 22, line 21 skipping to change at page 22, line 21
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 10. 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. Normative References 11. Normative References
[PBB] Clauses 25 and 26 of "IEEE Standard for Local and metropolitan [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
area networks - Media Access Control (MAC) Bridges and Requirement Levels", BCP 14, RFC 2119, March 1997.
Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
2013. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC7432] Sajassi, et al., "BGP MPLS-Based Ethernet VPN", RFC 7432, [RFC7432] Sajassi, et al., "BGP MPLS-Based Ethernet VPN", RFC 7432,
February 2015. February 2015.
[RFC7623] Sajassi, et al., "Provider Backbone Bridging Combined with [RFC7623] Sajassi, et al., "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, September 2015. Ethernet VPN (PBB-EVPN)", RFC 7623, September 2015.
[RFC8214] Boutrus, et al., "Virtual Private Wire Service Support in
Ethernet VPN", RFC 8214, August 2017.
[EVPN-IRB] Sajassi, et al., "Integrated Routing and Bridging in
EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-05, July 2018.
12. Informative References 12. Informative References
[RFC7209] Sajassi, et al., "Requirements for Ethernet VPN (EVPN)", [RFC7209] Sajassi, et al., "Requirements for Ethernet VPN (EVPN)",
RFC 7209, May 2014. RFC 7209, May 2014.
[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, December 2013. Backbone Bridges", RFC 7080, December 2013.
13. Authors' Addresses 13. Authors' Addresses
skipping to change at page 23, line 4 skipping to change at page 23, line 9
13. Authors' Addresses 13. Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Systems Cisco Systems
Email: sajassi@cisco.com Email: sajassi@cisco.com
Patrice Brissette Patrice Brissette
Cisco Systems Cisco Systems
Email: pbrisset@cisco.com Email: pbrisset@cisco.com
Rick Schell Rick Schell
Verizon Verizon
Email: richard.schell@verizon.com Email: richard.schell@verizon.com
John E Drake John E Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
Tapraj Singh
Juniper
Email: tsingh@juniper.net
Jorge Rabadan Jorge Rabadan
ALU Nokia
Email: jorge.rabadan@alcatel-lucent.com Email: jorge.rabadan@nokia.com
 End of changes. 43 change blocks. 
132 lines changed or deleted 155 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/