< draft-brissette-bess-evpn-mh-pa-02.txt   draft-brissette-bess-evpn-mh-pa-03.txt >
INTERNET-DRAFT Patrice Brissette INTERNET-DRAFT Patrice Brissette
Intended Status: Proposed Standard Samir Thoria Intended Status: Proposed Standard Samir Thoria
Ali Sajassi Ali Sajassi
Cisco Systems Cisco Systems
Expires: April 25, 2019 October 22, 2018 Expires: September 12, 2019 March 11, 2019
EVPN multi-homing port-active load-balancing EVPN multi-homing port-active load-balancing
draft-brissette-bess-evpn-mh-pa-02 draft-brissette-bess-evpn-mh-pa-03
Abstract Abstract
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables
the establishment of a logical port-channel connection with a the establishment of a logical port-channel connection with a
redundant group of independent nodes. The purpose of multi-chassis redundant group of independent nodes. The purpose of multi-chassis
LAG is to provide a solution to achieve higher network availability, LAG is to provide a solution to achieve higher network availability,
while providing different modes of sharing/balancing of traffic. EVPN while providing different modes of sharing/balancing of traffic. EVPN
standard defines EVPN based MC-LAG with single-active and all-active standard defines EVPN based MC-LAG with single-active and all-active
multi-homing load-balancing mode. The current draft expands on multi-homing load-balancing mode. The current draft expands on
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) 2018 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Multi-Chassis Ethernet Bundles . . . . . . . . . . . . . . . . 4 2. Multi-Chassis Ethernet Bundles . . . . . . . . . . . . . . . . 4
3. Port-active load-balancing procedure . . . . . . . . . . . . . 4 3. Port-active load-balancing procedure . . . . . . . . . . . . . 4
4. Algorithm to elect per port-active PE . . . . . . . . . . . . . 5 4. Algorithm to elect per port-active PE . . . . . . . . . . . . . 5
5. Port-active over Integrated Routing-Bridging Interface . . . . 6 5. Convergence considerations . . . . . . . . . . . . . . . . . . 5
6. Convergence considerations . . . . . . . . . . . . . . . . . . 7 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Overall Advantages . . . . . . . . . . . . . . . . . . . . . . 6
7. Overall Advantages . . . . . . . . . . . . . . . . . . . . . . 8 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1 Normative References . . . . . . . . . . . . . . . . . . . 8
11.1 Normative References . . . . . . . . . . . . . . . . . . . 9 11.2 Informative References . . . . . . . . . . . . . . . . . . 8
11.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1 Introduction 1 Introduction
EVPN, as per [RFC7432], provides all-active per flow load balancing EVPN, as per [RFC7432], provides all-active per flow load balancing
for multi-homing. It also defines single-active with service carving for multi-homing. It also defines single-active with service carving
mode, where one of the PEs, in redundancy relationship, is active per mode, where one of the PEs, in redundancy relationship, is active per
service. service.
While these two multi-homing scenarios are most widely utilized in While these two multi-homing scenarios are most widely utilized in
skipping to change at page 4, line 26 skipping to change at page 4, line 26
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Multi-Chassis Ethernet Bundles 2. Multi-Chassis Ethernet Bundles
When a CE is multi-homed to a set of PE nodes using the [802.1AX] When a CE is multi-homed to a set of PE nodes using the [802.1AX]
Link Aggregation Control Protocol (LACP), the PEs must act as if they Link Aggregation Control Protocol (LACP), the PEs must act as if they
were a single LACP speaker for the Ethernet links to form a bundle, were a single LACP speaker for the Ethernet links to form a bundle,
and operate as a Link Aggregation Group (LAG). To achieve this, the and operate as a Link Aggregation Group (LAG). To achieve this, the
PEs connected to the same multi-homed CE must synchronize LACP PEs connected to the same multi-homed CE must synchronize LACP
configuration and operational data among them. ICCP-based protocol configuration and operational data among them. ICCP-based protocol
has been used for that purpose. EVLAG simplifies greatly that has been used for that purpose. EVPN LAG simplifies greatly that
solution. Along with the simplification comes few assumptions: solution. Along with the simplification comes few assumptions:
- Links in the Ethernet Bundle MUST operate in all-active load- - Links in the Ethernet Bundle MUST operate in all-active load-
balancing mode balancing mode
- Same LACP parameters MUST be configured on peering PEs such as - Same LACP parameters MUST be configured on peering PEs such as
system id, port priority, etc. system id, port priority, etc.
Any discrepancies from this list is left for future study. Any discrepancies from this list is left for future study.
Furthermore, mis-configuration and mis-wiring detection across Furthermore, mis-configuration and mis-wiring detection across
peering PEs are also left for further study. peering PEs are also left for further study.
3. Port-active load-balancing procedure 3. Port-active load-balancing procedure
Following steps describe the proposed procedure with EVLAG to support Following steps describe the proposed procedure with EVPN LAG to
port-active load-balancing mode: support port-active load-balancing mode:
1- ESI MUST be assigned per access interface as described in 1- ESI MUST be assigned per access interface as described in
[RFC7432], which may be auto derived or manually assigned. Access [RFC7432], which may be auto derived or manually assigned. Access
interface MAY be a Layer-2 or Layer3 interface. interface MAY be a Layer-2 or Layer3 interface.
2- Ethernet-Segment MUST be configured in port-active load-balancing 2- Ethernet-Segment MUST be configured in port-active load-balancing
mode on peering PEs for specific interface mode on peering PEs for specific interface
3- Peering PEs MAY exchange only Ethernet-Segment route (Route Type- 3- Peering PEs MAY exchange only Ethernet-Segment route (Route Type-
4) 4)
4- PEs in the redundancy group leverages DF election defined in 4- PEs in the redundancy group leverages DF election defined in
[draft-ietf-bess-evpn-df-election-framework] to determine which PE [EVPN-DF] to determine which PE keeps the port in active mode and
keeps the port in active mode and which one(s) keep it in standby which one(s) keep it in standby mode. While the DF election defined
mode. While the DF election defined in [draft-ietf-bess-evpn-df- in [EVPN-DF] is per <ES, VLAN> granularity, for port-active mode of
election-framework] is per <ES, VLAN> granularity, for port-active multi-homing, the DF election is done per <ES>. The details of this
mode of multi-homing, the DF election is done per <ES>. The details algorithm are described in Section 4.
of this algorithm are described in Section 4.
5- DF router MUST keep corresponding access interface in up and 5- DF router MUST keep corresponding access interface in up and
forwarding active state for that Ethernet-Segment forwarding active state for that Ethernet-Segment
6- Non-DF routers MAY bring and keep peering access interface 6- Non-DF routers MAY bring and keep peering access interface
attached to it in operational down state. If the interface is running attached to it in operational down state. If the interface is running
LACP protocol, then the non-DF PE MAY also set the LACP state to OOS LACP protocol, then the non-DF PE MAY also set the LACP state to OOS
(Out of Sync) as opposed to interface state down. This allows for (Out of Sync) as opposed to interface state down. This allows for
better convergence on standby to active transition. better convergence on standby to active transition.
7- For EVPN-VPWS service, the usage of primary/backup bits of EVPN
Layer2 attributes extended community [RFC8214] is highly recommended
to achieve better convergence.
4. Algorithm to elect per port-active PE 4. Algorithm to elect per port-active PE
The default DF Election algorithm, or modulus-based algorithm as in The default DF Election algorithm, or modulus-based algorithm as in
[RFC7432], is used here also, at the granularity of <ES> only. For [RFC7432], is used here also, at the granularity of <ES> only. For
Modulo calculation, byte 10 of the ESI is used. Modulo calculation, byte 10 of the ESI is used.
Highest Random Weight (HRW) algorithm defined in [draft-ietf-bess- Highest Random Weight (HRW) algorithm defined in [EVPN-DF] MAY also
evpn-df-election-framework] MAY also be used and signaled, and be used and signaled, and modified to operate at the granularity of
modified to operate at the granularity of <ES> rather than per <ES, <ES> rather than per <ES, VLAN>.
VLAN>.
Let Active(ESI) denote the PE that will be the active PE for port Let Active(ESI) denote the PE that will be the active PE for port
with Ethernet segment identifier - ESI. The other PEs in the with Ethernet segment identifier - ESI. The other PEs in the
redundancy group will be standby PE(s) for the same port (ES). Ai is redundancy group will be standby PE(s) for the same port (ES). Ai is
the address of the PEi and weight() is a pseudorandom function of ESi the address of the PEi and weight() is a pseudorandom function of ESi
and Ai, Wrand() function defined in [draft-ietf-bess-evpn-df- and Ai, Wrand() function defined in [EVPN-DF] is used as the Weight()
election-framework] is used as the Weight() function. function.
Active(ESI) = PEi: if Weight(ESI, Ai) >= Weight(ESI, Aj), for all j, Active(ESI) = PEi: if Weight(ESI, Ai) >= Weight(ESI, Aj), for all j,
0 <= I,j <= Number of PEs in the redundancy group. In case of a tie, 0 <= I,j <= Number of PEs in the redundancy group. In case of a tie,
choose the PE whose IP address is numerically the least. choose the PE whose IP address is numerically the least.
5. Port-active over Integrated Routing-Bridging Interface 5. Convergence considerations
+-----+
| PE3 |
|(IRB)|
| GW3 |
+-----+
+-----------+
| MPLS/IP |
| CORE |
+-----------+
+-----+ +-----+
| GW1 | | GW2 |
|(IRB)| |(IRB)|
| PE1 | | PE2 |
+-----+ +-----+
| | |
I1 I2 I3
\ / |
\ / \
+---+ +---+
|CE1| |CE2|
+---+ +---+
Figure 2. EVPN-IRB Port-active load-balancing
Figure 2 shows a simple network where EVPN-IRB is used for inter-
subnet connectivity. IRB interfaces on PE1 and PE2 are configured in
anycast gateway (same MAC, same IP). CE1 device is multi-homed to
both PE1 and PE2. The Ethernet-segment load-balancing mode, of the
connected CE1 to peering PEs, can be of any type e.g. all-active,
single-active or port-active. CE2 device is connected to a single PE
(PE2). It operates as single-homed device via an orphan port I3.
Finally, port-active load-balancing is apply to IRB interface on
peering PEs (PE1 and PE2). Manual Ethernet-Segment Identifier is
assigned per IRB interface. ESI auto-generation is also possible
based on the IRB anycast IP address.
DF election is performed between peering PE over IRB interface (per
ESI/EVI). Designed forwarder (DF) IRB interface remains in up state.
Non-designated forwarder (NDF) IRB interface may goes in down state.
Furthermore, if all access interfaces connected to an IRB interface
are down state (failure or admin) OR in blocked forward state(NDF),
IRB interface is brought down. For example, interface I3 fails at the
same time than interface I2 (in single-active load-balancing mode) is
in blocked forwarding state.
In the example where IRB on PE2 is NDF, all L3 traffic coming from
PE3 is going via PE1. An IRB interface in down state doesn't attract
traffic from core side. CE2 device reachability is done via an L2
subnet stretch between PE1 and PE2. Therefore L3 traffic coming from
PE3 destinated to CE2 goes via GW1 first, then via an L2 connection
to PE2 and finally via interface I3 to CE2 device.
There are many reasons of configuring port-active load-balancing mode
over IRB interface:
- Ease replacement of legacy technology such VRRP / HSRP
- Better scalability than legacy protocols
- Traffic predictability
- Optimal routing and entirely independent of load-balancing mode
configured on any access interfaces
6. Convergence considerations
To improve the convergence, upon failure and recovery, when port- To improve the convergence, upon failure and recovery, when port-
active load-balancing mode is used, some advanced synchronization active load-balancing mode is used, some advanced synchronization
between peering PEs may be required. Port-active is challenging in a between peering PEs may be required. Port-active is challenging in a
sense that the "standby" port is in down state. It takes some time to sense that the "standby" port is in down state. It takes some time to
bring a "standby" port in up-state and settle the network. For IRB bring a "standby" port in up-state and settle the network. For IRB
and L3 services, ARP / MLD cache may be synchronized. Moreover, and L3 services, ARP / MLD cache may be synchronized. Moreover,
associated VRF tables may also be synchronized. For L2 services, MAC associated VRF tables may also be synchronized. For L2 services, MAC
table synchronization may be considered. Finally, using bundle- table synchronization may be considered. Finally, using bundle-
Ethernet interface, where LACP is running, is usually a smart thing Ethernet interface, where LACP is running, is usually a smart thing
since it provides the ability to set the "standby" port in "out-of- since it provides the ability to set the "standby" port in "out-of-
sync" state aka "warm-standby". sync" state aka "warm-standby".
6. Applicability 6. Applicability
A common deployment is to provide L2 or L3 service on the PEs A common deployment is to provide L2 or L3 service on the PEs
providing multi-homing. The services could be any L2 EVPN such as providing multi-homing. The services could be any L2 EVPN such as
EVPN VPWS, EVPN [RFC7432], etc. L3 service could be in VPN context EVPN VPWS, EVPN [RFC7432], etc. L3 service could be in VPN context
[RFC4364] or in global routing context. When a PE provides first hop [RFC4364] or in global routing context. When a PE provides first hop
routing, EVPN IRB could also be deployed on the PEs. The mechanism routing, EVPN IRB could also be deployed on the PEs. The mechanism
defined in this draft is used between the PEs providing the L2 or L3 defined in this draft is used between the PEs providing the L2 and/or
service, when the requirement is to use per port active. L3 service, when the requirement is to use per port active.
A possible alternate solution is the one described in this draft is A possible alternate solution is the one described in this draft is
MC-LAG with ICCP [RFC7275] active-standby redundancy. However, ICCP MC-LAG with ICCP [RFC7275] active-standby redundancy. However, ICCP
requires LDP to be enabled as a transport of ICCP messages. There are requires LDP to be enabled as a transport of ICCP messages. There are
many scenarios where LDP is not required e.g. deployments with VXLAN many scenarios where LDP is not required e.g. deployments with VXLAN
or SRv6. The solution defined in this draft with EVPN does not or SRv6. The solution defined in this draft with EVPN does not
mandate the need to use LDP or ICCP and is independent of the overlay mandate the need to use LDP or ICCP and is independent of the
encapsulation. underlay encapsulation.
7. Overall Advantages 7. Overall Advantages
There are many advantages in EVLAG to support port-active load- There are many advantages in EVPN LAG to support port-active load-
balancing mode. Here is a non-exhaustive list: balancing mode. Here is a non-exhaustive list:
- Open standards based per interface single-active redundancy - Open standards based per interface single-active redundancy
mechanism that eliminates the need to run ICCP and LDP. mechanism that eliminates the need to run ICCP and LDP.
- Agnostic of underlay technology (MPLS, VXLAN, SRv6) and associated - Agnostic of underlay technology (MPLS, VXLAN, SRv6) and associated
services (L2, L3, Bridging, E-LINE, etc). services (L2, L3, Bridging, E-LINE, etc).
- Provides a way to enable deterministic QOS over MC-LAG attachment - Provides a way to enable deterministic QOS over MC-LAG attachment
circuits circuits
skipping to change at page 9, line 35 skipping to change at page 8, line 35
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M.,
Matsushima, S., and T. Nadeau, "Inter-Chassis Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private Network Communication Protocol for Layer 2 Virtual Private Network
(L2VPN) Provider Edge (PE) Redundancy", RFC 7275, DOI (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, DOI
10.17487/RFC7275, June 2014, <https://www.rfc- 10.17487/RFC7275, June 2014, <https://www.rfc-
editor.org/info/rfc7275>. editor.org/info/rfc7275>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[EVPN-DF] Rabadan J., Mohanty S. et al. "Framework for EVPN
Designated Forwarder Election Extensibility", draft-
ietf-bess-evpn-df-election- framework-07, work-in-
progress, December, 2018.
11.2 Informative References 11.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc- 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[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 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
 End of changes. 15 change blocks. 
98 lines changed or deleted 45 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/