Hi Aijun, Now that the -08 revision has been published, let me bring this discussion to the WG. The email thread has some details that help clarify the intended use case and why the proposed solution is not needed or not good.
The draft does not clearly state it, but based on our discussions below, the PE-CE connection is a PW that terminates into the EVPN PE. There are two previous points that I want to re-emphasize here. I'll then explain why your proposed solution is not needed in my view. - There are already deployed solutions of PWs terminating into VPN service PEs, including EVPN, w/o any protocol extensions - On the EVPN side, there is no difference between "a PW terminates into a PW-PE, which then connects to EVPN PE via a physical L2 connection" and "a PW terminates into the EVPN PE directly" Your solution requires the ingress EVPN PEs to put on the PW information that is used on the egress side. That is just unnecessary and not appropriate. In the true L2 connection case, the MAC lookup on the egress PE leads to local forwarding information, including the outgoing AC and perhaps VID translation information. In the PW terminating into EVPN PE case, the same lookup leads to local forwarding information, including the PW information, which is *local* and should not be advertised other EVPN PEs for them to put into the VXLAN header. If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about), it is an orthogonal issue (nothing to do with PW terminating into EVPN PE) that is already solved. Per RFC7432: A PE may advertise the same single EVPN label for all MAC addresses in a given MAC-VRF. This label assignment is referred to as a per MAC-VRF label assignment. Alternatively, a PE may advertise a unique EVPN label per <MAC-VRF, Ethernet tag> combination. This label assignment is referred to as a per <MAC-VRF, Ethernet tag> label assignment. As a third option, a PE may advertise a unique EVPN label per <ESI, Ethernet tag> combination. This label assignment is referred to as a per <ESI, Ethernet tag> label assignment. As a fourth option, a PE may advertise a unique EVPN label per MAC address. This label assignment is referred to as a per MAC label assignment. All of these label assignment methods have their trade-offs. The choice of a particular label assignment methodology is purely local to the PE that originates the route. The third option (per <ESI, Ethernet tag> combination) can be per <AC, Ethernet tag> (whether the AC has a zero- or none-zero ESI) and the AC can correspond to a PW. Jeffrey Juniper Business Use Only -----Original Message----- From: Aijun Wang Sent: Friday, February 28, 2025 9:26 AM To: Jeffrey (Zhaohui) Zhang ; wang...@chinatelecom.cn; bess-cha...@ietf.org Cc: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' Subject: 答复: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt [External Email. Be cautious of content] Hi, Jeffrey: Let's first update the draft and then take the discussions to the BESS list, to avoid some loop for the solved issues. I think we are converging after the constructive discussions. Thanks for your efforts! But I should point out is that the information about PW(over a tunnel) is different from the information from VLAN(over wire). The protocol extension proposed in this document is just want to transfer the information(for example, site customer's VNI) within the PW to the other side, to assure the traffic isolation among different customer'VNI. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 【外部账号】 Jeffrey (Zhaohui) Zhang 发送时间: 2025年2月27日 21:37 收件人: Aijun Wang ; bess-cha...@ietf.org 抄送: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' 主题: RE: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt Hi Aijun, The more we talk about it, the more I am convinced that we don't have a valid use case here. For the benefit of the WG, I'll copy the WG in my next reply unless you object to it. Please see zzh3> below. Juniper Business Use Only -----Original Message----- From: Aijun Wang Sent: Thursday, February 27, 2025 2:35 AM To: Jeffrey (Zhaohui) Zhang ; bess-cha...@ietf.org Cc: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' Subject: 答复: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt [External Email. Be cautious of content] Hi, Jeffrey: "PW information" if the identifier of PW. Zzh3> The identifier of the PW is just between two ends of the PW, and has no significance beyond the PW. For VxLAN based PW, the "PW information" is the VNI that is carried in the VxLAN header. For "Traffic Isolation", we mainly refer to the hosts located in different "PW" can't communicate with each other. Zzh3> That's on the PW side and it has nothing to do with EVPN. The description in the document of headquarter and branch should be updated. Actually, what in our imagination about the communication pattern is like VPLS, not VPWS. Zzh3> OK that's clear now; then the headquarter/branch text should be removed. But that does not change the fact that we don't need any protocol extension. And, I have gave one example that may be helpful for you to understand our main motivation: Let's think the current scenario from the opposite viewpoint: if the MAN between the CE and PE are removed, that is, the CE connects directly to PE via one Layer 2 access network, then, the VLAN-based/VLAN-Aware/VLAN-Buddle service(we call it layer 2 accessible EVPN services) are all familiar with us, right? Zzh3> Correct. If the MAN is added back again, the VLAN-based/VLAN-Aware/VLAN-Buddle service can't be used, then, we need to design some "layer 3 accessible EVPN services" to cover such scenario. Zzh3> With the MAN added back in, we don't need anything new if there is a PEm to terminate the PW (and act as the CE for the EVPN), right? CEm1 -- PEm11 --- PW ---- PEm12 -- PEb1 --- EVPN --- PEb2 --- PEm22 ---- PW --- PEm21 --- CEm2 Zzh3> Now when you merge PEm into PEb (terminating the PWs directly into PEb), it's just an implementation/deployment variation, and does not need anything new in the protocol. Zzh3> EVPN can provide three services: EVPN-L2 (type 2 routes), EVPN-L3 (type 5 routes), and EVPN-VPWS. Both EVPN-L2 and EVPN-VPWS use L2 access interface, and EVPN-L3 uses L3 interfaces. Zzh3> Your deployment case (and Juniper's PWHT) is still EVPN-L2. The access interface being a PW does not make it or need a "layer 3 accessible EVPN service". A PW is an L2 interface - the only difference from a regular L2 interface is that one is over a tunnel and the other is over a wire. Zzh3> Jeffrey Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2025年2月27日 12:31 收件人: Aijun Wang ; bess-cha...@ietf.org 抄送: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' 主题: RE: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt Hi Aijun, Please see zzh2> below. Juniper Business Use Only -----Original Message----- From: Aijun Wang Sent: Wednesday, February 26, 2025 10:21 PM To: Jeffrey (Zhaohui) Zhang ; bess-cha...@ietf.org Cc: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' Subject: 答复: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt [External Email. Be cautious of content] Hi, Jeffrey: Connect the CEm to the PEb, as that described in https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/pwht-pseudowire-headend-termination.html, is just the first step for the communications(peer 2 peer, or peer 2 multiple peers) Zzh2> The rest is just EVPN per RFC7432. The key requirement is that the PW information should be preserved along its E2E path, Zzh2> What PW information? PW just provides a virtual wire, its information is only for the MAN. The VLAN between the CEm and PEb may be preserved E2E, but that's already handled by RFC7432. which is to be used to control the traffic isolation (as that for the VLAN aware Bundle service that described in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7432.html*section-6.3__;Iw!!NEt6yMaO-gk!HuucmnwT9T0u1mWjXcJFtoTnB_yOA0sgK1O5VTRQ92QK98xWoTqpC8y5Xbv24Mx_lCzt0qyH75wuz8u6rkR-eV7M$ ) There is no place in the current EVPN forwarding plane to transfer the PW information. Zzh2> Can you elaborate "traffic isolation"? If you mean different VLANs, please see above. Zzh2> BTW - if the EVPN domain B is only for EVPN-VPWS here (you mentioned that branch sites only communicate with the headquarters), then MAC-VRF and type-2 routes do not make sense - they are not used for PWs. Zzh2> Jeffrey The proposed protocol extension in this document just want to achieve such aim. Aijun Wang -----邮件原件----- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2025年2月26日 21:16 收件人: Aijun Wang ; bess-cha...@ietf.org 抄送: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' 主题: RE: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt Hi Aijun, > Then CEs of Domain B is the edge routers of MAN, which is not illustrated for > brevity. That is a critical piece of detail that is missing. If we add a pair of MAN PEs for the PWs, then we have the following picture: CEm1 -- PEm11 --- PW ---- PEm12 -- PEb1 --- EVPN --- PEb2 --- PEm22 ---- PW --- PEm21 --- CEm2 PEm stands for a PE in MAN and PEb stands for a PE in the backbone. In the above picture, there is nothing special. It's just ethernet/vlan between the PEb and PEm, where the PEm is the CE for the EVPN backbone. PEm12 and PEm22 could be removed, and the PWs will terminate into PEb directly (but the logical independence is still there). That's just an implementation feature (https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/pwht-pseudowire-headend-termination.html) and does not require EVPN protocol extension. Jeffrey Juniper Business Use Only -----Original Message----- From: Aijun Wang Sent: Wednesday, February 26, 2025 2:41 AM To: Jeffrey (Zhaohui) Zhang ; bess-cha...@ietf.org Cc: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' Subject: 答复: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt [External Email. Be cautious of content] Hi, Jeffrey: Let's try to answer your questions, please see inline below[WAJ] -----邮件原件----- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2025年2月26日 12:46 收件人: Aijun Wang ; bess-cha...@ietf.org 抄送: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' 主题: RE: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt Aijun, You can put in an agenda request; even with a presentation in the session, I still need additional time to understand the unclear use case - the 10-minute presentation+Q&A is simply not enough for me - but I can ask my questions here now with follow-up in Bangkok. Please see zzh> below. Juniper Business Use Only -----Original Message----- From: Aijun Wang Sent: Tuesday, February 25, 2025 8:44 PM To: Jeffrey (Zhaohui) Zhang ; bess-cha...@ietf.org Cc: draft-wang-bess-l3-accessible-e...@ietf.org; 'Rabadan, Jorge (Nokia - US)' Subject: 答复: I-D Action: draft-wang-bess-l3-accessible-evpn-07.txt [External Email. Be cautious of content] Hi, Jeffrey: Let's try to explain the scenario more clearer: Normally, the service provider has one backbone network, and tens of metro-area-networks(MAN) that surrounds it(the backbone). Suppose one multi-regions customer has its branch sites located in some, or all of these MANs, and also its headquarter connected to another MAN(the diagram is similar with Figure 2 in https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-07__;!!NEt6yMaO-gk!GhLQQwXotdebXop6hSHz7zuAAtIugWRhbbBZJOYttTQvdTuEfde0a6bPL6RtnMnNx333yMpHgbok7ixY6vxuUpqw$ , except some points needs to be tweaked further for more clarities) This customer want to connect all of its branch sites, to its headquarter, via the one virtual private Layer 2 infrastructure. There are two possible solutions: 1) Solution A: Build one large virtual private Layer 2 infrastructure(EVPN Domain A), that span the backbone and MANs together------it is what you recommended that "EVPN is already layer 2 service span the layer 3 network" 2) Solution B: Build the virtual private Layer 2 infrastructure only within the backbone(EVPN Domain B), but connect each branch to the EVPN Domain B, via the layer 3 access network, based on the solution that proposal in this document Zzh> The draft says: ... The packets should be transmitted from CE to PE through VxLAN/IPSec tunnel. Due to the EVI cannot be transmitted in this scenario, we need an EVPN solution that can span the L3 network. Zzh> What does "EVI cannot be transmitted in this scenario" mean? [WAJ]: Here, the "EVI" should be "VLAN ID". Image C-A/C-B under one CE(CE1) in Figure 2, belongs to different VLANs, and needs to communicate with the corresponding C-A/C-B under another CE(CE2), via MAN-Backbone-MAN, all are layer 3 network. Zzh> Does "an EVPN solution that can span the L3 network" refer to Solution A or B? To me it can't be Solution B, because in the solution B the EVPN stops at the PEs and does not span the layer 3 MAN. [WAJ]: Solution B. Here, we should make some changes to clarify the statements more clearly.------"an EVPN accessible solution that can span the L3 network" Maybe be more accurate. Zzh> What are the EVPN CEs here for the EVPN Domain B? Are they CE1/CE2 in Figure 2 of the draft? If so, is it that there is a PW between the CE and PE over the MAN? If so what's the problem of existing EVPN solution (the PWs instead of real Ethernet VLANs are the EVPN ACs)? [WAJ] Domain B covers only the backbone. Then CEs of Domain B is the edge routers of MAN, which is not illustrated for brevity. There will be one PW(typically, VxLAN tunnel) between PE and CE that span the MAN. Such PW acts as the EVPN AC, instead of the real Ethernet VLAN _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
