draft-ietf-bess-evpn-virtual-eth-segment-00.txt   draft-ietf-bess-evpn-virtual-eth-segment-01.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: December 18, 2016 June 18, 2018 Expires: July 06, 2019 January 06, 2019
EVPN Virtual Ethernet Segment EVPN Virtual Ethernet Segment
draft-ietf-bess-evpn-virtual-eth-segment-00 draft-ietf-bess-evpn-virtual-eth-segment-01
Abstract
EVPN and PBB-EVPN introduce a family of solutions for multipoint
Ethernet services over MPLS/IP network with many advanced
capabilities among which their multi-homing capabilities. These
solutions define two types of multi-homing for an Ethernet Segment
(ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment
is defined as a set of links between the multi-homed device/network
and the set of PE devices that they are connected to.
Some Service Providers want to extend the concept of the physical
links in an ES to Ethernet Virtual Circuits (EVCs) where many of such
EVCs can be aggregated on a single physical External Network-to-
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
draft describes the requirements and the extensions needed to support
vES in EVPN and PBB-EVPN.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 9 skipping to change at page 2, line 25
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
EVPN and PBB-EVPN introduce a family of solutions for multipoint
Ethernet services over MPLS/IP network with many advanced
capabilities among which their multi-homing capabilities. These
solutions define two types of multi-homing for an Ethernet Segment
(ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment
is defined as a set of links between the multi-homed device/network
and the set of PE devices that they are connected to.
Some Service Providers want to extend the concept of the physical
links in an ES to Ethernet Virtual Circuits (EVCs) where many of such
EVCs can be aggregated on a single physical External Network-to-
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
draft describes the requirements and the extensions needed to support
vES in EVPN and PBB-EVPN.
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
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 . . . . . . . . . . . . . . . . . . . . 10
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 . . 15 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 . . . 16 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 . 17
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 . . . . . . . . . . . . . . . . . 20 6.1. I-SID Extended Community . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
10. Intellectual Property Considerations . . . . . . . . . . . . . 21 10. Intellectual Property Considerations . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . . 21 12. Informative References . . . . . . . . . . . . . . . . . . . . 22
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 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 capabilities among which their multi-homing capabilities. These
solutions define two types of multi-homing for an Ethernet Segment solutions define two types of multi-homing for an Ethernet Segment
(ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment
is defined as a set of links between the multi-homed device/network is defined as a set of links between the multi-homed device/network
and the set of PE devices that they are connected to. and the 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
be associated to a set of EVCs or other objects such as MPLS Label be associated to a set of EVCs (e.g., VLANs) or other objects such as
Switch Paths (LSP) or Pseudowires (PW). 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 can be aggregated on a single physical External many of such EVCs (e.g., VLANs) can be aggregated on a single
Network-to-Network Interface (ENNI). An ES that consists of a set of physical External Network-to-Network Interface (ENNI). An ES that
EVCs instead of physical links is referred to as a virtual ES (vES). consists of a set of EVCs instead of physical links is referred to as
Figure below depicts two PE devices (PE1 and PE2) each with an ENNI a virtual ES (vES). Figure below depicts two PE devices (PE1 and PE2)
where a number of vES's are aggregated on - each of which through its each with an ENNI where a number of vES's are aggregated on - each of
associated EVC. which through its associated EVC.
Carrier Carrier
Ethernet Ethernet
+-----+ Network +-----+ Network
| CE11|EVC1 +---------+ | CE11|EVC1 +---------+
+-----+ \ | | +---+ +-----+ \ | | +---+
Cust. A \-0=========0--ENNI1| | Cust. A \-0=========0--ENNI1| |
+-----+ | | ENNI1| | +-------+ +---+ +-----+ | | ENNI1| | +-------+ +---+
| CE12|EVC2--0=========0--ENNI1|PE1|---| | | | | CE12|EVC2--0=========0--ENNI1|PE1|---| | | |
+-----+ | | ENNI1| | | |---|PE3|- +-----+ | | ENNI1| | | |---|PE3|-
skipping to change at page 6, line 5 skipping to change at page 6, line 5
two or more ENNIs) via their associated EVCs. Just like physical ES's two or more ENNIs) via their associated EVCs. Just like physical ES's
in [RFC7432] and [RFC7623] solutions, these vES's can be single-homed in [RFC7432] and [RFC7623] solutions, these vES's can be single-homed
or multi-homed ES's and when multi-homed, then can operate in either or multi-homed ES's and when multi-homed, then can operate in either
Single-Active or All-Active redundancy modes. In a typical SP off- Single-Active or All-Active redundancy modes. In a typical SP off-
network scenario, an ENNI can be associated with several thousands of network scenario, an ENNI can be associated with several thousands of
single-homed vES's, several hundreds of Single-Active vES's and it single-homed vES's, several hundreds of Single-Active vES's and it
may also be associated with tens or hundreds of All-Active vES's. 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 (PW) 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) per [EVPN-VPWS] in Access MPLS networks.
Figure 2 illustrates this concept. Figure 2 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----|===========| |
+-----+ | ---+===========| | +-------+ +---+ +-----+ | ---+===========| | +-------+ +---+
skipping to change at page 6, line 40 skipping to change at page 6, line 40
EVCs EVCs
<--802.1Q---><------MPLS-------> <-802.1Q-> <--802.1Q---><------MPLS-------> <-802.1Q->
Figure 2: DHN and SH on Access MPLS networks Figure 2: DHN and SH on Access MPLS networks
In some cases, Service Providers use Access MPLS Networks that belong In some cases, Service Providers use Access MPLS Networks that belong
to separate administrative entities or third parties as a way to get to separate administrative entities or third parties as a way to get
access to the their own IP/MPLS network infrastructure. This is the access to the their own IP/MPLS network infrastructure. This is the
case illustrated in Figure 2. case illustrated in Figure 2.
An ES is defined as a set of individual PWs if they cannot be In such scenarios, a virtual ES (vES) is defined as a set of
aggregated into a common LSP. If the aggregation of PWs is possible, individual PWs if they cannot be aggregated into a common LSP. If the
the ES can be associated to an LSP in a given PE. In the example of aggregation of PWs is possible, the vES can be associated to an LSP
Figure 2, EVC3 is connected to a VPWS instance in AG2 that is in a given PE. In the example of Figure 2, EVC3 is connected to a
connected to PE1 and PE2 via PW3 and PW5 respectively. EVC4 is VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and PW5
connected to a separate VPWS instance on AG2 that gets connected to respectively. EVC4 is connected to a separate VPWS instance on AG2
an EVI on PE1 and PE2 via PW4 and PW6, respectively. Since the PWs that gets connected to an EVI on PE1 and PE2 via PW4 and PW6,
for the two VPWS instances can be aggregated into the same LSPs going respectively. Since the PWs for the two VPWS instances can be
to the EVPN network, a common virtual ES can be defined for LSP1 and aggregated into the same LSPs going to the EVPN network, a common
LSP2. This ES will be shared by two separate EVIs in the EVPN virtual ES can be defined for LSP1 and LSP2. This vES will be shared
network. by two separate EVIs in the EVPN network.
In some cases, this aggregation of PWs into common LSPs may not be In some cases, this aggregation of PWs into common LSPs may not be
possible. For instance, if PW3 were terminated into a third PE, e.g. possible. For instance, if PW3 were terminated into a third PE, e.g.
PE3, instead of PE1, the ES would need to be defined on a per PE3, instead of PE1, the vES would need to be defined on a per
individual PW on each PE, i.e. PW3 and PW5 would belong to ES-1, individual PW on each PE, i.e. PW3 and PW5 would belong to ES-1,
whereas PW4 and PW6 would be associated to ES-2. whereas PW4 and PW6 would be associated to ES-2.
An ES that consists of a set of LSPs or individual PWs is also For MPLS/IP access networks where a vES represents a set of PWs or
referred as virtual ES (vES) in this document." LSPs, this document extended Single-Active multi-homing procedures of
[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
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
[RFC7623] to meet these requirements. Section 5 describes the failure [RFC7432] and [RFC7623] to meet these requirements. Section 5
handling and recovery for Virtual ES's in [RFC7623]. Section 6 covers describes the failure handling and recovery for Virtual ES's in
scalability and fast convergence required for Virtual ES's in [RFC7432] and [RFC7623]. Section 6 covers scalability and fast
[RFC7623]. 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
network see [RFC7080])
LACP: Link Aggregation Control Protocol LACP: Link Aggregation Control Protocol
PBB: Provider Backbone Bridge
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 45 skipping to change at page 8, line 49
(R1e) A Multi-Homed vES (Single-Active or All-Active) can be spread (R1e) A Multi-Homed vES (Single-Active or All-Active) can be spread
across any two or more PEs (on two or more ENNIs) across any two or more PEs (on two or more ENNIs)
3.2. Scalability 3.2. Scalability
A single physical port (e.g., ENNI) can be associated with many A single physical port (e.g., ENNI) can be associated with many
vES's. The following requirements give a quantitative measure for vES's. The following requirements give a quantitative measure for
each vES type. each vES type.
(R2a) A PE MUST handle thousands or tens of thousands of Single-homed (R2a) A PE SHOULD handle very large number of Single-Homed vES's on a
vES's on a single physical port (e.g., single ENNI) single physical port (e.g., thousands of vES's on a single ENNI)
(R2b) A PE MUST handle hundreds of Single-Active vES's on a single (R2b) A PE SHOULD handle large number of Single-Active vES's on a
physical port (e.g., single ENNI) single physical port (e.g., hundreds of vES's on a single ENNI)
(R2c) A PE MAY handle tens or hundreds of All-Active Multi-Homed
vES's on a single physical port (e.g., single ENNI)
(R2d) A PE MUST handle the above scale for a mix of Single-homed (R2c) A PE MAY handle large number of All-Active Multi-Homed vES's on
a single physical port (e.g., hundreds of vES's on a single ENNI)
(R2d) A PE SHOULD handle the above scale for a mix of Single-homed
vES's and Single-Active vES's simultaneously on a single physical vES's and Single-Active vES's simultaneously on a single physical
port (e.g., single ENNI) port (e.g., single ENNI)
(R4e) A PE MAY handle the above sale for a mixed of All-Active Multi- (R4e) A PE MAY handle the above sale for a mixed of All-Active Multi-
Homed vES's along with other types of vES's on a single physical port Homed vES's along with other types of vES's on a single physical port
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
skipping to change at page 11, line 42 skipping to change at page 11, line 47
(R8a) There SHOULD be a mechanism equivalent to EVPN mass-withdraw (R8a) There SHOULD be a mechanism equivalent to EVPN mass-withdraw
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 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 instead of a group of links. In other performed for a group of EVCs or LSPs/PWs instead of a group of
words, the ESI is associated with a virtual ES (vES) and that's why links. In other words, the ESI is associated with a virtual ES (vES)
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 EVPN solution, everything basically remains the same except for
the handling of physical port failure where many vES's can be 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.
skipping to change at page 12, line 28 skipping to change at page 12, line 35
BMAC is shared for all Single-Active vES's that shared the same ENNI. BMAC is shared for all Single-Active vES's that shared the same ENNI.
- One shared BMAC address can be used for all Single-Active vES's on - One shared BMAC address can be used for all Single-Active vES's on
that PE. that PE.
- One BMAC address is used per EVC per physical port per PE for each - One BMAC address is used per EVC per physical port per PE for each
All-Active multi-homed vES. In other words, a single BMAC address is All-Active multi-homed vES. In other words, a single BMAC address is
used per vES for All-Active multi-homing scenarios. used per vES for All-Active multi-homing scenarios.
- A single BMAC address may also be used per vES per PE for Single- - A single BMAC address may also be used per vES per PE for Single-
Active multi-homing scenarios. Active multi-homing scenarios.
BEB +--------------+ BEB BEB +--------------+ BEB
|| | | || || | | ||
\/ | | \/ \/ | | \/
+----+ EVC1 +----+ | | +----+ +----+ +----+ EVC1 +----+ | | +----+ +----+
| CE1|------| | | | | |---| CE2| | CE1|------| | | | | |---| CE2|
+----+\ | PE1| | IP/MPLS | | PE3| +----+ +----+\ | PE1| | IP/MPLS | | PE3| +----+
\ +----+ | Network | +----+ \ +----+ | Network | +----+
\ | | \ | |
EVC2\ +----+ | | EVC2\ +----+ | |
skipping to change at page 13, line 12 skipping to change at page 13, line 31
Figure 2: PBB-EVPN Network Figure 2: PBB-EVPN Network
4.1. EVPN DF Election for vES 4.1. EVPN DF Election for vES
The procedure for service carving for virtual Ethernet Segments is The procedure for service carving for virtual Ethernet Segments is
the same as the one outlined in section 8.5 of [RFC7432] except for the same as the one outlined in section 8.5 of [RFC7432] except for
the fact that ES is replaced with vES. For the sake of clarity and the fact that ES is replaced with vES. For the sake of clarity and
completeness, this procedure is repeated below: completeness, this procedure is repeated below:
1. When a PE discovers the ESI or is configured with the ESI 1. When a PE discovers the vESI or is configured with the vESI
associated with its attached vES, it advertises an Ethernet Segment associated with its attached vES, it advertises an Ethernet Segment
route with the associated ES-Import extended community attribute. route with the associated ES-Import extended community attribute.
2. The PE then starts a timer (default value = 3 seconds) to allow 2. The PE then starts a timer (default value = 3 seconds) to allow
the reception of Ethernet Segment routes from other PE nodes the reception of Ethernet Segment routes from other PE nodes
connected to the same vES. This timer value MUST be same across all connected to the same vES. This timer value MUST be same across all
PEs connected to the same vES. PEs connected to the same vES.
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
skipping to change at page 13, line 52 skipping to change at page 14, line 23
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. This will re-trigger the service carving procedures on
all the PEs in the RG. For PE node failure, or upon PE commissioning all the PEs in the RG. For PE node failure, or upon PE commissioning
or decommissioning, the PEs re-trigger the service carving across all or decommissioning, the PEs re-trigger the service carving across all
affected vES's. In case of a Single-Active multi-homing, when a affected vES's. In case of a Single-Active multi-homing, when a
service moves from one PE in the RG to another PE as a result of re- service moves from one PE in the Redundancy Group to another PE as a
carving, the PE, which ends up being the elected DF for the service, result of re-carving, the PE, which ends up being the elected DF for
SHOULD trigger a MAC address flush notification towards the the service, SHOULD trigger a MAC address flush notification towards
associated vES. This can be done, for e.g. using IEEE 802.1ak MVRP the associated vES. This can be done, for e.g. using IEEE 802.1ak
'new' declaration. 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. withdraw message as a MAC address flush notification. It should be
noted that the PW-status is signaled for the scenarios where there is
a one-to-one mapping between EVI 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
skipping to change at page 21, line 37 skipping to change at page 22, line 19
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.
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
Private LAN Service (VPLS) Interoperability with Provider
Backbone Bridges", RFC 7080, December 2013.
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
 End of changes. 25 change blocks. 
73 lines changed or deleted 85 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/