draft-ietf-bess-evpn-usage-05.txt   draft-ietf-bess-evpn-usage-06.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: February 18, 2018 August 17, 2017 Expires: March 1, 2018 August 28, 2017
Usage and applicability of BGP MPLS based Ethernet VPN Usage and applicability of BGP MPLS based Ethernet VPN
draft-ietf-bess-evpn-usage-05 draft-ietf-bess-evpn-usage-06
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 Status of this Memo This Internet-Draft is submitted in full conformance
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."
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 February 18, 2018. This Internet-Draft will expire on March 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 6, line 27 skipping to change at page 6, line 27
CE2 and CE3. As in the EVI200 case, an N:1 VLAN-to-EVI mapping is CE2 and CE3. As in the EVI200 case, an N:1 VLAN-to-EVI mapping is
created at the ingress PEs, however in this case, a separate created at the ingress PEs, however in this case, a separate
broadcast domain is required per CE-VID. The CE-VIDs can be broadcast domain is required per CE-VID. The CE-VIDs can be
different (hence CE-VID translation is required). different (hence CE-VID translation is required).
NOTE: in section 4.2.1, only EVI100 is used as an example of NOTE: in section 4.2.1, only EVI100 is used as an example of
VLAN-based service provisioning. In sections 6.2 and 7.2, 4k VLAN-based service provisioning. In sections 6.2 and 7.2, 4k
VLAN-based EVIs (EVI1 to EVI4k) are used so that the impact of MAC VLAN-based EVIs (EVI1 to EVI4k) are used so that the impact of MAC
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-4 and 7.3-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 on 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
VPLS solutions based on [RFC4761][RFC4762][RFC6074] cannot meet the VPLS solutions based on [RFC4761], [RFC4762] and [RFC6074] cannot
requirements in section 2, whereas EVPN can. meet the requirements in section 3, whereas EVPN can.
For example: For example:
o If CE2 has a single CE-VID (or a few CE-VIDs) the current VPLS o If CE2 has a single CE-VID (or a few CE-VIDs) the current VPLS
multi-homing solutions (based on load-balancing per CE-VID or multi-homing solutions (based on load-balancing per CE-VID or
service) do not provide the optimized link utilization required in service) do not provide the optimized link utilization required in
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.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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 In regards 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 2, 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) the
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
skipping to change at page 18, line 47 skipping to change at page 18, line 47
imported by the three PEs. Note that if CE-VID translation is imported by the three PEs. Note that if CE-VID translation is
required, an A-D per EVI route is required per Ethernet-Tag (4k). required, an A-D per EVI route is required per Ethernet-Tag (4k).
6.4.2. Packet Walkthrough 6.4.2. Packet Walkthrough
The packet walkthrough for the VLAN-aware case is similar to the one The packet walkthrough for the VLAN-aware case is similar to the one
described before. Compared to the other two cases, VLAN-aware described before. Compared to the other two cases, VLAN-aware
services allow for CE-VID translation and for an N:1 CE-VID to EVI services allow for CE-VID translation and for an N:1 CE-VID to EVI
mapping. Both things are not supported at once in either of the two mapping. Both things are not supported at once in either of the two
other service interfaces. Some differences compared to the packet other service interfaces. Some differences compared to the packet
walkthrough described in section 5.2.2 are: walkthrough described in section 6.2.2 are:
o At the ingress PE, the frames are identified to be forwarded in the o At the ingress PE, the frames are identified to be forwarded in the
EVI300 context as long as their CE-VID belong to the range defined EVI300 context as long as their CE-VID belong to the range defined
in the PE port to the CE. In addition to it, CE-VID=x is mapped to in the PE port to the CE. In addition to it, CE-VID=x is mapped to
a "normalized" Ethernet-Tag=y at the MAC-VRF-300 (where x and y a "normalized" Ethernet-Tag=y at the MAC-VRF-300 (where x and y
might be equal if no translation is needed). Qualified learning is might be equal if no translation is needed). Qualified learning is
now required (a different Bridge Table is allocated within MAC- now required (a different Bridge Table is allocated within MAC-
VRF-300 for each Ethernet-Tag). Potentially the same MAC could be VRF-300 for each Ethernet-Tag). Potentially the same MAC could be
learned in two different Ethernet-Tag Bridge Tables of the same learned in two different Ethernet-Tag Bridge Tables of the same
MAC-VRF. MAC-VRF.
skipping to change at page 19, line 35 skipping to change at page 19, line 35
o At the egress PE, Ethernet-Tag=y, for a given broadcast domain o At the egress PE, Ethernet-Tag=y, for a given broadcast domain
within MAC-VRF-300, can be translated to egress CE-VID=x. That is within MAC-VRF-300, can be translated to egress CE-VID=x. That is
not possible for VLAN-bundle interfaces. It is possible for VLAN- not possible for VLAN-bundle interfaces. It is possible for VLAN-
based interfaces, but it requires a separate MAC-VRF per CE-VID. based interfaces, but it requires a separate MAC-VRF per CE-VID.
7. MPLS-based forwarding model use-case 7. MPLS-based forwarding model use-case
EVPN supports an alternative forwarding model, usually referred to as EVPN supports an alternative forwarding model, usually referred to as
MPLS-based forwarding or disposition model as opposed to the MPLS-based forwarding or disposition model as opposed to the
MAC-based forwarding or disposition model described in section 5. MAC-based forwarding or disposition model described in section 6.
Using MPLS-based forwarding model instead of MAC-based model might Using MPLS-based forwarding model instead of MAC-based model might
have an impact on: have an impact on:
o The number of forwarding states required. o The number of forwarding states required.
o The FIB where the forwarding states are handled: MAC FIB or MPLS o The FIB where the forwarding states are handled: MAC FIB or MPLS
LFIB. LFIB.
The MPLS-based forwarding model avoids the destination MAC lookup at The MPLS-based forwarding model avoids the destination MAC lookup at
the egress PE MAC FIB, at the expense of increasing the number of the egress PE MAC FIB, at the expense of increasing the number of
skipping to change at page 23, line 26 skipping to change at page 23, line 26
| Egress PE Lookups | 2 (MPLS+MAC) | 1 (MPLS) | | Egress PE Lookups | 2 (MPLS+MAC) | 1 (MPLS) |
+-----------------------------+----------------+----------------+ +-----------------------------+----------------+----------------+
The egress forwarding model is an implementation local to the egress The egress forwarding model is an implementation local to the egress
PE and is independent of the model supported on the rest of the PEs, PE and is independent of the model supported on the rest of the PEs,
i.e. in our use-case, PE1, PE2 and PE3 could have either egress i.e. in our use-case, PE1, PE2 and PE3 could have either egress
forwarding model without any dependencies. forwarding model without any dependencies.
9. Traffic flow optimization 9. Traffic flow optimization
In addition to the procedures described across sections 1 through 8, In addition to the procedures described across sections 3 through 8,
EVPN [RFC7432] procedures allow for optimized traffic handling in EVPN [RFC7432] procedures allow for optimized traffic handling in
order to minimize unnecessary flooding across the entire order to minimize unnecessary flooding across the entire
infrastructure. Optimization is provided through specific ARP infrastructure. Optimization is provided through specific ARP
termination and the ability to block unknown unicast flooding. termination and the ability to block unknown unicast flooding.
Additionally, EVPN procedures allow for intelligent, close to the Additionally, EVPN procedures allow for intelligent, close to the
source, inter-subnet forwarding and solves the commonly known sub- source, inter-subnet forwarding and solves the commonly known sub-
optimal routing problem. Besides the traffic efficiency, ingress optimal routing problem. Besides the traffic efficiency, ingress
based inter-subnet forwarding also optimizes packet forwarding rules based inter-subnet forwarding also optimizes packet forwarding rules
and implementation at the egress nodes as well. Details of these and implementation at the egress nodes as well. Details of these
procedures are outlined in sections 9.1 and 9.2. procedures are outlined in sections 9.1 and 9.2.
skipping to change at page 26, line 11 skipping to change at page 26, line 11
can happen locally. When the packet is received at the egress PE, it can happen locally. When the packet is received at the egress PE, it
is directly mapped to an egress MAC-VRF, bypassing any egress IP-VPN is directly mapped to an egress MAC-VRF, bypassing any egress IP-VPN
processing. processing.
Please refer to [EVPN-INTERSUBNET] for more information about the IP Please refer to [EVPN-INTERSUBNET] for more information about the IP
inter-subnet forwarding procedures in EVPN. inter-subnet forwarding procedures in EVPN.
9.2. Packet Walkthrough Examples 9.2. Packet Walkthrough Examples
Assuming that the services are setup according to figure 1 in section Assuming that the services are setup according to figure 1 in section
2, the following flow optimization processes will take place in terms 3, the following flow optimization processes will take place in terms
of creating, receiving and forwarding packets across the network. of creating, receiving and forwarding packets across the network.
9.2.1. Proxy-ARP example for CE2 to CE3 traffic 9.2.1. Proxy-ARP example for CE2 to CE3 traffic
Using Figure 1 in section 2, consider EVI 400 residing on PE1, PE2 Using Figure 1 in section 3, consider EVI 400 residing on PE1, PE2
and PE3 connecting CE2 and CE3 networks. Also, consider that PE1 and and PE3 connecting CE2 and CE3 networks. Also, consider that PE1 and
PE2 are part of the all-active multi-homing ES for CE2, and that PE2 PE2 are part of the all-active multi-homing ES for CE2, and that PE2
is elected designated-forwarder for EVI400. We assume that all the is elected designated-forwarder for EVI400. We assume that all the
PEs implement the proxy-ARP functionality in the MAC-VRF-400 context. PEs implement the proxy-ARP functionality in the MAC-VRF-400 context.
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
skipping to change at page 26, line 44 skipping to change at page 26, line 44
CE3, and that the IP address in the ARP message matches the entry in CE3, and that the IP address in the ARP message matches the entry in
the table, PE2 will respond to the ARP request with the actual MAC the table, PE2 will respond to the ARP request with the actual MAC
address on behalf of the node behind CE3. 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 2, 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
the network devices behind CE3 come online they will learn their MAC the network devices behind CE3 come online they will learn their MAC
addresses and create local FIB entries for these devices. Note that addresses and create local FIB entries for these devices. Note that
local FIB entries could also be created through either a control or local FIB entries could also be created through either a control or
management plane between PE and CE as well. Consequently, PE3 will management plane between PE and CE as well. Consequently, PE3 will
automatically create EVPN Type 2 MAC Advertisement Routes and automatically create EVPN Type 2 MAC Advertisement Routes and
advertise all locally learned MAC addresses. The routes will also advertise all locally learned MAC addresses. The routes will also
include the corresponding MPLS label. include the corresponding MPLS label.
skipping to change at page 27, line 29 skipping to change at page 27, line 29
Based on the assumption that all the MAC entries behind the CEs are Based on the assumption that all the MAC entries behind the CEs are
pre-populated through gratuitous-ARP and/or DHCP requests, if one pre-populated through gratuitous-ARP and/or DHCP requests, if one
specific MAC entry is not present in the MAC-VRF-500 FIB on PE1, the specific MAC entry is not present in the MAC-VRF-500 FIB on PE1, the
owner of that MAC is not alive on the network behind the CE3, hence owner of that MAC is not alive on the network behind the CE3, hence
the traffic can be dropped at PE1 instead of be flooded and consume the traffic can be dropped at PE1 instead of be flooded and consume
network bandwidth. network bandwidth.
9.2.3. Optimization of inter-subnet forwarding example for CE3 to CE2 9.2.3. Optimization of inter-subnet forwarding example for CE3 to CE2
traffic traffic
Using Figure 1 in section 2 consider that there is an IP-VPN 666 Using Figure 1 in section 3 consider that there is an IP-VPN 666
context residing on PE1, PE2 and PE3 which connects CE1, CE2 and CE3 context residing on PE1, PE2 and PE3 which connects CE1, CE2 and CE3
into a single IP-VPN domain. Also consider that there are two EVIs into a single IP-VPN domain. Also consider that there are two EVIs
present on the PEs, EVI 600 and EVI 60. Each IP subnet is associated present on the PEs, EVI 600 and EVI 60. Each IP subnet is associated
to a different MAC-VRF context. Thus there is a single subnet, subnet to a different MAC-VRF context. Thus there is a single subnet, subnet
600, between CE1 and CE3 that is established through EVI 600. 600, between CE1 and CE3 that is established through EVI 600.
Similarly, there is another subnet, subnet 60, between CE2 and CE3 Similarly, there is another subnet, subnet 60, between CE2 and CE3
that is established through EVI 60. Since both subnets are part of that is established through EVI 60. Since both subnets are part of
the same IP VPN, there is a mapping of each EVI (or individual the same IP VPN, there is a mapping of each EVI (or individual
subnet) to a local IRB interface on the three PEs. subnet) to a local IRB interface on the three PEs.
skipping to change at page 28, line 47 skipping to change at page 28, line 47
Please refer to the "Security Considerations" section in [RFC7432]. Please refer to the "Security Considerations" section in [RFC7432].
11. IANA Considerations 11. IANA Considerations
No new IANA considerations are needed. No new IANA considerations are needed.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC4761]Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling",
DOI 10.17487/RFC4761, January 2007, <http://www.rfc- RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-
editor.org/info/rfc4761>. editor.org/info/rfc4761>.
[RFC4762]Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>. <http://www.rfc-editor.org/info/rfc4762>.
[RFC6074]Rosen, E., Davie, B., Radoaca, V., and W. Luo, [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual
Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January
2011, <http://www.rfc-editor.org/info/rfc6074>. 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC4364]Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
<http://www.rfc-editor.org/info/rfc4364>. <http://www.rfc-editor.org/info/rfc4364>.
[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>.
[RFC7117]Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)",
RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc- RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-
editor.org/info/rfc7117>. editor.org/info/rfc7117>.
[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-
editor.org/info/rfc7432>. editor.org/info/rfc7432>.
12.2. Informative References 12.2. Informative References
[EVPN-INTERSUBNET] Sajassi et al., "IP Inter-subnet forwarding in [EVPN-INTERSUBNET] Sajassi et al., "IP Inter-subnet forwarding in
EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt
13. Acknowledgments 13. Acknowledgments
 End of changes. 21 change blocks. 
28 lines changed or deleted 26 lines changed or added

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