draft-ietf-bess-evpn-usage-07.txt   draft-ietf-bess-evpn-usage-08.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft S. Palislamovic Internet Draft S. Palislamovic
W. Henderickx W. Henderickx
Intended status: Informational Nokia Intended status: Informational Nokia
A. Sajassi A. Sajassi
Cisco Cisco
J. Uttaro J. Uttaro
AT&T AT&T
Expires: August 2, 2018 January 29, 2018 Expires: August 20, 2018 February 16, 2018
Usage and applicability of BGP MPLS based Ethernet VPN Usage and applicability of BGP MPLS based Ethernet VPN
draft-ietf-bess-evpn-usage-07 draft-ietf-bess-evpn-usage-08
Abstract Abstract
This document discusses the usage and applicability of BGP MPLS based This document discusses the usage and applicability of BGP MPLS based
Ethernet VPN (EVPN) in a simple and fairly common deployment Ethernet VPN (EVPN) in a simple and fairly common deployment
scenario. The different EVPN procedures are explained on the example scenario. The different EVPN procedures are explained on the example
scenario, analyzing the benefits and trade-offs of each option. This scenario, analyzing the benefits and trade-offs of each option. This
document is intended to provide a simplified guide for the deployment document is intended to provide a simplified guide for the deployment
of EVPN networks. of EVPN networks.
Status of this Memo This Internet-Draft is submitted in full conformance Status of this Memo
with the provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 2, line 4 skipping to change at page 1, line 42
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 2, 2018. This Internet-Draft will expire on August 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use-case scenario description and requirements . . . . . . . . 4 3. Use-case scenario description and requirements . . . . . . . . 4
3.1. Service Requirements . . . . . . . . . . . . . . . . . . . 5 3.1. Service Requirements . . . . . . . . . . . . . . . . . . . 5
3.2. Why EVPN is chosen to address this use-case . . . . . . . . 6 3.2. Why EVPN is chosen to address this use-case . . . . . . . . 6
4. Provisioning Model . . . . . . . . . . . . . . . . . . . . . . 7 4. Provisioning Model . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Common provisioning tasks . . . . . . . . . . . . . . . . . 7 4.1. Common provisioning tasks . . . . . . . . . . . . . . . . . 7
4.1.1. Non-service specific parameters . . . . . . . . . . . . 7 4.1.1. Non-service specific parameters . . . . . . . . . . . . 7
4.1.2. Service specific parameters . . . . . . . . . . . . . . 8 4.1.2. Service specific parameters . . . . . . . . . . . . . . 8
4.2. Service interface dependent provisioning tasks . . . . . . 9 4.2. Service interface dependent provisioning tasks . . . . . . 9
4.2.1. VLAN-based service interface EVI . . . . . . . . . . . 9 4.2.1. VLAN-based service interface EVI . . . . . . . . . . . 9
4.2.2. VLAN-bundle service interface EVI . . . . . . . . . . . 10 4.2.2. VLAN-bundle service interface EVI . . . . . . . . . . . 10
skipping to change at page 3, line 29 skipping to change at page 3, line 21
9.1.1. MAC learning options . . . . . . . . . . . . . . . . . 23 9.1.1. MAC learning options . . . . . . . . . . . . . . . . . 23
9.1.2. Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . 24 9.1.2. Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . 24
9.1.3. Unknown Unicast flooding suppression . . . . . . . . . 25 9.1.3. Unknown Unicast flooding suppression . . . . . . . . . 25
9.1.4. Optimization of Inter-subnet forwarding . . . . . . . . 25 9.1.4. Optimization of Inter-subnet forwarding . . . . . . . . 25
9.2. Packet Walkthrough Examples . . . . . . . . . . . . . . . . 26 9.2. Packet Walkthrough Examples . . . . . . . . . . . . . . . . 26
9.2.1. Proxy-ARP example for CE2 to CE3 traffic . . . . . . . 26 9.2.1. Proxy-ARP example for CE2 to CE3 traffic . . . . . . . 26
9.2.2. Flood suppression example for CE1 to CE3 traffic . . . 26 9.2.2. Flood suppression example for CE1 to CE3 traffic . . . 26
9.2.3. Optimization of inter-subnet forwarding example for 9.2.3. Optimization of inter-subnet forwarding example for
CE3 to CE2 traffic . . . . . . . . . . . . . . . . . . 27 CE3 to CE2 traffic . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document complements [RFC7432] by discussing the applicability This document complements [RFC7432] by discussing the applicability
of the technology in a simple and fairly common deployment scenario, of the technology in a simple and fairly common deployment scenario,
which is described in section 3. which is described in section 3.
After describing the topology and requirements of the use-case After describing the topology and requirements of the use-case
scenario, section 4 will describe the provisioning model. scenario, section 4 will describe the provisioning model.
skipping to change at page 4, line 45 skipping to change at page 4, line 36
o CE1-IP, CE2-IP and CE3-IP refer to IP addresses associated to the o CE1-IP, CE2-IP and CE3-IP refer to IP addresses associated to the
above MAC addresses. above MAC addresses.
o LACP: Link Aggregation Control Protocol. o LACP: Link Aggregation Control Protocol.
o RD: Route Distinguisher. o RD: Route Distinguisher.
o RT: Route Target. o RT: Route Target.
o PE: Provider Edge router.
o AS: Autonomous System.
o PE-IP: it refers to the IP address of a given PE.
3. Use-case scenario description and requirements 3. Use-case scenario description and requirements
Figure 1 depicts the scenario that will be referenced throughout the Figure 1 depicts the scenario that will be referenced throughout the
rest of the document. rest of the document.
+--------------+ +--------------+
| | | |
+----+ +----+ | | +----+ +----+ +----+ +----+ | | +----+ +----+
| CE1|-----| | | | | |---| CE3| | CE1|-----| | | | | |---| CE3|
+----+ /| PE1| | IP/MPLS | | PE3| +----+ +----+ /| PE1| | IP/MPLS | | PE3| +----+
skipping to change at page 5, line 34 skipping to change at page 5, line 34
3.1. Service Requirements 3.1. Service Requirements
The following service requirements are assumed in this scenario: The following service requirements are assumed in this scenario:
o Redundancy requirements: o Redundancy requirements:
- CE2 requires multi-homing connectivity to PE1 and PE2, not only - CE2 requires multi-homing connectivity to PE1 and PE2, not only
for redundancy purposes, but also for adding more for redundancy purposes, but also for adding more
upstream/downstream connectivity bandwidth to/from the network. upstream/downstream connectivity bandwidth to/from the network.
- Fast convergence. E.g.: if the link between CE2 and PE1 goes - Fast convergence. For example: if the link between CE2 and PE1
down, a fast convergence mechanism must be supported so that PE3 goes down, a fast convergence mechanism must be supported so that
can immediately send the traffic to PE2, irrespectively of the PE3 can immediately send the traffic to PE2, irrespective of the
number of affected services and MAC addresses. number of affected services and MAC addresses.
o Service interface requirements: o Service interface requirements:
- The service definition must be flexible in terms of CE-VID-to- - The service definition must be flexible in terms of CE-VID-to-
broadcast-domain assignment in the core. broadcast-domain assignment in the core.
- The following three EVI services are required in this example: - The following three EVI services are required in this example:
EVI100 - It uses VLAN-based service interfaces in the three CEs EVI100 - It uses VLAN-based service interfaces in the three CEs
with a 1:1 VLAN-to-EVI mapping. The CE-VIDs at the three CEs can with a 1:1 VLAN-to-EVI mapping. The CE-VIDs at the three CEs can
be the same, e.g.: VID 100, or different at each CE, e.g.: VID be the same, for example: VID 100, or different at each CE, for
101 in CE1, VID 102 in CE2 and VID 103 in CE3. A single broadcast instance: VID 101 in CE1, VID 102 in CE2 and VID 103 in CE3. A
domain needs to be created for EVI100 in any case; therefore CE- single broadcast domain needs to be created for EVI100 in any
VIDs will require translation at the egress PEs if they are not case; therefore CE-VIDs will require translation at the egress
consistent across the three CEs. The case when the same CE-VID is PEs if they are not consistent across the three CEs. The case
used across the three CEs for EVI100 is referred in [RFC7432] as when the same CE-VID is used across the three CEs for EVI100 is
the "Unique VLAN" EVPN case. This term will be used throughout referred in [RFC7432] as the "Unique VLAN" EVPN case. This term
this document too. will be used throughout this document too.
EVI200 - It uses VLAN-bundle service interfaces in CE1, CE2 and EVI200 - It uses VLAN-bundle service interfaces in CE1, CE2 and
CE3, based on an N:1 VLAN-to-EVI mapping. The operator needs to CE3, based on an N:1 VLAN-to-EVI mapping. The operator needs to
pre-configure a range of CE-VIDs and its mapping to the EVI, and pre-configure a range of CE-VIDs and its mapping to the EVI, and
this mapping should be consistent in all the PEs (no translation this mapping should be consistent in all the PEs (no translation
is supported). A single broadcast domain is created for the is supported). A single broadcast domain is created for the
customer. The customer is responsible of keeping the separation customer. The customer is responsible of keeping the separation
between users in different CE-VIDs. between users in different CE-VIDs.
EVI300 - It uses VLAN-aware bundling service interfaces in CE1, EVI300 - It uses VLAN-aware bundling service interfaces in CE1,
skipping to change at page 6, line 35 skipping to change at page 6, line 35
vs. MPLS disposition models in the control plane can be evaluated. In vs. MPLS disposition models in the control plane can be evaluated. In
the same way, EVI200 and EVI300 will be described with a 4k:1 mapping the same way, EVI200 and EVI300 will be described with a 4k:1 mapping
(CE-VIDs-to-EVI mapping) in sections 6.3, 6.4, 7.3 and 7.4. (CE-VIDs-to-EVI mapping) in sections 6.3, 6.4, 7.3 and 7.4.
o BUM (Broadcast, Unknown unicast, Multicast) optimization o BUM (Broadcast, Unknown unicast, Multicast) optimization
requirements: requirements:
- The solution must support ingress replication or P2MP MPLS LSPs - The solution must support ingress replication or P2MP MPLS LSPs
on a per EVI service. on a per EVI service.
- For example, we can use ingress replication for on EVI100 and - For example, we can use ingress replication for EVI100 and
EVI200, assuming those EVIs will not carry much BUM traffic. On EVI200, assuming those EVIs will not carry much BUM traffic. On
the contrary, if EVI300 is presumably carrying a significant the contrary, if EVI300 is presumably carrying a significant
amount of multicast traffic, P2MP MPLS LSPs can be used for this amount of multicast traffic, P2MP MPLS LSPs can be used for this
service. service.
- The benefit of ingress replication compared to P2MP LSPs is that - The benefit of ingress replication compared to P2MP LSPs is that
the core routers will not need to maintain any multicast states. the core routers will not need to maintain any multicast states.
3.2. Why EVPN is chosen to address this use-case 3.2. Why EVPN is chosen to address this use-case
skipping to change at page 7, line 18 skipping to change at page 7, line 18
this example. EVPN provides the flow-based load-balancing this example. EVPN provides the flow-based load-balancing
multi-homing solution required in this scenario to optimize the multi-homing solution required in this scenario to optimize the
upstream/downstream link utilization between CE2 and PE1-PE2. upstream/downstream link utilization between CE2 and PE1-PE2.
o Also, EVPN provides a fast convergence solution that is independent o Also, EVPN provides a fast convergence solution that is independent
of the CE-VIDs in the multi-homed PEs. Upon failure on the link of the CE-VIDs in the multi-homed PEs. Upon failure on the link
between CE2 and PE1, PE3 can immediately send the traffic to PE2, between CE2 and PE1, PE3 can immediately send the traffic to PE2,
based on a single notification message being sent by PE1. This is based on a single notification message being sent by PE1. This is
not possible with VPLS solutions. not possible with VPLS solutions.
o In regards to service interfaces and mapping to broadcast domains, o With regard to service interfaces and mapping to broadcast domains,
while VPLS might meet the requirements for EVI100 and EVI200, the while VPLS might meet the requirements for EVI100 and EVI200, the
VLAN-aware bundling service interfaces required by EVI300 are not VLAN-aware bundling service interfaces required by EVI300 are not
supported by the current VPLS tools. supported by the current VPLS tools.
The rest of the document will describe how EVPN can be used to meet The rest of the document will describe how EVPN can be used to meet
the service requirements described in section 3, and even optimize the service requirements described in section 3, and even optimize
the network further by: the network further by:
o Providing the user with an option to reduce (and even suppress) the o Providing the user with an option to reduce (and even suppress)
ARP-flooding. ARP-flooding.
o Supporting ARP termination and inter-subnet-forwarding. o Supporting ARP termination and inter-subnet-forwarding.
4. Provisioning Model 4. Provisioning Model
One of the requirements stated in [RFC7209] is the ease of One of the requirements stated in [RFC7209] is the ease of
provisioning. BGP parameters and service context parameters should be provisioning. BGP parameters and service context parameters should be
auto-provisioned so that the addition of a new MAC-VRF to the EVI auto-provisioned so that the addition of a new MAC-VRF to the EVI
requires a minimum number of single-sided provisioning touches. requires a minimum number of single-sided provisioning touches.
However this is only possible in a limited number of cases. This However this is possible only in a limited number of cases. This
section describes the provisioning tasks required for the services section describes the provisioning tasks required for the services
described in section 3, i.e. EVI100 (VLAN-based service interfaces), described in section 3, i.e. EVI100 (VLAN-based service interfaces),
EVI200 (VLAN-bundle service interfaces) and EVI300 (VLAN-aware EVI200 (VLAN-bundle service interfaces) and EVI300 (VLAN-aware
bundling service interfaces). bundling service interfaces).
4.1. Common provisioning tasks 4.1. Common provisioning tasks
Regardless of the service interface type (VLAN-based, VLAN-bundle or Regardless of the service interface type (VLAN-based, VLAN-bundle or
VLAN-aware), the following sub-sections describe the parameters to be VLAN-aware), the following sub-sections describe the parameters to be
provisioned in the three PEs. provisioned in the three PEs.
4.1.1. Non-service specific parameters 4.1.1. Non-service specific parameters
The multi-homing function in EVPN requires the provisioning of The multi-homing function in EVPN requires the provisioning of
certain parameters which are not service-specific and that are shared certain parameters that are not service-specific and that are shared
by all the MAC-VRFs in the node using the multi-homing capabilities. by all the MAC-VRFs in the node using the multi-homing capabilities.
In our use-case, these parameters are only provisioned or auto- In our use-case, these parameters are only provisioned or auto-
derived in PE1 and PE2, and are listed below: derived in PE1 and PE2, and are listed below:
o Ethernet Segment Identifier (ESI): only the ESI associated to CE2 o Ethernet Segment Identifier (ESI): only the ESI associated to CE2
needs to be considered in our example. Single-homed CEs such as CE1 needs to be considered in our example. Single-homed CEs such as CE1
and CE3 do not require the provisioning of an ESI (the ESI will be and CE3 do not require the provisioning of an ESI (the ESI will be
coded as zero in the BGP NLRIs). In our example, a LAG is used coded as zero in the BGP NLRIs). In our example, a LAG is used
between CE2 and PE1-PE2 (since all-active multi-homing is a between CE2 and PE1-PE2 (since all-active multi-homing is a
requirement) therefore the ESI can be auto-derived from the LACP requirement) therefore the ESI can be auto-derived from the LACP
information as described in [RFC7432]. Note that the ESI must be information as described in [RFC7432]. Note that the ESI must be
unique across all the PEs in the network, therefore the unique across all the PEs in the network, therefore the
auto-provisioning of the ESI is only recommended in case the CEs auto-provisioning of the ESI is recommended only in case the CEs
are managed by the Operator. Otherwise the ESI should be manually are managed by the Operator. Otherwise the ESI should be manually
provisioned (type 0 as in [RFC7432]) in order to avoid potential provisioned (type 0 as in [RFC7432]) in order to avoid potential
conflicts. conflicts.
o ES-Import Route Target (ES-Import RT): this is the RT that will be o ES-Import Route Target (ES-Import RT): this is the RT that will be
sent by PE1 and PE2, along with the ES route. Regardless of how the sent by PE1 and PE2, along with the ES route. Regardless of how the
ESI is provisioned in PE1 and PE2, the ES-Import RT must always be ESI is provisioned in PE1 and PE2, the ES-Import RT must always be
auto-derived from the 6-byte MAC address portion of the ESI value. auto-derived from the 6-byte MAC address portion of the ESI value.
o Ethernet Segment Route Distinguisher (ES RD): this is the RD to be o Ethernet Segment Route Distinguisher (ES RD): this is the RD to be
skipping to change at page 8, line 40 skipping to change at page 8, line 40
be sent by PE1 and PE2 for the CE2 ESI. This RD should always be be sent by PE1 and PE2 for the CE2 ESI. This RD should always be
auto-derived from the PE IP address, as described in [RFC7432]. auto-derived from the PE IP address, as described in [RFC7432].
o Multi-homing type: the user must be able to provision the o Multi-homing type: the user must be able to provision the
multi-homing type to be used in the network. In our use-case, the multi-homing type to be used in the network. In our use-case, the
multi-homing type will be set to all-active for the CE2 ESI. This multi-homing type will be set to all-active for the CE2 ESI. This
piece of information is encoded in the ESI Label extended community piece of information is encoded in the ESI Label extended community
flags and sent by PE1 and PE2 along with the Ethernet A-D route for flags and sent by PE1 and PE2 along with the Ethernet A-D route for
the CE2 ESI. the CE2 ESI.
In our use-case, besides the above parameters, the same LACP In addition, the same LACP parameters will be configured in PE1 and
parameters will be configured in PE1 and PE2 for the ESI, so that CE2 PE2 for the ES so that CE2 can send frames to PE1 and PE2 as though
can send different flows to PE1 and PE2 for the same CE-VID as though they were forming a single system.
they were forming a single system from the CE2 perspective.
4.1.2. Service specific parameters 4.1.2. Service specific parameters
The following parameters must be provisioned in PE1, PE2 and PE3 per The following parameters must be provisioned in PE1, PE2 and PE3 per
EVI service: EVI service:
o EVI identifier: global identifier per EVI that is shared by all the o EVI identifier: global identifier per EVI that is shared by all the
PEs part of the EVI, i.e. PE1, PE2 and PE3 will be provisioned with PEs part of the EVI, i.e. PE1, PE2 and PE3 will be provisioned with
EVI100, 200 and 300. The EVI identifier can be associated to (or be EVI100, 200 and 300. The EVI identifier can be associated to (or be
the same value as) the EVI default Ethernet Tag (4-byte default the same value as) the EVI default Ethernet Tag (4-byte default
skipping to change at page 9, line 36 skipping to change at page 9, line 35
4.2. Service interface dependent provisioning tasks 4.2. Service interface dependent provisioning tasks
Depending on the service interface type being used in the EVI, a Depending on the service interface type being used in the EVI, a
specific CE-VID binding provisioning must be specified. specific CE-VID binding provisioning must be specified.
4.2.1. VLAN-based service interface EVI 4.2.1. VLAN-based service interface EVI
In our use-case, EVI100 is a VLAN-based service interface EVI. In our use-case, EVI100 is a VLAN-based service interface EVI.
EVI100 can be a "unique-VLAN" service if the CE-VID being used for EVI100 can be a "unique-VLAN" service if the CE-VID being used for
this service in CE1, CE2 and CE3 is identical, e.g. VID 100. In that this service in CE1, CE2 and CE3 is identical, for example VID 100.
case, the VID 100 binding must be provisioned in PE1, PE2 and PE3 for In that case, the VID 100 binding must be provisioned in PE1, PE2 and
EVI100 and the associated port or LAG. The MAC-VRF RD and RT can be PE3 for EVI100 and the associated port or LAG. The MAC-VRF RD and RT
auto-derived from the CE-VID: can be auto-derived from the CE-VID:
o The auto-derived MAC-VRF RD will be a Type 1 RD, as recommended in o The auto-derived MAC-VRF RD will be a Type 1 RD, as recommended in
[RFC7432], and it will be comprised of [PE-IP]:[zero-padded-VID]; [RFC7432], and it will be comprised of [PE-IP]:[zero-padded-VID];
where [PE-IP] is the IP address of the PE (a loopback address) and where [PE-IP] is the IP address of the PE (a loopback address) and
[zero-padded-VID] is a 2-byte value where the low order 12 bits are [zero-padded-VID] is a 2-byte value where the low order 12 bits are
the VID (VID 100 in our example) and the high order 4 bits are the VID (VID 100 in our example) and the high order 4 bits are
zero. zero.
o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded- o The auto-derived MAC-VRF RT will be composed of [AS]:[zero-padded-
VID]; where [AS] is the Autonomous System that the PE belongs to VID]; where [AS] is the Autonomous System that the PE belongs to
skipping to change at page 10, line 24 skipping to change at page 10, line 23
Assuming EVI200 is a VLAN-bundle service interface EVI, and VIDs Assuming EVI200 is a VLAN-bundle service interface EVI, and VIDs
200-250 are assigned to EVI200, the CE-VID bundle 200-250 must be 200-250 are assigned to EVI200, the CE-VID bundle 200-250 must be
provisioned on PE1, PE2 and PE3. Note that this model does not allow provisioned on PE1, PE2 and PE3. Note that this model does not allow
CE-VID translation and the CEs must use the same CE-VIDs for EVI200. CE-VID translation and the CEs must use the same CE-VIDs for EVI200.
No auto-derived EVI RDs or EVI RTs are possible. No auto-derived EVI RDs or EVI RTs are possible.
4.2.3. VLAN-aware bundling service interface EVI 4.2.3. VLAN-aware bundling service interface EVI
If EVI300 is a VLAN-aware bundling service interface EVI, CE-VID If EVI300 is a VLAN-aware bundling service interface EVI, CE-VID
binding to EVI300 does not have to match on the three PEs (only on binding to EVI300 does not have to match on the three PEs (only on
PE1 and PE2, since they are part of the same ES). E.g.: PE1 and PE2 PE1 and PE2, since they are part of the same ES). For example: PE1
CE-VID binding to EVI300 can be set to the range 300-310 and PE3 to and PE2 CE-VID binding to EVI300 can be set to the range 300-310 and
321-330. Note that each individual CE-VID will be assigned to a PE3 to 321-330. Note that each individual CE-VID will be assigned to
different broadcast domain, represented by an Ethernet Tag in the a different broadcast domain, represented by an Ethernet Tag in the
control plane. control plane.
Therefore, besides the CE-VID bundle range bound to EVI300 in each Therefore, besides the CE-VID bundle range bound to EVI300 in each
PE, associations between each individual CE-VID and the corresponding PE, associations between each individual CE-VID and the corresponding
EVPN Ethernet Tag must be provisioned by the user. No auto-derived EVPN Ethernet Tag must be provisioned by the user. No auto-derived
EVI RDs/RTs are possible. EVI RDs/RTs are possible.
5. BGP EVPN NLRI usage 5. BGP EVPN NLRI usage
[RFC7432] defines four different route types and four different [RFC7432] defines four different route types and four different
skipping to change at page 11, line 17 skipping to change at page 11, line 15
+-------------------+---------------+---------------+ +-------------------+---------------+---------------+
| ES | Export/import | N/A | | ES | Export/import | N/A |
| A-D per ESI | Export/import | Import | | A-D per ESI | Export/import | Import |
| A-D per EVI | Export/import | Import | | A-D per EVI | Export/import | Import |
| MAC | Export/import | Export/import | | MAC | Export/import | Export/import |
| Inclusive mcast | Export/import | Export/import | | Inclusive mcast | Export/import | Export/import |
+-------------------+---------------+---------------+ +-------------------+---------------+---------------+
Table 1 - Base EVPN Routes and Export/Import Actions Table 1 - Base EVPN Routes and Export/Import Actions
PE3 is only required to export MAC and Inclusive multicast routes and PE3 is required to export only MAC and Inclusive multicast routes and
be able to import and process A-D routes, as well as MAC and be able to import and process A-D routes, as well as MAC and
Inclusive multicast routes. If PE3 did not support importing and Inclusive multicast routes. If PE3 did not support importing and
processing A-D routes per ESI and per EVI, fast convergence and processing A-D routes per ESI and per EVI, fast convergence and
aliasing functions (respectively) would not be possible in this aliasing functions (respectively) would not be possible in this
use-case. use-case.
6. MAC-based forwarding model use-case 6. MAC-based forwarding model use-case
This section describes how the BGP EVPN routes are exported and This section describes how the BGP EVPN routes are exported and
imported by the PEs in our use-case, as well as how traffic is imported by the PEs in our use-case, as well as how traffic is
skipping to change at page 11, line 44 skipping to change at page 11, line 42
6.1. EVPN Network Startup procedures 6.1. EVPN Network Startup procedures
Before any EVI is provisioned in the network, the following Before any EVI is provisioned in the network, the following
procedures are required: procedures are required:
o Infrastructure setup: the proper MPLS infrastructure must be setup o Infrastructure setup: the proper MPLS infrastructure must be setup
among PE1, PE2 and PE3 so that the EVPN services can make use of among PE1, PE2 and PE3 so that the EVPN services can make use of
P2P and P2MP LSPs. In addition to the MPLS transport, PE1 and PE2 P2P and P2MP LSPs. In addition to the MPLS transport, PE1 and PE2
must be properly configured with the same LACP configuration to must be properly configured with the same LACP configuration to
CE2. Details are provided in [RFC7432]. Once the LAG is properly CE2. Details are provided in [RFC7432]. Once the LAG is properly
setup, the ESI for the CE2 Ethernet Segment, e.g. ESI12, can be setup, the ESI for the CE2 Ethernet Segment, for example ESI12, can
auto-generated by PE1 and PE2 from the LACP information exchanged be auto-generated by PE1 and PE2 from the LACP information
with CE2 (ESI type 1), as discussed in section 4.1. Alternatively, exchanged with CE2 (ESI type 1), as discussed in section 4.1.
the ESI can also be manually provisioned on PE1 and PE2 (ESI type Alternatively, the ESI can also be manually provisioned on PE1 and
0). PE1 and PE2 will auto-configure a BGP policy that will import PE2 (ESI type 0). PE1 and PE2 will auto-configure a BGP policy that
any ES route matching the auto-derived ES-import RT for ESI12. will import any ES route matching the auto-derived ES-import RT for
ESI12.
o Ethernet Segment route exchange and DF election: PE1 and PE2 will o Ethernet Segment route exchange and DF election: PE1 and PE2 will
advertise a BGP Ethernet Segment route for ESI12, where the ESI RD advertise a BGP Ethernet Segment route for ESI12, where the ESI RD
and ES-Import RT will be auto-generated as discussed in section and ES-Import RT will be auto-generated as discussed in section
4.1.1. PE1 and PE2 will import the ES routes of each other and will 4.1.1. PE1 and PE2 will import the ES routes of each other and will
run the DF election algorithm for any existing EVI (if any, at this run the DF election algorithm for any existing EVI (if any, at this
point). PE3 will simply discard the route. Note that the DF point). PE3 will simply discard the route. Note that the DF
election algorithm can support service carving, so that the election algorithm can support service carving, so that the
downstream BUM traffic from the network to CE2 can be load-balanced downstream BUM traffic from the network to CE2 can be load-balanced
across PE1 and PE2 on a per-service basis. across PE1 and PE2 on a per-service basis.
skipping to change at page 14, line 10 skipping to change at page 14, line 10
normally allocated and signaled by the three PEs for MAC normally allocated and signaled by the three PEs for MAC
advertisement routes. Based on the RT, the route is imported by advertisement routes. Based on the RT, the route is imported by
PE2 and PE3 and the forwarding state plus ARP entry are added to PE2 and PE3 and the forwarding state plus ARP entry are added to
their MAC-VRF-1 context. From this moment on, any ARP request from their MAC-VRF-1 context. From this moment on, any ARP request from
CE2 or CE3 destined to CE1-IP, can be directly replied by PE1, PE2 CE2 or CE3 destined to CE1-IP, can be directly replied by PE1, PE2
or PE3 and ARP flooding for CE1-IP is not needed in the core. or PE3 and ARP flooding for CE1-IP is not needed in the core.
c) Since the ARP frame is a broadcast frame, it is forwarded by PE1 c) Since the ARP frame is a broadcast frame, it is forwarded by PE1
using the Inclusive multicast tree for EVI1 (CE-VID=1 tag should using the Inclusive multicast tree for EVI1 (CE-VID=1 tag should
be kept if translation is required). Depending on the type of be kept if translation is required). Depending on the type of
tree, the label stack may vary. E.g. assuming ingress replication, tree, the label stack may vary. For example assuming ingress
the packet is replicated to PE2 and PE3 with the downstream replication, the packet is replicated to PE2 and PE3 with the
allocated labels and the P2P LSP transport labels. No other labels downstream allocated labels and the P2P LSP transport labels. No
are added to the stack. other labels are added to the stack.
d) Assuming PE1 is the DF for EVI1 on ESI12, the frame is locally d) Assuming PE1 is the DF for EVI1 on ESI12, the frame is locally
replicated to CE2. replicated to CE2.
e) The MPLS-encapsulated frame gets to PE2 and PE3. Since PE2 is non- e) The MPLS-encapsulated frame gets to PE2 and PE3. Since PE2 is non-
DF for EVI1 on ESI12, and there is no other CE connected to PE2, DF for EVI1 on ESI12, and there is no other CE connected to PE2,
the frame is discarded. At PE3, the frame is de-encapsulated, CE- the frame is discarded. At PE3, the frame is de-encapsulated, CE-
VID translated if needed and forwarded to CE3. VID translated if needed and forwarded to CE3.
Any other type of BUM frame from CE1 would follow the same Any other type of BUM frame from CE1 would follow the same
procedures. BUM frames from CE3 would follow the same procedures too. procedures. BUM frames from CE3 would follow the same procedures too.
(2) BUM frame example from CE2: (2) BUM frame example from CE2:
a) An ARP-request with CE-VID=1 is issued from source MAC CE2-MAC to a) An ARP-request with CE-VID=1 is issued from source MAC CE2-MAC to
find the MAC address of CE3-IP. find the MAC address of CE3-IP.
b) CE2 will hash the frame and will forward it to e.g. PE2. Based on b) CE2 will hash the frame and will forward it to for example PE2.
the CE-VID, the frame is identified to be forwarded in the EVI1 Based on the CE-VID, the frame is identified to be forwarded in
context. A source MAC lookup is done in the MAC FIB and the the EVI1 context. A source MAC lookup is done in the MAC FIB and
sender's CE2-IP in the proxy-ARP table within the MAC-VRF-1 the sender's CE2-IP in the proxy-ARP table within the MAC-VRF-1
context. If both are unknown, three actions are carried out context. If both are unknown, three actions are carried out
(assuming the source MAC is accepted by PE2): (assuming the source MAC is accepted by PE2):
(1) Forwarding state is added for CE2-MAC associated to the (1) Forwarding state is added for CE2-MAC associated to the
corresponding LAG/ESI and CE-VID, corresponding LAG/ESI and CE-VID,
(2) the ARP-request is snooped and the tuple CE2-MAC/CE2-IP is (2) the ARP-request is snooped and the tuple CE2-MAC/CE2-IP is
added to the proxy-ARP table and added to the proxy-ARP table and
(3) a BGP MAC advertisement route is triggered from PE2 containing (3) a BGP MAC advertisement route is triggered from PE2 containing
skipping to change at page 16, line 39 skipping to change at page 16, line 39
either PE (PE2 or PE1), the FIB lookup yields a local ESI12 port either PE (PE2 or PE1), the FIB lookup yields a local ESI12 port
to which the frame is sent. to which the frame is sent.
Unicast frames from CE1 to CE2 follow the same procedures. Unicast frames from CE1 to CE2 follow the same procedures.
6.3. VLAN-bundle service procedures 6.3. VLAN-bundle service procedures
Instead of using VLAN-based interfaces, the Operator can choose to Instead of using VLAN-based interfaces, the Operator can choose to
implement VLAN-bundle interfaces to carry the traffic for the 4k CE- implement VLAN-bundle interfaces to carry the traffic for the 4k CE-
VIDs among CE1, CE2 and CE3. If that is the case, the 4k CE-VIDs can VIDs among CE1, CE2 and CE3. If that is the case, the 4k CE-VIDs can
be mapped to the same EVI, e.g. EVI200, at each PE. The main be mapped to the same EVI, for example EVI200, at each PE. The main
advantage of this approach is the low control plane overhead (reduced advantage of this approach is the low control plane overhead (reduced
number of routes and labels) and easiness of provisioning, at the number of routes and labels) and easiness of provisioning, at the
expense of no control over the customer broadcast domains, i.e. a expense of no control over the customer broadcast domains, i.e. a
single inclusive multicast tree for all the CE-VIDs and no CE-VID single inclusive multicast tree for all the CE-VIDs and no CE-VID
translation in the Provider network. translation in the Provider network.
6.3.1. Service startup procedures 6.3.1. Service startup procedures
As soon as the EVI200 is created in PE1, PE2 and PE3, the following As soon as the EVI200 is created in PE1, PE2 and PE3, the following
control plane actions are carried out: control plane actions are carried out:
skipping to change at page 17, line 51 skipping to change at page 17, line 51
Please refer to section 6.2.2 for more information about the control Please refer to section 6.2.2 for more information about the control
plane and forwarding plane interaction for BUM and unicast traffic plane and forwarding plane interaction for BUM and unicast traffic
from the different CEs. from the different CEs.
6.4. VLAN-aware bundling service procedures 6.4. VLAN-aware bundling service procedures
The last potential service type analyzed in this document is The last potential service type analyzed in this document is
VLAN-aware bundling. When this type of service interface is used to VLAN-aware bundling. When this type of service interface is used to
carry the 4k CE-VIDs among CE1, CE2 and CE3, all the CE-VIDs will be carry the 4k CE-VIDs among CE1, CE2 and CE3, all the CE-VIDs will be
mapped to the same EVI, e.g. EVI300. The difference, compared to the mapped to the same EVI, for example EVI300. The difference, compared
VLAN-bundle service type in the previous section, is that each to the VLAN-bundle service type in the previous section, is that each
incoming CE-VID will also be mapped to a different "normalized" incoming CE-VID will also be mapped to a different "normalized"
Ethernet-Tag in addition to EVI300. If no translation is required, Ethernet-Tag in addition to EVI300. If no translation is required,
the Ethernet-tag will match the CE-VID. Otherwise a translation the Ethernet-tag will match the CE-VID. Otherwise a translation
between CE-VID and Ethernet-tag will be needed at the imposition PE between CE-VID and Ethernet-tag will be needed at the imposition PE
and at the disposition PE. The main advantage of this approach is the and at the disposition PE. The main advantage of this approach is the
ability to control customer broadcast domains while providing a ability to control customer broadcast domains while providing a
single EVI to the customer. single EVI to the customer.
6.4.1. Service startup procedures 6.4.1. Service startup procedures
skipping to change at page 20, line 49 skipping to change at page 20, line 49
o Ethernet A-D routes per EVI (4k routes per PE/ESI): no impact o Ethernet A-D routes per EVI (4k routes per PE/ESI): no impact
compared to the MAC-based model. compared to the MAC-based model.
o MAC-advertisement routes: instead of allocating and advertising the o MAC-advertisement routes: instead of allocating and advertising the
same MPLS label for all the new MACs locally learnt on the same same MPLS label for all the new MACs locally learnt on the same
MAC-VRF, a different label must be advertised per CE next-hop or MAC-VRF, a different label must be advertised per CE next-hop or
MAC so that no MAC FIB lookup is needed at the egress PE. In MAC so that no MAC FIB lookup is needed at the egress PE. In
general, this means that a different label at least per CE must be general, this means that a different label at least per CE must be
advertised, although the PE can decide to implement a label per MAC advertised, although the PE can decide to implement a label per MAC
if more granularity (hence less scalability) is required in terms if more granularity (hence less scalability) is required in terms
of forwarding states. E.g. if CE2 sends traffic from two different of forwarding states. For example if CE2 sends traffic from two
MACs to PE1, CE2-MAC1 and CE2-MAC2, the same MPLS label=x can be different MACs to PE1, CE2-MAC1 and CE2-MAC2, the same MPLS label=x
re-used for both MAC advertisements since they both share the same can be re-used for both MAC advertisements since they both share
source ESI12. It is up to the PE1 implementation to use a different the same source ESI12. It is up to the PE1 implementation to use a
label per individual MAC within the same ES Segment (even if only different label per individual MAC within the same ES Segment (even
one label per ESI is enough). if only one label per ESI is enough).
o PE1, PE2 and PE3 will not add forwarding states to the MAC FIB upon o PE1, PE2 and PE3 will not add forwarding states to the MAC FIB upon
learning new local CE MAC addresses on the data plane, but will learning new local CE MAC addresses on the data plane, but will
rather add forwarding states to the MPLS LFIB. rather add forwarding states to the MPLS LFIB.
7.3. Impact of MPLS-based forwarding on the VLAN-bundle service 7.3. Impact of MPLS-based forwarding on the VLAN-bundle service
procedures procedures
Compared to the MAC-based forwarding model, the MPLS-based forwarding Compared to the MAC-based forwarding model, the MPLS-based forwarding
model has no impact in terms of number of routes when all the service model has no impact in terms of number of routes when all the service
skipping to change at page 25, line 13 skipping to change at page 25, line 13
functionality across all EVI MAC-VRFs. functionality across all EVI MAC-VRFs.
9.1.3. Unknown Unicast flooding suppression 9.1.3. Unknown Unicast flooding suppression
Given that all locally learned MAC addresses are advertised through Given that all locally learned MAC addresses are advertised through
BGP to all remote PEs, suppressing flooding of any Unknown Unicast BGP to all remote PEs, suppressing flooding of any Unknown Unicast
traffic towards the remote PEs is a feasible network optimization. traffic towards the remote PEs is a feasible network optimization.
The assumption in the use case is made that any network device that The assumption in the use case is made that any network device that
appears on a remote MAC-VRF will somehow signal its presence to the appears on a remote MAC-VRF will somehow signal its presence to the
network. This signaling can be done through e.g. gratuitous ARPs. network. This signaling can be done through for example gratuitous
Once the remote PE acknowledges the presence of the node in the MAC- ARPs. Once the remote PE acknowledges the presence of the node in the
VRF, it will do two things: install its MAC address in its local FIB MAC-VRF, it will do two things: install its MAC address in its local
and advertise this MAC address to all other BGP speakers via EVPN FIB and advertise this MAC address to all other BGP speakers via EVPN
NLRI. Therefore, we can assume that any active MAC address is NLRI. Therefore, we can assume that any active MAC address is
propagated and learnt through the entire EVI. Given that MAC propagated and learnt through the entire EVI. Given that MAC
addresses become pre-populated - once nodes are alive on the network addresses become pre-populated - once nodes are alive on the network
- there is no need to flood any unknown unicast towards the remote - there is no need to flood any unknown unicast towards the remote
PEs. If the owner of a given destination MAC is active, the BGP route PEs. If the owner of a given destination MAC is active, the BGP route
will be present in the local RIB and FIB, assuming that the BGP will be present in the local RIB and FIB, assuming that the BGP
import policies are successfully applied; otherwise, the owner of import policies are successfully applied; otherwise, the owner of
such destination MAC is not present on the network. such destination MAC is not present on the network.
It is worth noting that unless: a) control or management plane It is worth noting that unless: a) control or management plane
skipping to change at page 26, line 39 skipping to change at page 26, line 39
In this scenario, PE3 will not only advertise the MAC addresses In this scenario, PE3 will not only advertise the MAC addresses
through the EVPN MAC Advertisement Route but also IP addresses of through the EVPN MAC Advertisement Route but also IP addresses of
individual hosts, i.e. /32 prefixes, behind CE3. Upon receiving the individual hosts, i.e. /32 prefixes, behind CE3. Upon receiving the
EVPN routes, PE1 and PE2 will install the MAC addresses in the MAC- EVPN routes, PE1 and PE2 will install the MAC addresses in the MAC-
VRF-400 FIB and based on the associated received IP addresses, PE1 VRF-400 FIB and based on the associated received IP addresses, PE1
and PE2 can now build a proxy-ARP table within the context of MAC- and PE2 can now build a proxy-ARP table within the context of MAC-
VRF-400. VRF-400.
From the forwarding perspective, when a node behind CE2 sends a frame From the forwarding perspective, when a node behind CE2 sends a frame
destined to a node behind CE3, it will first send an ARP request to destined to a node behind CE3, it will first send an ARP request to
e.g. PE2 (based on the result of the CE2 hashing). Assuming that PE2 for example PE2 (based on the result of the CE2 hashing). Assuming
has populated its proxy-ARP table for all active nodes behind the that PE2 has populated its proxy-ARP table for all active nodes
CE3, and that the IP address in the ARP message matches the entry in behind the CE3, and that the IP address in the ARP message matches
the table, PE2 will respond to the ARP request with the actual MAC the entry in the table, PE2 will respond to the ARP request with the
address on behalf of the node behind CE3. actual MAC address on behalf of the node behind CE3.
Once the nodes behind CE2 learn the actual MAC address of the nodes Once the nodes behind CE2 learn the actual MAC address of the nodes
behind CE3, all the MAC-to-MAC communications between the two behind CE3, all the MAC-to-MAC communications between the two
networks will be unicast. networks will be unicast.
9.2.2. Flood suppression example for CE1 to CE3 traffic 9.2.2. Flood suppression example for CE1 to CE3 traffic
Using Figure 1 in section 3, consider EVI 500 residing on PE1 and PE3 Using Figure 1 in section 3, consider EVI 500 residing on PE1 and PE3
connecting CE1 and CE3 networks. Consider that both PE1 and PE3 have connecting CE1 and CE3 networks. Consider that both PE1 and PE3 have
disabled unknown unicast flooding for this specific EVI context. Once disabled unknown unicast flooding for this specific EVI context. Once
skipping to change at page 28, line 46 skipping to change at page 28, line 46
between PEs is forwarded through EVPN, rather than through IP-VPN. In between PEs is forwarded through EVPN, rather than through IP-VPN. In
the example described above for traffic from EVI 60 on CE2 to EVI 600 the example described above for traffic from EVI 60 on CE2 to EVI 600
on CE3, there is no need for IP-VPN processing on the egress PE3. on CE3, there is no need for IP-VPN processing on the egress PE3.
Traffic is forwarded either to the EVI 600 context in PE3 for further Traffic is forwarded either to the EVI 600 context in PE3 for further
MAC lookup and next-hop processing, or directly to the node behind MAC lookup and next-hop processing, or directly to the node behind
CE3, depending on the egress forwarding model being used. CE3, depending on the egress forwarding model being used.
10. Security Considerations 10. Security Considerations
Please refer to the "Security Considerations" section in [RFC7432]. Please refer to the "Security Considerations" section in [RFC7432].
The standards produced by the SIDR WG address secure route origin
authentication (e.g., RFCs 6480-93) and route advertisement security
(e.g., RFCs 8205-11). They protect the integrity and authenticity of
IP address advertisements and ASN/IP prefix bindings. This document,
and [RFC7432], use BGP to convey other info, e.g., MAC addresses,
and thus the protections offered by the SIDR WG RFCs are not
applicable in this context.
11. IANA Considerations 11. IANA Considerations
No new IANA considerations are needed. No IANA considerations are needed.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)",
RFC 7209, DOI 10.17487/RFC7209, May 2014, <http://www.rfc- RFC 7209, DOI 10.17487/RFC7209, May 2014, <http://www.rfc-
editor.org/info/rfc7209>. editor.org/info/rfc7209>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
 End of changes. 32 change blocks. 
72 lines changed or deleted 89 lines changed or added

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