Internet-Draft EVPN VPLS multihoming based on BD August 2023
Xu & Zhu Expires 18 February 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-xu-bess-evpn-vpls-multihoming-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Xu
Huawei Technologies
T,. Zhu
Huawei Technologies

EVPN VPLS multihoming based on BD

Abstract

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.

Status of This Memo

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.

Table of Contents

1. Introduction

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.

2. Requirements Language and Terminology

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].

3. Scenario Description

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.

        +---------------------+
        | USER ACCESS NETWORK |
        +---------------------+

    +-------+     +-----+
    | BNG1  |-----|     |
    +-------+     | PE1 |
    +-------+     |     |    +-----+
    | BNG2  |-----|     |----|     |
    +-------+     +-----+    |     |
                             | UPE |----SUBSCRIBER
    +-------+     +-----+    |     |
    | BNG3  |-----| PE2 |----|     |
    +-------+     +-----+    +-----+

Figure 1

4. Solution Description

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.

5. IANA considerations

None.

6. Security Considerations

This document raises no new security issues for EVPN.

7. References

[I-D.ietf-bess-evpn-pref-df]
Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A. Sajassi, "Preference-based EVPN DF Election", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-11>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7432]
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, , <https://www.rfc-editor.org/info/rfc7432>.

Authors' Addresses

Jianyong Xu
Huawei Technologies
No.101 Software Avenue, Yuhuatai District
Nanjing
210012
China
Tong Zhu
Huawei Technologies
No.101 Software Avenue, Yuhuatai District.
Nanjing
210012
China