draft-ietf-l2vpn-evpn-01.txt   draft-ietf-l2vpn-evpn-02.txt 
skipping to change at page 1, line 19 skipping to change at page 1, line 19
W. Henderickx W. Henderickx
S. Boutros F. Balus S. Boutros F. Balus
K. Patel Alcatel-Lucent K. Patel Alcatel-Lucent
S. Salam S. Salam
Cisco Aldrin Isaac Cisco Aldrin Isaac
Bloomberg Bloomberg
J. Drake J. Drake
R. Shekhar J. Uttaro R. Shekhar J. Uttaro
Juniper Networks AT&T Juniper Networks AT&T
Expires: January 14, 2012 July 14, 2012 Expires: April 22, 2013 October 22, 2012
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-01 draft-ietf-l2vpn-evpn-02
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 33 skipping to change at page 2, line 33
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. BGP MPLS Based E-VPN Overview . . . . . . . . . . . . . . . . . 6 5. BGP MPLS Based E-VPN Overview . . . . . . . . . . . . . . . . . 6
6. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7 6. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7
7. Ethernet Tag . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Ethernet Tag . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 9 7.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 9
7.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 9 7.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 9
7.2.1 Port Based Service Interface . . . . . . . . . . . . . . 9 7.2.1 Port Based Service Interface . . . . . . . . . . . . . . 9
7.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 9 7.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 9
7.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 10
8. BGP E-VPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . 10 8. BGP E-VPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 10 8.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 11
8.2. MAC Advertisement Route . . . . . . . . . . . . . . . . . 11 8.2. MAC Advertisement Route . . . . . . . . . . . . . . . . . 11
8.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 11 8.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 11
8.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 12 8.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 12
8.5 ESI MPLS Label Extended Community . . . . . . . . . . . . . 12 8.5 ESI MPLS Label Extended Community . . . . . . . . . . . . . 12
8.6 ES-Import Extended Community . . . . . . . . . . . . . . . . 13 8.6 ES-Import Extended Community . . . . . . . . . . . . . . . . 13
8.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 13 8.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 13
9. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 13 8.8 Default Gateway Extended Community . . . . . . . . . . . . . 13
9.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 13 9. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 14
9.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 14
9.1.1 Constructing the Ethernet Segment Route . . . . . . . . 14 9.1.1 Constructing the Ethernet Segment Route . . . . . . . . 14
9.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 14 9.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 14
9.2.1 Constructing the Ethernet A-D Route per Ethernet 9.2.1 Constructing the Ethernet A-D Route per Ethernet
Segment . . . . . . . . . . . . . . . . . . . . . . . . 15 Segment . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 15 9.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 16
9.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 16
9.3.1 ESI MPLS Label Assignment . . . . . . . . . . . . . . . 16 9.3.1 ESI MPLS Label Assignment . . . . . . . . . . . . . . . 16
9.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 16 9.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 17
9.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 17 9.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 17
9.3.1.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . 18 9.3.1.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . 18
9.4 Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.4 Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.4.1 Constructing the Ethernet A-D Route per EVI . . . . . . 18 9.4.1 Constructing the Ethernet A-D Route per EVI . . . . . . 19
9.4.1.1 Ethernet A-D Route Targets . . . . . . . . . . . . . 19 9.4.1.1 Ethernet A-D Route Targets . . . . . . . . . . . . . 20
9.5 Designated Forwarder Election . . . . . . . . . . . . . . . 20 9.5 Designated Forwarder Election . . . . . . . . . . . . . . . 20
9.5.1 Default DF Election Procedure . . . . . . . . . . . . . 21 9.5.1 Default DF Election Procedure . . . . . . . . . . . . . 22
9.5.2 DF Election with Service Carving . . . . . . . . . . . . 21 9.5.2 DF Election with Service Carving . . . . . . . . . . . . 22
10. Determining Reachability to Unicast MAC Addresses . . . . . . 22 10. Determining Reachability to Unicast MAC Addresses . . . . . . 23
10.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Remote learning . . . . . . . . . . . . . . . . . . . . . 23 10.2. Remote learning . . . . . . . . . . . . . . . . . . . . . 24
10.2.1. Constructing the BGP E-VPN MAC Address Advertisement . 23 10.2.1. Constructing the BGP E-VPN MAC Address Advertisement . 24
11. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Handling of Multi-Destination Traffic . . . . . . . . . . . . 26 11.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 26
12. Handling of Multi-Destination Traffic . . . . . . . . . . . . 27
12.1. Construction of the Inclusive Multicast Ethernet Tag 12.1. Construction of the Inclusive Multicast Ethernet Tag
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 27 12.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 28
13. Processing of Unknown Unicast Packets . . . . . . . . . . . . 28 13. Processing of Unknown Unicast Packets . . . . . . . . . . . . 29
13.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 28 13.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 30
13.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 29 13.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 30
14. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 29 14. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 30
14.1. Forwarding packets received from a CE . . . . . . . . . . 29 14.1. Forwarding packets received from a CE . . . . . . . . . . 30
14.2. Forwarding packets received from a remote PE . . . . . . . 30 14.2. Forwarding packets received from a remote PE . . . . . . . 31
14.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 30 14.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 31
14.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 31 14.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 32
15. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 31 15. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 32
15.1. Load balancing of traffic from an PE to remote CEs . . . . 31 15.1. Load balancing of traffic from an PE to remote CEs . . . . 32
15.1.1 Active-Standby Redundancy Mode . . . . . . . . . . . . 31 15.1.1 Active-Standby Redundancy Mode . . . . . . . . . . . . 32
15.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 32 15.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 33
15.2. Load balancing of traffic between an PE and a local CE . . 33 15.2. Load balancing of traffic between an PE and a local CE . . 35
15.2.1. Data plane learning . . . . . . . . . . . . . . . . . 34 15.2.1. Data plane learning . . . . . . . . . . . . . . . . . 35
15.2.2. Control plane learning . . . . . . . . . . . . . . . . 34 15.2.2. Control plane learning . . . . . . . . . . . . . . . . 35
16. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 35
17. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 36 17. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 36 17.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 37
17.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 36 17.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 37
17.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 36 17.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 37
17.3.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 36 17.3.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 38
17.3.2. Selective Trees . . . . . . . . . . . . . . . . . . . 37 17.3.2. Selective Trees . . . . . . . . . . . . . . . . . . . 38
17.4. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 38 17.4. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 39
18. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 38 18. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.1. Transit Link and Node Failures between PEs . . . . . . . . 38 18.1. Transit Link and Node Failures between PEs . . . . . . . . 39
18.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 38 18.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 39
18.2.1. Local Repair . . . . . . . . . . . . . . . . . . . . . 38 18.2.1. Local Repair . . . . . . . . . . . . . . . . . . . . . 40
18.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 39 18.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 40
19. LACP State Synchronization . . . . . . . . . . . . . . . . . . 39 19. LACP State Synchronization . . . . . . . . . . . . . . . . . . 40
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 21. Security Considerations . . . . . . . . . . . . . . . . . . . 42
21. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
23.1 Normative References . . . . . . . . . . . . . . . . . . . 42
23.2 Informative References . . . . . . . . . . . . . . . . . . 42
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 43
1. Specification of requirements 1. 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].
2. Contributors 2. Contributors
In addition to the authors listed above, the following individuals In addition to the authors listed above, the following individuals
skipping to change at page 5, line 30 skipping to change at page 5, line 30
Juniper Networks Juniper Networks
Clarence Filsfils Clarence Filsfils
Dennis Cai Dennis Cai
Cisco Cisco
3. Introduction 3. Introduction
This document describes procedures for BGP MPLS based Ethernet VPNs This document describes procedures for BGP MPLS based Ethernet VPNs
(E-VPN). The procedures described here are intended to meet the (E-VPN). The procedures described here are intended to meet the
requirements specified in [E-VPN-REQ]. Please refer to [E-VPN-REQ] requirements specified in [EVPN-REQ]. Please refer to [EVPN-REQ] for
for the detailed requirements and motivation. E-VPN requires the detailed requirements and motivation. E-VPN requires extensions
extensions to existing IP/MPLS protocols as described in this to existing IP/MPLS protocols as described in this document. In
document. In addition to these extensions E-VPN uses several building addition to these extensions E-VPN uses several building blocks from
blocks from existing MPLS technologies. existing MPLS technologies.
4. Terminology 4. Terminology
CE: Customer Edge device e.g., host or router or switch CE: Customer Edge device e.g., host or router or switch
E-VPN Instance (EVI): An E-VPN routing and forwarding instance on a E-VPN Instance (EVI): An E-VPN routing and forwarding instance on a
PE. PE.
Ethernet segment identifier (ESI): If a CE is multi-homed to two or Ethernet segment identifier (ESI): If a CE is multi-homed to two or
more PEs, the set of Ethernet links that attaches the CE to the PEs more PEs, the set of Ethernet links that attaches the CE to the PEs
skipping to change at page 10, line 5 skipping to change at page 10, line 5
CE-VID) and an EVI. Furthermore, there are multiple bridge domains CE-VID) and an EVI. Furthermore, there are multiple bridge domains
per PE for the EVI: one broadcast domain per CE broadcast domain per PE for the EVI: one broadcast domain per CE broadcast domain
identifier. In the case where the CE broadcast domain identifiers are identifier. In the case where the CE broadcast domain identifiers are
not consistent for different CEs, a normalized Ethernet Tag MUST be not consistent for different CEs, a normalized Ethernet Tag MUST be
carried in the MPLS encapsulated frames and a tag translation carried in the MPLS encapsulated frames and a tag translation
function MUST be supported in the data path. This translation MUST be function MUST be supported in the data path. This translation MUST be
performed on both the imposition as well as the disposition PEs. The performed on both the imposition as well as the disposition PEs. The
Ethernet Tag Identifier in all E-VPN routes MUST be set to the Ethernet Tag Identifier in all E-VPN routes MUST be set to the
normalized Ethernet Tag assigned by the E-VPN provider. normalized Ethernet Tag assigned by the E-VPN provider.
7.3.1 Port Based VLAN Aware Service Interface
This service interface is a special case of the VLAN Aware Bundle
service interface, where all of the VLANs on the port are part of the
same service and map to the same bundle. The procedures are identical
to those described in section 7.3.
8. BGP E-VPN NLRI 8. BGP E-VPN NLRI
This document defines a new BGP NLRI, called the E-VPN NLRI. This document defines a new BGP NLRI, called the E-VPN NLRI.
Following is the format of the E-VPN NLRI: Following is the format of the E-VPN NLRI:
+-----------------------------------+ +-----------------------------------+
| Route Type (1 octet) | | Route Type (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Length (1 octet) | | Length (1 octet) |
skipping to change at page 11, line 38 skipping to change at page 11, line 43
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| MAC Address Length (1 octet) | | MAC Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| MAC Address (6 octets) | | MAC Address (6 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| IP Address (4 or 16 octets) | | IP Address (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label (n * 3 octets) | | MPLS Label (3 octets) |
+---------------------------------------+ +---------------------------------------+
For procedures and usage of this route please see section 10 For procedures and usage of this route please see section 10
"Determining Reachability to Unicast MAC Addresses" and section 15 "Determining Reachability to Unicast MAC Addresses" and section 15
"Load Balancing of Unicast Packets". "Load Balancing of Unicast Packets".
8.3. Inclusive Multicast Ethernet Tag Route 8.3. Inclusive Multicast Ethernet Tag Route
An Inclusive Multicast Ethernet Tag route type specific E-VPN NLRI An Inclusive Multicast Ethernet Tag route type specific E-VPN NLRI
consists of the following: consists of the following:
skipping to change at page 13, line 4 skipping to change at page 13, line 6
as follows: as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x44 | Sub-Type | Flags (One Octet) |Reserved=0 | | 0x44 | Sub-Type | Flags (One Octet) |Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0| ESI MPLS label | | Reserved = 0| ESI MPLS label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The low order bit of the flags octet is defined as the "Active- The low order bit of the flags octet is defined as the "Active-
Standby" bit and may be set to 1. The other bits must be set to 0. Standby" bit and may be set to 1. A value of 0 means that the multi-
homed site is operating in Active-Active mode; whereas, a value of 1
means that the multi-homed site is operating in Active-Standby mode.
The second low order bit of the flags octet is defined as the "Root-
Leaf". A value of 0 means that this label is associated with a Root
site; whereas, a value of 1 means that this label is associate with a
Leaf site. The other bits must be set to 0.
8.6 ES-Import Extended Community 8.6 ES-Import Extended Community
This is a new transitive extended community carried with the Ethernet This is a new transitive extended community carried with the Ethernet
Segment route. When used, it enables all the PEs connected to the Segment route. When used, it enables all the PEs connected to the
same multi-homed site to import the Ethernet Segment routes. The same multi-homed site to import the Ethernet Segment routes. The
value is derived automatically from the ESI by encoding the 6-byte value is derived automatically from the ESI by encoding the 6-byte
MAC address portion of the ESI in the ES-Import Extended Community. MAC address portion of the ESI in the ES-Import Extended Community.
The format of this extended community is as follows: The format of this extended community is as follows:
skipping to change at page 13, line 42 skipping to change at page 13, line 51
The MAC Mobility Extended Community is encoded as a 8-octet value as The MAC Mobility Extended Community is encoded as a 8-octet value as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x44 | Sub-Type | Reserved=0 | | 0x44 | Sub-Type | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.8 Default Gateway Extended Community
The Default Gateway community is an Extended Community of an Opaque
Type (see 3.3 of rfc4360). It is a transitive community, which means
that the first octet is 0x03. The value of the second octet (Sub-
Type) is 0x030d (Default Gateway) as defined by IANA. The Value field
of this community is reserved (set to 0 by the senders, ignored by
the receivers).
9. Multi-homing Functions 9. Multi-homing Functions
This section discusses the functions, procedures and associated BGP This section discusses the functions, procedures and associated BGP
routes used to support multi-homing in E-VPN. This covers both multi- routes used to support multi-homing in E-VPN. This covers both multi-
homed device (MHD) as well as multi-homed network (MHN) scenarios. homed device (MHD) as well as multi-homed network (MHN) scenarios.
9.1 Multi-homed Ethernet Segment Auto-Discovery 9.1 Multi-homed Ethernet Segment Auto-Discovery
PEs connected to the same Ethernet segment can automatically discover PEs connected to the same Ethernet segment can automatically discover
each other with minimal to no configuration through the exchange of each other with minimal to no configuration through the exchange of
skipping to change at page 18, line 41 skipping to change at page 19, line 9
To alleviate this issue, E-VPN introduces the concept of 'Aliasing'. To alleviate this issue, E-VPN introduces the concept of 'Aliasing'.
Aliasing refers to the ability of an PE to signal that it has Aliasing refers to the ability of an PE to signal that it has
reachability to a given locally attached Ethernet segment, even when reachability to a given locally attached Ethernet segment, even when
it has learnt no MAC addresses from that segment. The Ethernet A-D it has learnt no MAC addresses from that segment. The Ethernet A-D
route per EVI is used to that end. Remote PEs which receive MAC route per EVI is used to that end. Remote PEs which receive MAC
advertisement routes with non-zero ESI SHOULD consider the advertised advertisement routes with non-zero ESI SHOULD consider the advertised
MAC address as reachable via all PEs which have advertised MAC address as reachable via all PEs which have advertised
reachability to the relevant Segment using Ethernet A-D routes with reachability to the relevant Segment using Ethernet A-D routes with
the same ESI (and Ethernet Tag if applicable). the same ESI (and Ethernet Tag if applicable).
This flavor of Ethernet A-D route associated with aliasing can arrive
at target PEs asynchronously relative to the flavor of Ethernet A-D
route associated with split-horizon and mass-withdraw. Therefore, if
Ether A-D route associated with aliasing arrives ahead of the route
associated with mass-withdraw, then former must NOT be processed into
the FIB till the latter arrives. This will take care of corner cases
and race conditions where the Ether A-D route associated with mass-
withdraw is withdrawn but a PE still receives the route associated
with aliasing routes.
9.4.1 Constructing the Ethernet A-D Route per EVI 9.4.1 Constructing the Ethernet A-D Route per EVI
This section describes procedures to construct the Ethernet A-D route This section describes procedures to construct the Ethernet A-D route
when one or more such routes are advertised by an PE for a given EVI. when one or more such routes are advertised by an PE for a given EVI.
This flavor of the Ethernet A-D route is used for aliasing, and This flavor of the Ethernet A-D route is used for aliasing, and
support of this route flavor is OPTIONAL. support of this route flavor is OPTIONAL.
Route-Distinguisher (RD) MUST be set to the RD of the EVI that is Route-Distinguisher (RD) MUST be set to the RD of the EVI that is
advertising the NLRI. An RD MUST be assigned for a given EVI on an advertising the NLRI. An RD MUST be assigned for a given EVI on an
PE. This RD MUST be unique across all EVIs on an PE. It is PE. This RD MUST be unique across all EVIs on an PE. It is
skipping to change at page 26, line 22 skipping to change at page 26, line 50
each IP address. For instance, this may be the case when there are each IP address. For instance, this may be the case when there are
both an IPv4 and an IPv6 address associated with the MAC address. both an IPv4 and an IPv6 address associated with the MAC address.
When the IP address is dissociated with the MAC address, then the MAC When the IP address is dissociated with the MAC address, then the MAC
advertisement route with that particular IP address MUST be advertisement route with that particular IP address MUST be
withdrawn. withdrawn.
When an PE receives an ARP request for an IP address from a CE, and When an PE receives an ARP request for an IP address from a CE, and
if the PE has the MAC address binding for that IP address, the PE if the PE has the MAC address binding for that IP address, the PE
SHOULD perform ARP proxy and respond to the ARP request. SHOULD perform ARP proxy and respond to the ARP request.
Further detailed procedures will be specified in a later version. 11.1 Default Gateway
A PE MAY choose to terminate ARP messages instead of performing ARP
proxy for them. Such scenarios arises when the PE needs to perform
inter-subnet forwarding where each subnet is represented by a
different bridge domain/EVI. In such scenarios the inter-subnet
forwarding is performed at layer 3 and the PE that performs such
function is called the default gateway.
Each PE that acts as a default gateway for a given E-VPN advertises
in the E-VPN control plane its default gateway IP and MAC address
using the MAC advertisement route, and indicates that such route is
associated with the default gateway. This is accomplished by
requiring the route to carry the Default Gateway extended community
defined in [Section 8.8 Default Gateway Extended Community].
Each PE that receives this route and imports it as per procedures
specified in this document follows the procedures in this section
when replying to ARP Requests that it receives if such Requests are
for the IP address in the received E-VPN route.
Each PE that acts as a default gateway for a given E-VPN that
receives this route and imports it as per procedures specified in
this document MUST create MAC forwarding state that enables it to
apply IP forwarding to the packets destined to the MAC address
carried in the route.
12. Handling of Multi-Destination Traffic 12. Handling of Multi-Destination Traffic
Procedures are required for a given PE to send broadcast or multicast Procedures are required for a given PE to send broadcast or multicast
traffic, received from a CE encapsulated in a given Ethernet Tag in traffic, received from a CE encapsulated in a given Ethernet Tag in
an EVI, to all the other PEs that span that Ethernet Tag in the EVI. an EVI, to all the other PEs that span that Ethernet Tag in the EVI.
In certain scenarios, described in section "Processing of Unknown In certain scenarios, described in section "Processing of Unknown
Unicast Packets", a given PE may also need to flood unknown unicast Unicast Packets", a given PE may also need to flood unknown unicast
traffic to other PEs. traffic to other PEs.
skipping to change at page 28, line 24 skipping to change at page 29, line 30
The procedures in this document do not require the PEs to flood The procedures in this document do not require the PEs to flood
unknown unicast traffic to other PEs. If PEs learn CE MAC addresses unknown unicast traffic to other PEs. If PEs learn CE MAC addresses
via a control plane protocol, the PEs can then distribute MAC via a control plane protocol, the PEs can then distribute MAC
addresses via BGP, and all unicast MAC addresses will be learnt prior addresses via BGP, and all unicast MAC addresses will be learnt prior
to traffic to those destinations. to traffic to those destinations.
However, if a destination MAC address of a received packet is not However, if a destination MAC address of a received packet is not
known by the PE, the PE may have to flood the packet. Flooding must known by the PE, the PE may have to flood the packet. Flooding must
take into account "split horizon forwarding" as follows: The take into account "split horizon forwarding" as follows: The
principles behind the following procedures are borrowed from the principles behind the following procedures are borrowed from the
split horizon forwarding rules in VPLS solutions [RFC 4761, RFC split horizon forwarding rules in VPLS solutions [RFC4761] and
4762]. When an PE capable of flooding (say PEx) receives a broadcast [RFC4762]. When an PE capable of flooding (say PEx) receives a
or multicast Ethernet frame, or one with an unknown destination MAC broadcast or multicast Ethernet frame, or one with an unknown
address, it must flood the frame. If the frame arrived from an destination MAC address, it must flood the frame. If the frame
attached CE, PEx must send a copy of the frame to every other arrived from an attached CE, PEx must send a copy of the frame to
attached CE participating in the EVI, on a different ESI than the one every other attached CE participating in the EVI, on a different ESI
it received the frame on, as long as the PE is the DF for the egress than the one it received the frame on, as long as the PE is the DF
ESI. In addition, the PE must flood the frame to all other PEs for the egress ESI. In addition, the PE must flood the frame to all
participating in the EVI. If, on the other hand, the frame arrived other PEs participating in the EVI. If, on the other hand, the frame
from another PE (say PEy), PEx must send a copy of the packet only to arrived from another PE (say PEy), PEx must send a copy of the packet
attached CEs as long as it is the DF for the egress ESI. PEx MUST NOT only to attached CEs as long as it is the DF for the egress ESI. PEx
send the frame to other PEs, since PEy would have already done so. MUST NOT send the frame to other PEs, since PEy would have already
Split horizon forwarding rules apply to broadcast and multicast done so. Split horizon forwarding rules apply to broadcast and
packets, as well as packets to an unknown MAC address. multicast packets, as well as packets to an unknown MAC address.
Whether or not to flood packets to unknown destination MAC addresses Whether or not to flood packets to unknown destination MAC addresses
should be an administrative choice, depending on how learning happens should be an administrative choice, depending on how learning happens
between CEs and PEs. between CEs and PEs.
The PEs in a particular E-VPN may use ingress replication using RSVP- The PEs in a particular E-VPN may use ingress replication using RSVP-
TE P2P LSPs or LDP MP2P LSPs for sending broadcast, multicast and TE P2P LSPs or LDP MP2P LSPs for sending broadcast, multicast and
unknown unicast traffic to other PEs. Or they may use RSVP-TE P2MP or unknown unicast traffic to other PEs. Or they may use RSVP-TE P2MP or
LDP P2MP or LDP MP2MP LSPs for sending such traffic to other PEs. LDP P2MP or LDP MP2MP LSPs for sending such traffic to other PEs.
skipping to change at page 40, line 43 skipping to change at page 42, line 5
version. version.
20. Acknowledgements 20. Acknowledgements
We would like to thank Yakov Rekhter, Pedro Marques, Kaushik Ghosh, We would like to thank Yakov Rekhter, Pedro Marques, Kaushik Ghosh,
Nischal Sheth, Robert Raszuk, Amit Shukla and Nadeem Mohammed for Nischal Sheth, Robert Raszuk, Amit Shukla and Nadeem Mohammed for
discussions that helped shape this document. We would also like to discussions that helped shape this document. We would also like to
thank Han Nguyen for his comments and support of this work. We would thank Han Nguyen for his comments and support of this work. We would
also like to thank Steve Kensil for his review. also like to thank Steve Kensil for his review.
21. References 21. Security Considerations
[E-VPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", draft-sajassi-raggarwa-l2vpn-evpn-req-
00.txt
[RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 22. IANA Considerations
[VPLS-MCAST] "Multicast in VPLS". R. Aggarwal et.al., draft-ietf- 23. References
l2vpn-vpls-mcast-04.txt
23.1 Normative References
[RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007. 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[VPLS-MULTIHOMING] "BGP based Multi-homing in Virtual Private LAN [RFC4271] Y. Rekhter et. al., "A Border Gateway Protocol 4 (BGP-4)",
Service", K. Kompella et. al., draft-ietf-l2vpn-vpls- RFC 4271, January 2006
multihoming-00.txt
[PIM-SNOOPING] "PIM Snooping over VPLS", V. Hemige et. al., draft- [RFC4760] T. Bates et. al., "Multiprotocol Extensions for BGP-4", RFC
ietf-l2vpn-vpls-pim-snooping-01 4760, January 2007
[IGMP-SNOOPING] "Considerations for Internet Group Management 23.2 Informative References
Protocol (IGMP) and Multicast Listener Discovery (MLD)
Snooping Switches", M. Christensen et. al., RFC4541, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", draft-ietf-l2vpn-evpn-req-01.txt
[VPLS-MCAST] "Multicast in VPLS". R. Aggarwal et.al., draft-ietf-
l2vpn-vpls-mcast-11.txt
[RT-CONSTRAIN] P. Marques et. al., "Constrained Route Distribution [RT-CONSTRAIN] P. Marques et. al., "Constrained Route Distribution
for Border Gateway Protocol/MultiProtocol Label Switching for 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
[EVPN-SEGMENT-ROUTE] A. Sajassi et. al., "E-VPN Ethernet Segment [BGP-VPLS-MH] "BGP based Multi-homing in Virtual Private LAN
Route", draft-sajassi-l2vpn-evpn-segment-route-00.txt, Service", K. Kompella et. al., draft-ietf-l2vpn-vpls-
work in progress. multihoming-04.txt
21. Author's Address
Rahul Aggarwal 24. Author's Address
Email: raggarwa_1@yahoo.com
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive
San Jose, CA 95134, US
Email: sajassi@cisco.com Email: sajassi@cisco.com
Rahul Aggarwal
Email: raggarwa_1@yahoo.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
e-mail: wim.henderickx@alcatel-lucent.com e-mail: wim.henderickx@alcatel-lucent.com
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
Email: aisaac71@bloomberg.net Email: aisaac71@bloomberg.net
James Uttaro James Uttaro
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: uttaro@att.com Email: uttaro@att.com
skipping to change at page 42, line 43 skipping to change at page 44, line 16
Email: keyupate@cisco.com Email: keyupate@cisco.com
Sami Boutros Sami Boutros
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134, US
Email: sboutros@cisco.com Email: sboutros@cisco.com
Samer Salam Samer Salam
Cisco Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com Email: ssalam@cisco.com
John Drake
Juniper Networks
Email: jdrake@juniper.net
 End of changes. 33 change blocks. 
99 lines changed or deleted 164 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/