draft-ietf-bess-evpn-inter-subnet-forwarding-07.txt   draft-ietf-bess-evpn-inter-subnet-forwarding-08.txt 
L2VPN Workgroup A. Sajassi, Ed. BESS Workgroup A. Sajassi, Ed.
INTERNET-DRAFT S. Salam INTERNET-DRAFT S. Salam
Intended Status: Standards Track S. Thoria Intended Status: Standards Track S. Thoria
Cisco Cisco
J. Drake J. Drake
Juniper Juniper
J. Rabadan J. Rabadan
Nokia Nokia
Expires: August 11, 2019 February 11, 2019 Expires: September 4, 2019 March 4, 2019
Integrated Routing and Bridging in EVPN Integrated Routing and Bridging in EVPN
draft-ietf-bess-evpn-inter-subnet-forwarding-07 draft-ietf-bess-evpn-inter-subnet-forwarding-08
Abstract Abstract
EVPN provides an extensible and flexible multi-homing VPN solution EVPN provides an extensible and flexible multi-homing VPN solution
over an MPLS/IP network for intra-subnet connectivity among Tenant over an MPLS/IP network for intra-subnet connectivity among Tenant
Systems and End Devices that can be physical or virtual. However, Systems and End Devices that can be physical or virtual. However,
there are scenarios for which there is a need for a dynamic and there are scenarios for which there is a need for a dynamic and
efficient inter-subnet connectivity among these Tenant Systems and efficient inter-subnet connectivity among these Tenant Systems and
End Devices while maintaining the multi-homing capabilities of EVPN. End Devices while maintaining the multi-homing capabilities of EVPN.
This document describes an Integrated Routing and Bridging (IRB) This document describes an Integrated Routing and Bridging (IRB)
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Copyright and License Notice Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
6.1.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 26 6.1.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 26
6.2 IRB forwarding on NVEs for Subnets behind Tenant Systems . . 27 6.2 IRB forwarding on NVEs for Subnets behind Tenant Systems . . 27
6.2.1 Control Plane Operation . . . . . . . . . . . . . . . . 29 6.2.1 Control Plane Operation . . . . . . . . . . . . . . . . 29
6.2.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 30 6.2.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 30
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 31 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 31
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1 Normative References . . . . . . . . . . . . . . . . . . . 32 10.1 Normative References . . . . . . . . . . . . . . . . . . . 32
10.2 Informative References . . . . . . . . . . . . . . . . . . 32 10.2 Informative References . . . . . . . . . . . . . . . . . . 32
11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 11, line 10 skipping to change at page 11, line 10
VLAN-Aware Bundle mode. Whether the service interface on a PE is VLAN-Aware Bundle mode. Whether the service interface on a PE is
VLAN-Based or VLAN-Aware Bundle mode does not impact the IRB VLAN-Based or VLAN-Aware Bundle mode does not impact the IRB
operation and procedures. It only impacts the setting of Ethernet tag operation and procedures. It only impacts the setting of Ethernet tag
field in EVPN BGP routes as described in [RFC7432]. field in EVPN BGP routes as described in [RFC7432].
PE 1 +---------+ PE 1 +---------+
+-------------+ | | +-------------+ | |
TS1-----| MACx| | | PE2 TS1-----| MACx| | | PE2
(IP1/M1) |(BT1) | | | +-------------+ (IP1/M1) |(BT1) | | | +-------------+
TS5-----| \ | | MPLS/ | |MACy (BT3) |-----TS3 TS5-----| \ | | MPLS/ | |MACy (BT3) |-----TS3
(IP5/M5) |Mx/IPx \ | | VxLAN/ | | / | (IP3/M3) (IP5/M5) |Mx/IPx \ | | VxLAN/ | | / | (IP3/M3)
| (IP-VRF1)|----| NVGRE |---|(IP-VRF1) | | (IP-VRF1)|----| NVGRE |---|(IP-VRF1) |
| / | | | | \ | | / | | | | \ |
TS2-----|(BT2) / | | | | (BT1) |-----TS4 TS2-----|(BT2) / | | | | (BT1) |-----TS4
(IP2/M2) | | | | | | (IP4/M4) (IP2/M2) | | | | | | (IP4/M4)
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---------+ +---------+
Figure 4: IRB forwarding Figure 4: IRB forwarding
3.1 IRB Interface and its MAC & IP addresses 3.1 IRB Interface and its MAC & IP addresses
To support inter-subnet forwarding on a PE, the PE acts as an IP To support inter-subnet forwarding on a PE, the PE acts as an IP
Default Gateway from the perspective of the attached Tenant Systems Default Gateway from the perspective of the attached Tenant Systems
skipping to change at page 17, line 44 skipping to change at page 17, line 44
then the receiving PE MUST ignore MPLS label2 field and install the then the receiving PE MUST ignore MPLS label2 field and install the
MAC address in the corresponding MAC-VRF and <IP, MAC> association in MAC address in the corresponding MAC-VRF and <IP, MAC> association in
the ARP table for that tenant (identified by either MAC-VRF or IP-VRF the ARP table for that tenant (identified by either MAC-VRF or IP-VRF
route target). route target).
If the receiving PE receives the MAC/IP Advertisement route with MPLS If the receiving PE receives the MAC/IP Advertisement route with MPLS
label2 field and it can support symmetric IRB mode, then it should label2 field and it can support symmetric IRB mode, then it should
use the MAC-VRF route target to identify its corresponding MAC-VRF use the MAC-VRF route target to identify its corresponding MAC-VRF
table and import the MAC address. It should use the IP-VRF route table and import the MAC address. It should use the IP-VRF route
target to identify the corresponding IP-VRF table and import the IP target to identify the corresponding IP-VRF table and import the IP
address. It MUST not import <IP, MAC> association into its ARP address. It MUST NOT import <IP, MAC> association into its ARP
table. table.
3.3.3 Data Plane - Ingress PE 3.3.3 Data Plane - Ingress PE
When an Ethernet frame is received by an ingress PE (e.g., PE1 in When an Ethernet frame is received by an ingress PE (e.g., PE1 in
figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify figure 4 above), the PE uses the AC ID (e.g., VLAN ID) to identify
the associated MAC-VRF/BT and it performs a lookup on the destination the associated MAC-VRF/BT and it performs a lookup on the destination
MAC address. If the MAC address corresponds to its IRB Interface MAC MAC address. If the MAC address corresponds to its IRB Interface MAC
address, the ingress PE deduces that the packet must be inter-subnet address, the ingress PE deduces that the packet must be inter-subnet
routed. Hence, the ingress PE performs an IP lookup in the associated routed. Hence, the ingress PE performs an IP lookup in the associated
skipping to change at page 19, line 16 skipping to change at page 19, line 16
properly executed and the corresponding MAC-VRF and IP-VRF tables on properly executed and the corresponding MAC-VRF and IP-VRF tables on
all participating NVEs are updated. [RFC7432] describes the MAC all participating NVEs are updated. [RFC7432] describes the MAC
mobility procedures for L2-only services for both single-homed TS and mobility procedures for L2-only services for both single-homed TS and
multi-homed TS. This section describes the incremental procedures and multi-homed TS. This section describes the incremental procedures and
BGP Extended Communities needed to handle the MAC mobility for IRB. BGP Extended Communities needed to handle the MAC mobility for IRB.
In order to place the emphasis on the differences between L2-only and In order to place the emphasis on the differences between L2-only and
IRB use cases, the incremental procedure is described for single- IRB use cases, the incremental procedure is described for single-
homed TS with the expectation that the reader can easily extrapolate homed TS with the expectation that the reader can easily extrapolate
multi-homed TS based on the procedures described in section 15 of multi-homed TS based on the procedures described in section 15 of
[RFC7432]. This section describes mobility procedures for both [RFC7432]. This section describes mobility procedures for both
symmetric and asymmetric IRB. symmetric and asymmetric IRB. Although the language used in this
section is for IPv4 ARP, it equally applies to IPv6 ND.
When a TS moves from a source NVE to a target NVE, it can behave in When a TS moves from a source NVE to a target NVE, it can behave in
one of the following three ways: one of the following three ways:
1) TS initiates an ARP request upon a move to the target NVE 1) TS initiates an ARP request upon a move to the target NVE
2) TS sends data packet without first initiating an ARP request to 2) TS sends data packet without first initiating an ARP request to
the target NVE the target NVE
3) TS is a silent host and neither initiates an ARP request nor sends 3) TS is a silent host and neither initiates an ARP request nor sends
any packets any packets
The following subsections describe the procedures for each of the The following subsections describe the procedures for each of the
above options. In the following subsections, it is assumed that the above options. In the following subsections, it is assumed that the
MAC & IP addresses of a TS have one-to-one relationship (i.e., there MAC & IP addresses of a TS have one-to-one relationship (i.e., there
is one IP address per MAC address and vise versa). If such there is is one IP address per MAC address and vice versa). If there is many-
many-to-one relationship such that there are many host IP addresses to-one relationship such that there are many host IP addresses
correspond to a single host MAC address or there are many host MAC correspond to a single host MAC address or there are many host MAC
addresses correspond to a single IP address, then to detect host addresses correspond to a single IP address, then to detect host
mobility, the procedures in [IRB-EXT-MOBILITY] must be exercised mobility, the procedures in [IRB-EXT-MOBILITY] must be exercised
followed by the procedures described below. followed by the procedures described below.
4.1 Initiating an ARP Request upon a Move 4.1 Initiating an ARP Request upon a Move
In this scenario when a TS moves from a source NVE to a target NVE, In this scenario when a TS moves from a source NVE to a target NVE,
the TS initiates an ARP request upon the move (e.g., gratuitous ARP) the TS initiates an ARP request upon the move (e.g., gratuitous ARP)
to the target NVE. to the target NVE.
skipping to change at page 20, line 8 skipping to change at page 20, line 9
IP-VRF, and ARP table with the host MAC, IP, and local adjacency IP-VRF, and ARP table with the host MAC, IP, and local adjacency
information (e.g., local interface). information (e.g., local interface).
Since this NVE has previously learned the same MAC and IP addresses Since this NVE has previously learned the same MAC and IP addresses
from the source NVE, it recognizes that there has been a MAC move and from the source NVE, it recognizes that there has been a MAC move and
it initiates MAC mobility procedures per [RFC7432] by advertising an it initiates MAC mobility procedures per [RFC7432] by advertising an
EVPN MAC/IP route with both the MAC and IP addresses filled in (per EVPN MAC/IP route with both the MAC and IP addresses filled in (per
sections 3.2.1 and 3.3.1) along with MAC Mobility Extended Community sections 3.2.1 and 3.3.1) along with MAC Mobility Extended Community
with the sequence number incremented by one. The target NVE also with the sequence number incremented by one. The target NVE also
exercises the MAC duplication detection procedure in section 15.1 of exercises the MAC duplication detection procedure in section 15.1 of
[RFC 7432]. [RFC7432].
The source NVE upon receiving this MAC/IP advertisement, realizes The source NVE upon receiving this MAC/IP advertisement, realizes
that the MAC has moved to the target NVE. It updates its MAC-VRF and that the MAC has moved to the target NVE. It updates its MAC-VRF and
IP-VRF table accordingly with the adjacency information of the target IP-VRF table accordingly with the adjacency information of the target
NVE. In case of the asymmetric IRB, the source NVE also updates its NVE. In case of the asymmetric IRB, the source NVE also updates its
ARP table with the received adjacency information and in case of the ARP table with the received adjacency information and in case of the
symmetric IRB, the source NVE removes the entry associated with the symmetric IRB, the source NVE removes the entry associated with the
received <MAC, IP> from its local ARP table. It then withdraws its received <MAC, IP> from its local ARP table. It then withdraws its
EVPN MAC/IP route. Furthermore, it sends an ARP probe locally to EVPN MAC/IP route. Furthermore, it sends an ARP probe locally to
ensure that the MAC is gone. If an ARP response is received, the ensure that the MAC is gone. If an ARP response is received, the
source NVE updates its ARP entry for that <IP, MAC> and re-advertises source NVE updates its ARP entry for that <IP, MAC> and re-advertises
an EVPN MAC/IP route for that <IP, MAC> along with MAC Mobility an EVPN MAC/IP route for that <IP, MAC> along with MAC Mobility
Extended Community with the sequence number incremented by one. The Extended Community with the sequence number incremented by one. The
source NVE also exercises the MAC duplication detection procedure in source NVE also exercises the MAC duplication detection procedure in
section 15.1 of [RFC 7432]. section 15.1 of [RFC7432].
All other remote NVE devices upon receiving the MAC/IP advertisement All other remote NVE devices upon receiving the MAC/IP advertisement
route with MAC Mobility extended community compare the sequence route with MAC Mobility extended community compare the sequence
number in this advertisement with the one previously received. If the number in this advertisement with the one previously received. If the
new sequence number is greater than the old one, then they update the new sequence number is greater than the old one, then they update the
MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF
tables to point to the target NVE. Furthermore, upon receiving the tables to point to the target NVE. Furthermore, upon receiving the
MAC/IP withdraw for the TS from the source NVE, these remote PEs MAC/IP withdraw for the TS from the source NVE, these remote PEs
perform the cleanups for their BGP tables. perform the cleanups for their BGP tables.
skipping to change at page 22, line 17 skipping to change at page 22, line 17
an unicast ARP request to the host and when receiving an ARP an unicast ARP request to the host and when receiving an ARP
response, it follows the procedure outlined in section 4.1. response, it follows the procedure outlined in section 4.1.
4.3 Silent Host 4.3 Silent Host
In this scenario when a TS moves from a source NVE to a target NVE, In this scenario when a TS moves from a source NVE to a target NVE,
the TS is silent and it neither initiates an ARP request nor it sends the TS is silent and it neither initiates an ARP request nor it sends
any data traffic. Therefore, neither the target nor the source NVEs any data traffic. Therefore, neither the target nor the source NVEs
are aware of the MAC move. are aware of the MAC move.
On the source NVE, the MAC age-out timer (for the silent host that On the source NVE, an age-out timer (for the silent host that has
has moved) expires and as the result it triggers an ARP probe on the moved) is used to trigger an ARP probe. This age-out timer can be
source NVE. The ARP request gets sent both locally to all the either ARP timer or MAC age-out timer and this is an implementation
attached TSes on that subnet as well as it gets sent to all the choice. The ARP request gets sent both locally to all the attached
remote NVEs (including the target NVE) participating in that subnet. TSes on that subnet as well as it gets sent to all the remote NVEs
It also withdraw the EVPN MAC/IP route with only the MAC address (if (including the target NVE) participating in that subnet. It also
it has previously advertised such a route). withdraw the EVPN MAC/IP route with only the MAC address (if it has
previously advertised such a route).
The target NVE passes the ARP request to its locally attached TSes The target NVE passes the ARP request to its locally attached TSes
and when it receives the ARP response, it updates its MAC-VRF, IP- and when it receives the ARP response, it updates its MAC-VRF, IP-
VRF, and ARP table with the host <MAC, IP> and local adjacency VRF, and ARP table with the host <MAC, IP> and local adjacency
information (e.g., local interface). It also sends an EVPN MAC/IP information (e.g., local interface). It also sends an EVPN MAC/IP
advertisement route with both the MAC and IP address fields filled in advertisement route with both the MAC and IP address fields filled in
along with MAC Mobility Extended Community with the sequence number along with MAC Mobility Extended Community with the sequence number
incremented by one. incremented by one.
When the source NVE receives the EVPN MAC/IP advertisement, it When the source NVE receives the EVPN MAC/IP advertisement, it
skipping to change at page 25, line 10 skipping to change at page 25, line 10
TS3 which belong to different subnets, then both bridging and routing TS3 which belong to different subnets, then both bridging and routing
parts of the IRB solution are exercised. The following subsections parts of the IRB solution are exercised. The following subsections
describe the control and data planes operations for this IRB scenario describe the control and data planes operations for this IRB scenario
in details. in details.
NVE1 +---------+ NVE1 +---------+
+-------------+ | | +-------------+ | |
TS1-----| MACx| | | NVE2 TS1-----| MACx| | | NVE2
(IP1/M1) |(MAC- | | | +-------------+ (IP1/M1) |(MAC- | | | +-------------+
TS5-----| VRF1)\ | | MPLS/ | |MACy (MAC- |-----TS3 TS5-----| VRF1)\ | | MPLS/ | |MACy (MAC- |-----TS3
(IP5/M5) | \ | | VxLAN/ | | / VRF3) | (IP3/M3) (IP5/M5) | \ | | VxLAN/ | | / VRF3) | (IP3/M3)
| (IP-VRF1)|----| NVGRE |---|(IP-VRF1) | | (IP-VRF1)|----| NVGRE |---|(IP-VRF1) |
| / | | | | \ | | / | | | | \ |
TS2-----|(MAC- / | | | | (MAC- |-----TS4 TS2-----|(MAC- / | | | | (MAC- |-----TS4
(IP2/M2) | VRF2) | | | | VRF1) | (IP4/M4) (IP2/M2) | VRF2) | | | | VRF1) | (IP4/M4)
+-------------+ | | +-------------+ +-------------+ | | +-------------+
| | | |
+---------+ +---------+
Figure 6: IRB forwarding on NVEs for Tenant Systems Figure 6: IRB forwarding on NVEs for Tenant Systems
6.1.1 Control Plane Operation 6.1.1 Control Plane Operation
Each NVE advertises a MAC/IP Advertisement route (i.e., Route Type 2) Each NVE advertises a MAC/IP Advertisement route (i.e., Route Type 2)
for each of its TSes with the following field set: for each of its TSes with the following field set:
skipping to change at page 31, line 17 skipping to change at page 31, line 17
SA set to that of the access-facing IRB interface of the egress NVE SA set to that of the access-facing IRB interface of the egress NVE
(NVE2) and the MAC DA is set to that of destination TS (TS3) MAC (NVE2) and the MAC DA is set to that of destination TS (TS3) MAC
address. The packet is sent to the corresponding MAC-VRF3 and after a address. The packet is sent to the corresponding MAC-VRF3 and after a
lookup of MAC DA, is forwarded to the destination TS (TS3) over the lookup of MAC DA, is forwarded to the destination TS (TS3) over the
corresponding interface. corresponding interface.
7 Acknowledgements 7 Acknowledgements
The authors would like to thank Sami Boutros, Jeffrey Zhang, The authors would like to thank Sami Boutros, Jeffrey Zhang,
Krzysztof Szarkowicz, Lukas Krattiger and Neeraj Malhotra for their Krzysztof Szarkowicz, Lukas Krattiger and Neeraj Malhotra for their
valuable comments. The authors would also like to thank Linda Dunbar valuable comments. The authors would also like to thank Linda Dunbar,
for her engaging discussions. Florin Balus, Yakov Rekhter, Wim Henderickx, Lucy Yong, and Dennis
Cai for their feedbacks and contributions.
8 Security Considerations 8 Security Considerations
This document describes a set of procedures for Inter-Subnet This document describes a set of procedures for Inter-Subnet
Forwarding of tenant traffic across PEs (or NVEs). These procedures Forwarding of tenant traffic across PEs (or NVEs). These procedures
include both layer-2 forwarding and layer-3 routing on a packet by include both layer-2 forwarding and layer-3 routing on a packet by
packet basis. The security consideration for layer-2 forwarding in packet basis. The security consideration for layer-2 forwarding in
this document follow that of [RFC7432] for MPLS encapsulation and it this document follow that of [RFC7432] for MPLS encapsulation and it
follows that of [RFC8365] for VxLAN or GENEVE encapsulations. follows that of [RFC8365] for VxLAN or GENEVE encapsulations.
skipping to change at page 32, line 23 skipping to change at page 32, line 23
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017. 2017.
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
February, 2015. February, 2015.
[RFC8365] Sajassi et al., "A Network Virtualization Overlay Solution [RFC8365] Sajassi et al., "A Network Virtualization Overlay Solution
Using Ethernet VPN (EVPN)", RFC 8365, March, 2018. Using Ethernet VPN (EVPN)", RFC 8365, March, 2018.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-03, November Attribute", draft-ietf-idr-tunnel-encaps-11, February
2016. 2019.
[EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", [EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",
draft-ietf-bess-evpn-prefix-advertisement-03, September, draft-ietf-bess-evpn-prefix-advertisement-11, May 2018.
2016.
10.2 Informative References 10.2 Informative References
[RFC7606] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, [RFC7606] Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Messages", RFC 7606, August "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August
2015, <http://www.rfc-editor.org/info/rfc7606>. 2015, <http://www.rfc-editor.org/info/rfc7606>.
[802.1Q] "IEEE Standard for Local and metropolitan area networks - [802.1Q] "IEEE Standard for Local and metropolitan area networks -
Media Access Control (MAC) Bridges and Virtual Bridged Local Area Media Access Control (MAC) Bridges and Virtual Bridged Local Area
Networks", IEEE Std 802.1Q(tm), 2014 Edition, November 2014. Networks", IEEE Std 802.1Q(tm), 2014 Edition, November 2014.
[RFC7348] Mahalingam, M., et al., "Virtual eXtensible Local Area [RFC7348] Mahalingam, M., et al., "Virtual eXtensible Local Area
Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Network (VXLAN): A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348,
August 2014. August 2014.
[GENEVE] Gross, J., et al., "Geneve: Generic Network Virtualization [RFC4364] Rosen, E., et al., "BGP/MPLS IP Virtual Private Networks
Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-06, March (VPNs)", RFC 4364, February 2006.
2018.
[IRB-EXT-MOBILITY] Malhotra, N., al., "Extended Mobility Procedures
for EVPN-IRB", Work in Progress, draft-malhotra-bess-evpn-irb-
extended-mobility-02, February 2018.
11 Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Florin Balus [RFC4365] Rosen, E., et al., "Applicability Statement for BGP/MPLS IP
Cisco Virtual Private Networks (VPNs)", RFC 4365, February 2006.
Yakov Rekhter [RFC7365] Lasserre, M., et al., "Framework for Data Center (DC)
Juniper Network Virtualization", RFC 7365, October 2014.
Wim Henderickx [RFC5798] Nadas, S., et al., "Virtual Router Redundancy Protocol
Nokia (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
Lucy Yong [GENEVE] Gross, J., et al., "Geneve: Generic Network Virtualization
Linda Dunbar Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-10, March
Huawei 2019.
Dennis Cai [IRB-EXT-MOBILITY] Malhotra, N., al., "Extended Mobility Procedures
Alibaba for EVPN-IRB", Work in Progress, draft-malhotra-bess-evpn-irb-
extended-mobility-04, January 2019.
Authors' Addresses Authors' Addresses
Ali Sajassi (Editor) Ali Sajassi (Editor)
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Samer Salam Samer Salam
Cisco Cisco
Email: sslam@cisco.com Email: ssalam@cisco.com
Samir Thoria Samir Thoria
Cisco Cisco
Email: sthoria@cisco.com Email: sthoria@cisco.com
John E. Drake John E. Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
Jorge Rabadan Jorge Rabadan
 End of changes. 25 change blocks. 
52 lines changed or deleted 44 lines changed or added

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