draft-ietf-l2vpn-evpn-11.original   draft-ietf-l2vpn-evpn-12.txt 
pl 10.0i
Network Working Group A. Sajassi, Ed. Network Working Group A. Sajassi, Ed.
INTERNET-DRAFT Cisco INTERNET-DRAFT Cisco
Category: Standards Track Category: Standards Track
R. Aggarwal R. Aggarwal
J. Drake Arktan J. Drake Arktan
Juniper Networks Juniper Networks
N. Bitar N. Bitar
W. Henderickx Verizon W. Henderickx Verizon
Alcatel-Lucent Alcatel-Lucent
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
J. Uttaro J. Uttaro
AT&T AT&T
Expires: April 18, 2015 October 18, 2014 Expires: April 20, 2015 October 20, 2014
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-11 draft-ietf-l2vpn-evpn-12
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 31 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Specification of requirements . . . . . . . . . . . . . . . . . 5 2. Specification of requirements . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. BGP MPLS Based EVPN Overview . . . . . . . . . . . . . . . . . 6 4. BGP MPLS Based EVPN Overview . . . . . . . . . . . . . . . . . 6
5. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7 5. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7
6. Ethernet Tag ID . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Ethernet Tag ID . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 11 6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 11
6.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 11 6.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 11
6.2.1 Port Based Service Interface . . . . . . . . . . . . . . 11 6.2.1 Port Based Service Interface . . . . . . . . . . . . . . 12
6.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 11 6.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 12
6.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 12 6.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 12
7. BGP EVPN Routes . . . . . . . . . . . . . . . . . . . . . . . . 12 7. BGP EVPN Routes . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 13 7.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 13
7.2. MAC/IP Advertisement Route . . . . . . . . . . . . . . . . 13 7.2. MAC/IP Advertisement Route . . . . . . . . . . . . . . . . 14
7.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 14 7.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 15
7.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 15 7.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 15
7.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 15 7.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 16
7.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 16 7.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 16
7.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 16 7.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 17
7.8 Default Gateway Extended Community . . . . . . . . . . . . . 17 7.8 Default Gateway Extended Community . . . . . . . . . . . . . 17
7.9 Route Distinguisher Assignment per EVI . . . . . . . . . . . 17 7.9 Route Distinguisher Assignment per EVI . . . . . . . . . . . 18
7.10 Route Targets . . . . . . . . . . . . . . . . . . . . . . . 17 7.10 Route Targets . . . . . . . . . . . . . . . . . . . . . . . 18
7.10.1 Auto-Derivation from the Ethernet Tag ID . . . . . . . 17 7.10.1 Auto-Derivation from the Ethernet Tag ID . . . . . . . 18
8. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 18 8. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 18
8.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 18 8.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 19
8.1.1 Constructing the Ethernet Segment Route . . . . . . . . 18 8.1.1 Constructing the Ethernet Segment Route . . . . . . . . 19
8.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 18 8.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 19
8.2.1 Constructing Ethernet A-D per Ethernet Segment Route . . 19 8.2.1 Constructing Ethernet A-D per Ethernet Segment Route . . 20
8.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 20 8.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 20
8.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 20 8.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 21
8.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 21 8.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 21
8.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 21 8.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 21
8.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 22 8.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 23
8.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 23 8.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 24
8.4.1 Constructing Ethernet A-D per EVPN Instance Route . . . 24 8.4.1 Constructing Ethernet A-D per EVPN Instance Route . . . 25
8.5 Designated Forwarder Election . . . . . . . . . . . . . . . 25 8.5 Designated Forwarder Election . . . . . . . . . . . . . . . 25
8.6. Interoperability with Single-homing PEs . . . . . . . . . . 27 8.6. Interoperability with Single-homing PEs . . . . . . . . . . 28
9. Determining Reachability to Unicast MAC Addresses . . . . . . . 27 9. Determining Reachability to Unicast MAC Addresses . . . . . . . 28
9.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Remote learning . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Remote learning . . . . . . . . . . . . . . . . . . . . . . 29
9.2.1. Constructing MAC/IP Address Advertisement . . . . . . . 28 9.2.1. Constructing MAC/IP Address Advertisement . . . . . . . 29
9.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . . 30 9.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . . 31
10. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 32 10.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 33
11. Handling of Multi-Destination Traffic . . . . . . . . . . . . 33 11. Handling of Multi-Destination Traffic . . . . . . . . . . . . 34
11.1. Constructing Inclusive Multicast Ethernet Tag Route . . . 34 11.1. Constructing Inclusive Multicast Ethernet Tag Route . . . 34
11.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 34 11.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 35
12. Processing of Unknown Unicast Packets . . . . . . . . . . . . 35 12. Processing of Unknown Unicast Packets . . . . . . . . . . . . 36
12.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 36 12.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 36
12.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 36 12.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 37
13. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 37 13. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 37
13.1. Forwarding packets received from a CE . . . . . . . . . . 37 13.1. Forwarding packets received from a CE . . . . . . . . . . 37
13.2. Forwarding packets received from a remote PE . . . . . . . 38 13.2. Forwarding packets received from a remote PE . . . . . . . 38
13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 38 13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 38
13.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 38 13.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 39
14. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 38 14. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 39
14.1. Load balancing of traffic from a PE to remote CEs . . . . 39 14.1. Load balancing of traffic from a PE to remote CEs . . . . 39
14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 39 14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 39
14.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 39 14.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 40
14.2. Load balancing of traffic between a PE and a local CE . . 41 14.2. Load balancing of traffic between a PE and a local CE . . 42
14.2.1. Data plane learning . . . . . . . . . . . . . . . . . 41 14.2.1. Data plane learning . . . . . . . . . . . . . . . . . 42
14.2.2. Control plane learning . . . . . . . . . . . . . . . . 41 14.2.2. Control plane learning . . . . . . . . . . . . . . . . 42
15. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 42 15. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 43 15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 44
15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 44 15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 44
16. Multicast & Broadcast . . . . . . . . . . . . . . . . . . . . 44 16. Multicast & Broadcast . . . . . . . . . . . . . . . . . . . . 45
16.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 44 16.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 45
16.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 44 16.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 45
16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 45 16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 45
17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 45 17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 46
17.1. Transit Link and Node Failures between PEs . . . . . . . . 45 17.1. Transit Link and Node Failures between PEs . . . . . . . . 46
17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 46 17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 46
17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 46 17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 46
18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . . 46 18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . . 47
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
20. Security Considerations . . . . . . . . . . . . . . . . . . . 47 20. Security Considerations . . . . . . . . . . . . . . . . . . . 48
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
23.1 Normative References . . . . . . . . . . . . . . . . . . . 50 23.1 Normative References . . . . . . . . . . . . . . . . . . . 50
23.2 Informative References . . . . . . . . . . . . . . . . . . 50 23.2 Informative References . . . . . . . . . . . . . . . . . . 51
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 51 24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes procedures for BGP MPLS based Ethernet VPNs Virtual Private LAN Service (VPLS), as defined in [RFC4664],
(EVPN). The procedures described here meet the requirements specified [RFC4761], and [RFC4762], is a proven and widely deployed technology.
in [RFC7209]. Please refer to [RFC7209] for the detailed However, the existing solution has a number of limitations when it
requirements and motivation. EVPN requires extensions to existing comes to multi-homing and redundancy, multicast optimization,
IP/MPLS protocols as described in this document. In addition to these provisioning simplicity, flow-based load balancing and multi-pathing
that are of important considerations for Data Center (DC)
deployments. [RFC7209] describes the motivation for a new solution to
address these limitations. It also outlines a set of requirements
that the new solution must address.
This document describes procedures for a BGP MPLS based solution
called Ethernet VPN (EVPN) to address the requirements specified in
[RFC7209]. Please refer to [RFC7209] for the detailed requirements
and motivation. EVPN requires extensions to existing IP/MPLS
protocols as described in this document. In addition to these
extensions EVPN uses several building blocks from existing MPLS extensions EVPN uses several building blocks from existing MPLS
technologies. technologies.
2. Specification of requirements 2. Specification of requirements
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
Broadcast Domain: In a bridged network, it corresponds to a Virtual Broadcast Domain: In a bridged network, it corresponds to a Virtual
LAN (VLAN); where a VLAN is typically represented by a single VLAN ID LAN (VLAN); where a VLAN is typically represented by a single VLAN ID
(VID), but can be represented by several VIDs where Shared VLAN (VID), but can be represented by several VIDs where Shared VLAN
Learning (SVL) is used per [802.1Q]. Learning (SVL) is used per [802.1Q].
Bridge Domain: An instantiation of a broadcast domain on a bridge Bridge Domain: An instantiation of a broadcast domain on a bridge
node node
CE: Customer Edge device e.g., host or router or switch CE: Customer Edge device - e.g., host or router or switch
EVI: An EVPN instance spanning across the PEs participating in that EVI: An EVPN instance spanning across the PEs participating in that
EVPN EVPN
MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on
a PE for an EVI a PE for an EVI
Ethernet Segment (ES): If a multi-homed device or network is Ethernet Segment (ES): When a customer site (device or network) is
connected to two or more PEs via a set of Ethernet links, then that connected to one or more PEs via a set of Ethernet links, then that
set of links is referred to as an 'Ethernet segment'. set of links is referred to as an 'Ethernet segment'.
Ethernet Segment Identifier (ESI): A unique non-zero identifier that Ethernet Segment Identifier (ESI): A unique non-zero identifier that
identifies an Ethernet Segment is called an 'Ethernet Segment identifies an Ethernet Segment is called an 'Ethernet Segment
Identifier'. Identifier'.
Ethernet Tag: An Ethernet Tag identifies a particular broadcast Ethernet Tag: An Ethernet Tag identifies a particular broadcast
domain, e.g., a VLAN. An EVPN instance consists of one or more domain, e.g., a VLAN. An EVPN instance consists of one or more
broadcast domains. Ethernet tag(s) are assigned to the broadcast broadcast domains. Ethernet tag(s) are assigned to the broadcast
domains of a given EVPN instance by the provider of that EVPN, and domains of a given EVPN instance by the provider of that EVPN, and
each PE in that EVPN instance performs a mapping between broadcast each PE in that EVPN instance performs a mapping between broadcast
domain identifier(s) understood by each of its attached CEs and the domain identifier(s) understood by each of its attached CEs and the
corresponding Ethernet tag. corresponding Ethernet tag.
LACP: Link Aggregation Control Protocol LACP: Link Aggregation Control Protocol
MP2MP: Multipoint to Multipoint MP2MP: Multipoint to Multipoint
P2MP: Point to Multipoint P2MP: Point to Multipoint
P2P: Point to Point P2P: Point to Point
PE: Provider Edge device
Single-Active Redundancy Mode: When only a single PE, among all the Single-Active Redundancy Mode: When only a single PE, among all the
PEs attached to an Ethernet segment, is allowed to forward traffic PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet Segment, then the Ethernet segment is defined to/from that Ethernet Segment, then the Ethernet segment is defined
to be operating in Single-Active redundancy mode. to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet All-Active Redundancy Mode: 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.
4. BGP MPLS Based EVPN Overview 4. BGP MPLS Based EVPN Overview
This section provides an overview of EVPN. An EVPN instance comprises This section provides an overview of EVPN. An EVPN instance comprises
CEs that are connected to PEs that form the edge of the MPLS Customer Edge devices (CEs) that are connected to Provider Edge
infrastructure. A CE may be a host, a router or a switch. The PEs devices (PEs) that form the edge of the MPLS infrastructure. A CE may
provide virtual Layer 2 bridged connectivity between the CEs. There be a host, a router or a switch. The PEs provide virtual Layer 2
may be multiple EVPN instances in the provider's network. bridged connectivity between the CEs. There may be multiple EVPN
instances in the provider's network.
The PEs may be connected by an MPLS LSP infrastructure which provides The PEs may be connected by an MPLS LSP infrastructure which provides
the benefits of MPLS technology such as fast-reroute, resiliency, the benefits of MPLS technology such as fast-reroute, resiliency,
etc. The PEs may also be connected by an IP infrastructure in which etc. The PEs may also be connected by an IP infrastructure in which
case IP/GRE tunneling or other IP tunneling can be used between the case IP/GRE tunneling or other IP tunneling can be used between the
PEs. The detailed procedures in this version of this document are PEs. The detailed procedures in this version of this document are
specified only for MPLS LSPs as the tunneling technology. However specified only for MPLS LSPs as the tunneling technology. However
these procedures are designed to be extensible to IP tunneling as the these procedures are designed to be extensible to IP tunneling as the
Packet Switched Network (PSN) tunneling technology. Packet Switched Network (PSN) tunneling technology.
skipping to change at page 7, line 38 skipping to change at page 6, line 39
to a MAC-VRF on a PE, on an Ethernet interface which may be to a MAC-VRF on a PE, on an Ethernet interface which may be
configured for one or more Ethernet Tags, e.g., VLAN IDs. Some configured for one or more Ethernet Tags, e.g., VLAN IDs. Some
deployment scenarios guarantee uniqueness of VLAN IDs across EVPN deployment scenarios guarantee uniqueness of VLAN IDs across EVPN
instances: all points of attachment for a given EVPN instance use the instances: all points of attachment for a given EVPN instance use the
same VLAN ID, and no other EVPN instance uses this VLAN ID. This same VLAN ID, and no other EVPN instance uses this VLAN ID. This
document refers to this case as a "Unique VLAN EVPN" and describes document refers to this case as a "Unique VLAN EVPN" and describes
simplified procedures to optimize for it. simplified procedures to optimize for it.
5. Ethernet Segment 5. Ethernet Segment
If a CE is multi-homed to two or more PEs, the set of Ethernet links As indicated in [RFC7209], each Ethernet Segment needs a unique
constitutes an "Ethernet Segment". An Ethernet segment may appear to identifier in an EVPN. This section defines how such identifiers are
the CE as a Link Aggregation Group (LAG). Ethernet segments have an assigned and how they are encoded for use in EVPN signaling. Later
identifier, called the "Ethernet Segment Identifier" (ESI) which is sections of the document describe the protocol mechanisms that
encoded as a ten octets integer in line format with the most utilize the identifiers.
significant octet sent first. The following two ESI values are
reserved:
- ESI 0 denotes a single-homed CE. When a customer site is connected to one or more PEs via a set of
Ethernet links, then this set of Ethernet links constitutes an
"Ethernet Segment". For a multi-homed site, each Ethernet Segment
(ES) is identified by a unique non-zero identifier called Ethernet
Segment Identifier (ESI). An ESI is encoded as a ten octets integer
in line format with the most significant octet sent first. The
following two ESI values are reserved:
- ESI 0 denotes a single-homed site.
- ESI {0xFF} (repeated 10 times) is known as MAX-ESI and is - ESI {0xFF} (repeated 10 times) is known as MAX-ESI and is
reserved. reserved.
In general, an Ethernet segment SHOULD have a non-reserved ESI that In general, an Ethernet segment SHOULD have a non-reserved ESI that
is unique network wide (i.e., across all EVPN instances on all the is unique network wide (i.e., across all EVPN instances on all the
PEs). If the CE(s) constituting an Ethernet Segment is (are) managed PEs). If the CE(s) constituting an Ethernet Segment is (are) managed
by the network operator, then ESI uniqueness should be guaranteed; by the network operator, then ESI uniqueness should be guaranteed;
however, if the CE(s) is (are) not managed, then the operator MUST however, if the CE(s) is (are) not managed, then the operator MUST
configure a network-wide unique ESI for that Ethernet Segment. This configure a network-wide unique ESI for that Ethernet Segment. This
skipping to change at page 19, line 51 skipping to change at page 17, line 41
The Ethernet Segment Identifier MUST be a ten octet entity as The Ethernet Segment Identifier MUST be a ten octet entity as
described in section "Ethernet Segment". The Ethernet A-D route is described in section "Ethernet Segment". The Ethernet A-D route is
not needed when the Segment Identifier is set to 0 (e.g., single- not needed when the Segment Identifier is set to 0 (e.g., single-
homed scenarios). homed scenarios).
The Ethernet Tag ID MUST be set to MAX-ET. The Ethernet Tag ID MUST be set to MAX-ET.
The MPLS label in the NLRI MUST be set to 0. The MPLS label in the NLRI MUST be set to 0.
The "ESI Label Extended Community" MUST be included in the route. If The "ESI Label Extended Community" MUST be included in the route. If
All-Active redundancy mode is desired, then the "Single-Active" bit All-Active redundancy mode is desired, then the "Single-Active" bit
in the flags of the ESI Label Extended Community MUST be set to 0 and in the flags of the ESI Label Extended Community MUST be set to 0 and
the MPLS label in that extended community MUST be set to a valid MPLS the MPLS label in that extended community MUST be set to a valid MPLS
label value. The MPLS label in this Extended Community is referred to label value. The MPLS label in this Extended Community is referred to
as the ESI label and MUST have the same value in each Ethernet A-D as the ESI label and MUST have the same value in each Ethernet A-D
per ES route advertised for the ES. This label MUST be a downstream per ES route advertised for the ES. This label MUST be a downstream
assigned MPLS label if the advertising PE is using ingress assigned MPLS label if the advertising PE is using ingress
replication for receiving multicast, broadcast or unknown unicast replication for receiving multicast, broadcast or unknown unicast
traffic from other PEs. If the advertising PE is using P2MP MPLS LSPs traffic from other PEs. If the advertising PE is using P2MP MPLS LSPs
for sending multicast, broadcast or unknown unicast traffic, then for sending multicast, broadcast or unknown unicast traffic, then
skipping to change at page 50, line 37 skipping to change at page 44, line 57
RFC 4760, January 2007 RFC 4760, January 2007
[RFC7153] E. Rosen et. al., "IANA Registries for BGP Extended [RFC7153] E. Rosen et. al., "IANA Registries for BGP Extended
Communities", RFC 7153, March 2014 Communities", RFC 7153, March 2014
23.2 Informative References 23.2 Informative References
[RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", May 2014. Ethernet VPN", May 2014.
[RFC7117] R. Aggarwal et.al., "Multicast in Virtual Private LAN [RFC7117] R. Aggarwal et.al., "Multicast in Virtual
Service (VPLS)", February 2014. Private LAN Service (VPLS)", February 2014.
[RFC4664] L. Andersson et. al., "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006
[RFC4684] P. Marques et. al., "Constrained Route Distribution for [RFC4684] P. Marques et. al., "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching Border Gateway Protocol/MultiProtocol Label Switching
(BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks
(VPNs)", RFC 4684, November 2006. (VPNs)", RFC 4684, November 2006.
[RFC6790] K. Kompella et. al, "The Use of Entropy Labels in MPLS [RFC6790] K. Kompella et. al, "The Use of Entropy Labels
Forwarding", RFC 6790, November 2012. in MPLS Forwarding", RFC 6790, November 2012.
[RFC4385] S. Bryant et. al, "PWE3 Control Word for Use over an MPLS [RFC4385] S. Bryant et. al, "PWE3 Control Word for Use
PSN", RFC 4385, February 2006 over an MPLS PSN", RFC 4385, February 2006
[RFC5925] J. Touch et. al., "The TCP Authentication Option", RFC [RFC5925] J. Touch et. al., "The TCP Authentication Option", RFC
5925, June 2010 5925, June 2010
[RFC5226] T. Narten et. al., "Guidelines for Writing an IANA [RFC5226] T. Narten et. al., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008 Considerations Section in RFCs", RFC 5226, May 2008
[RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis", RFC [RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis", RFC
4272, January 2006 4272, January 2006
[RFC6952] M. Jethanandani et. al., "Analysis of BGP, LDP, PCEP, and [RFC6952] M. Jethanandani et. al., "Analysis of BGP, LDP, PCEP, and
MSDP Issues According to the Keying and Authentication MSDP Issues According to the
for Routing Protocols (KARP) Design Guide", RFC 6952, May Keying and Authentication for Routing Protocols (KARP)
2013 Design Guide", RFC 6952, May 2013
[802.1Q] "IEEE Standard for Local and metropolitan area networks - [802.1Q] "IEEE Standard for Local and metropolitan area networks -
Media Access Control (MAC) Bridges and Virtual Bridged Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks", IEEE Std 802.1Q(tm), 2012 Edition, Local Area Networks", IEEE Std 802.1Q(tm), 2012 Edition,
October 2012. October 2012.
24. Author's Address 24. Author's Address
Ali Sajassi Ali Sajassi
Cisco Cisco
 End of changes. 36 change blocks. 
79 lines changed or deleted 103 lines changed or added

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