Internet-Draft | EVPN VPLS multihoming based on BD | August 2023 |
Xu & Zhu | Expires 18 February 2024 | [Page] |
EVPN VPLS supports multi-homing to implement redundancy between PEs, including single-active and all-active redundancy [RFC7432]. The redundancy function on the access side needs to be implemented in another mode, which is described in this document.¶
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 Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 February 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document provides a multihoming single-active solution based on BD. In an existing EVPN VPLS multi-homing scenario, a CE is multi-homed to multiple PEs. When multiple devices (eg. BNGs) are multi-homed to PEs, the multi-homing function based on BD must be supported to implement redundancy among the devices.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
BNG1, BNG2, and BNG3 belong to the same BD and are multi-homed to PE1 and PE2 as access devices. BNG (Broadband Network Gateway) is the access point for subscribers, through which they connect to the broadband network. Only one of the BNGs is selected when connecting.¶
In Figure 1, PE1 and PE2 procedures are as follow:¶
a. The PEs must assign the same ESI to the BD to which BNG1, BNG2, and BNG3 belong. DF election is performed based on the Ethernet Segment route corresponding to the ESI. Assume that PE1 is the Designated Forwarder PE and PE2 is the NDF PE.¶
b. The subscriber access packet is sent to the UPE, and the UPE broadcasts the packet to PE1 and PE2.¶
c. When the link between BNG1 and PE1 fails, subscriber go offline due to timeout. The subscriber retransmits an online packet. The packet is sent to BNG2 through PE1. BNG2 replies with a packet. Then the subscriber goes online successfully.¶
d. When the link between BNG2 and PE1 fails again, all access devices in the BD on PE1 fail. In this case, the Ethernet Segment route corresponding to the ESI of the BD is withdrawn and the DF election is performed again. PE2 is elected as the designated forwarder. After that, when the subscriber goes online, the access packet is sent to BNG3 through PE2. BNG3 replies with a packet, indicating that the subscriber goes online successfully.¶
e. When the link between BNG1 or BNG2 and PE1 recovers, the non-revertive capability of Highest-Preference DF Alg [I-D.ietf-bess-evpn-pref-df] can be used for DF. In this way, the DF PE remains unchanged, preventing subscriber from going offline.¶
None.¶
This document raises no new security issues for EVPN.¶