[bess] Re: draft-wang-bess-l3-accessible-evpn

[Aijun Wang]

Hi, Jorge: It’s possible to subdivide the VNI for backbone EVPN identifier to carry both the BD information and the common VNI part information. But it has the following drawbacks: 1) Normally, the VNI within the packet is used to identify the MAC-VRF itself, and the LSI(for layer 3 accessible EVPN) or VLAN(for layer 2 accessible EVPN) is used to identify the BD within this MAC-VRF. 2) If we subdivide the VNI, then the MAC within different BD domains is actually in different MAC-VRF(because the VNI is different). Then such mode is equivalent to the LSI based layer 3 accessible EVPN, not the LSI aware Bundle layer 3 accessible EVPN. 3) When we compare it again with the VLAN aware Bundle service, we should notice the VLAN information is carried within the inner Ethernet packet itself.  But for LSI aware bundle service, there is no place to carry such information. Jeffery(and also Ali) recommended to reuse the VLAN field in the Ethernet packet itself to identify the LSI. I think it is more reasonable, but we need the PE device to do some map work autonomously at the ingress PE side, and the reverse map at egress PE side.  This can also avoid the extension of VxLAN format itself and may be more easily forwarded within BESS WG(we needn’t coordinate with other WGs or ISE) If the above proposal is accepted, we will revise the document and ask the WG begin the adoption call.  The control plane extension(define one new ESI type) is still necessary, but the forward plane extension can be removed(we should add the mapping process between LSI/VLAN that mentioned above). Thanks the discussions!  I think we are converging more and more now. Aijun Wang China Telecom On Mar 20, 2025, at 22:55, Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org> wrote:  Hi Aijun,   I didn’t have time to ask you this question at the BESS meeting yesterday:   My interpretation of the problem statement is that you need some extra bits in the vxlan header to identify the LSI, hence the BD in “LSI” aware bundle mode.   But could you not use some bits of the VNI itself and therefore have a solution that works without any extensions? The VNI is a 24-bit value. You could e.g., use 20bits (or X) for the common ID and 4bits (or Y) for the “LSI”. Then on the PE, if you have “LSI” aware bundle, you can use those 4 to differentiate each BD. The EVPN routes would be advertised with a different “Y” value for each BD.   In other words, if you need to provide such “structure” for the VXLAN identifier that yields the BD on the ingress lookup, why can't you do it with the existing VNI space? The VNI space gives you 16M values, is that not enough?   Thanks. Jorge   From: Aijun Wang <wangai...@tsinghua.org.cn> Date: Thursday, March 20, 2025 at 8:01 AM To: Jeffrey Zhang <zzhang=40juniper....@dmarc.ietf.org> Cc: Aijun Wang <wangai...@tsinghua.org.cn>, BESS <bess@ietf.org>, draft-wang-bess-l3-accessible-e...@ietf.org <draft-wang-bess-l3-accessible-e...@ietf.org>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn   CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.   Hi, Jeffery:   Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.   The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will be looked up within the specified LSI BD domain only.   If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.   Aijun Wang China Telecom On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org> wrote:  Hi Aijun,   My quote of RFC7432 is in this context:   “If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about)” …   Is that your intention? If not, then the quote should simply be ignored. If yes, your draft should be clear about that (it is not currently); and I will come back with more comments.   Jeffrey       Juniper Business Use Only From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: Monday, March 17, 2025 7:06 AM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> Cc: Aijun Wang <wangai...@tsinghua.org.cn>; BESS <bess@ietf.org>; draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan <jorge.raba...@nokia.com> Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn   [External Email. Be cautious of content]   Hi, Jeffery:   Thanks for your analysis. Let’s try again to converge based on our current  mutual understandings.   First, the conclusion, the solution proposed in this document is necessary.    Here is the reasoning:  What you quoted at https://www.rfc-editor.org/rfc/rfc7432.html#section-9.2.1 is just the traditional layer 2 access EVPN services or one of our layer 3 accessible EVPN service(“LSI based EVPN services”), the protocol extensions proposed in draft-wang-bess-l3-accessible-evpn is mainly for “LSI Aware Bundle EVPN services”, which is not covered by the current RFC7432, or any other existing EVPN related services.   For example:   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.     —-The above description corresponds to “Layer 2 VLAN Bundled EVPN Service”     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.     —-The above description corresponds to “Layer 2 VLAN Based EVPN Service”     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.     —-The above description corresponds to “LSI Based EVPN Service”.   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.     —-The above description is just for some very specific situations, and is not in the scope of current “Layer 2 Access EVPN Service” or the corresponding newly proposed “Layer 3 accessible EVPN service”      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     Aijun Wang China Telecom   Aijun Wang China Telecom On Mar 17, 2025, at 05:12, Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org> wrote: 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 _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org

_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org