[bess] Re: draft-mackenzie-bess-evpn-l3mh-proto

["Patrice Brissette (pbrisset)" <[e-mail]>]

Hi Gyan,

Thank you for taking the time to review this work.
The concept of route target is very important due to the usage of EVPN machinery.
EVPN requires the Route Target to work. The concept is leverage for GRT as well to allow EVPN to sync route properly.

A new version of this draft will be public very soon where more edits were made to clarify the overall objective of it.


Regards,

Patrice Brissette

Distinguished Engineer

Cisco Systems







From: Gyan Mishra <[e-mail]>
Date: Wednesday, October 15, 2025 at 18:06
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: Jeffrey (Zhaohui) Zhang <[e-mail]>, Patrice Brissette (pbrisset) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [bess] Re: draft-mackenzie-bess-evpn-l3mh-proto

Hi Jorge & Patrice

Thanks you for clearing articulating the differences between the two drafts.

IP Aliasing draft is strictly about L3 link load balancing extension via EVPN L3 ES for backup path aliasing that is missing.

For operators I can see the IP aliasing leveraging EVPN with adds a new L3 ES for all active multi home.  The trickery behind the draft which I think is well thought out is now the host or appliance connections to the DC fabric can be somewhat opaque and now you can have added redundancy where each L3 link gets a L3 ES and BGP peering for redundancy only need two BGP peers and remaining links are just L3 subnets with L3 ES route import per EVI with ESI group attached for backup path aliasing.

For the Mackenzie draft is related to RFC 4364 L3 VPN use case to provide L3 over L2 LAG load balancing extension for multiple L3 subnet load balancing within a single ES BD.  So it’s L3 subnets over L2 LAG.

I tested this scenario in the lab with BGP even though the document says it’s out of scope I think the issue with IGP would be same for BGP.  So I was able to get a L3 BGP peer to Anycast IRB to  establish fine.  So the BGP peer session establishes to the leaf / PE that is DF and that is where the ARP/ND is learned on that link and not to the NDF leaf.  However every time the session resets it may hash to a different DF based to the DF Algo so not deterministic.  The big problem here is the backup path aliasing is broken for multi home load balancing and that is all solved very well in IP aliasing draft.

Section 2.1  this is what I understand
So we are using the RFC 9136 IP VPN RT for the EVPN RT so BGP can advertise the ES route for the multi home member PEs and populates their  IP VRF by importing the RTs.

Section 2.2 very confusing and not sure I understand the GRT as RTs do not apply

How does this work for GRT if no RT?

Section 2.3 This does sound a lot like the IP aliasing draft solution as it’s talking about L3 ESI multi home group membership for load balancing identical to IP aliasing draft.

Section 2.7 sounds like it’s taking about a composite PE with both IP VPN and IP EVPN and RT5 and preferring the RT5 over IP VPN.  Using the same RT for both IPVPN and EVPN RT5.  I think in general it would be better to prefer RT5 over IP VPN and maybe some unique cases where IP VPN would be preferred.

I think for Mackenzie draft recommendation to maybe splitting out the commentary and recommendations analysis into a separate informational draft and focusing on the solution only in the draft.  When reading it seems like an endless run on design discussion.

Thanks

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347




On Mon, Oct 6, 2025 at 10:27 AM Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

draft-mackenzie-bess-evpn-l3mh-proto focuses on CEs that use a single LAG multi-homed to multiple PEs through Layer 3 interfaces (no BDs, no IRBs). In this scenario, synchronization of ARP/ND/IGMP/MLD and subnet state is required among the PEs connected to the same CE, because only one of the PEs learns that information directly from the CE — a side effect of using a single LAG on the CE.

draft-ietf-bess-evpn-ip-aliasing defines the procedures for aliasing and backup path handling across multiple PEs, as well as mechanisms for fast convergence, when initially only one PE has advertised reachability to a given host route or prefix.

  *   Ethernet aliasing (as defined in RFC7432) applies to forwarding based on destination MAC addresses within a BD/MAC-VRF.
  *   IP aliasing (as defined in this draft) applies to forwarding based on destination IP addresses within an IP-VRF.
IP Aliasing for host routes is described in sections 1.1/1.2. IP Aliasing for Prefixes in section 1.3.

I don’t think there is much overlapping.
In the field, draft-mackenzie-bess-evpn-l3mh-proto is used in RFC4364 networks to simplify multi-homing to CEs. IP Aliasing is used in EVPN layer-3 networks running RFC9135/RFC9136.

Hope it helps.

Thanks.
Jorge


From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 3, 2025 at 5:54 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: Patrice Brissette (pbrisset) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] Re: draft-mackenzie-bess-evpn-l3mh-proto

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information.


Hi Patrice & Jorge

Can you help explain the similarities and differences between differences between these two drafts as they both seem to have some overlap in the problem statement and solution being provided.

https://datatracker.ietf.org/doc/html/draft-mackenzie-bess-evpn-l3mh-proto-06

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ip-aliasing-03

The McKenzie draft uses existing EVPN procedures and AC aware bundle with AC ID to identity which AC are part of a redundancy group for backup path aliasing.

Ip aliasing draft create a new L3 ES L3 ESI per EVI ES route new  L3 ESI redundancy group for backup path aliasing.


Thanks

Gyan


[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347



On Wed, Oct 1, 2025 at 10:42 PM Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]<mailto:[e-mail]>> wrote:
Hi Patrice,

I have some comments/questions for the draft.

When I first read it, I thought it was about using EVPN MH procedures along with all the L2 props – EVIs, MAC-VRFs, BDs, BTs, IRBs, etc. – among the MH PEs (and not involving other PEs at all) for the purpose of MH only. Everything will just work – what would be the purpose of this draft?

Then I realized that,  perhaps, while the EVPN MH-related routes are used, there are no L2 EVIs, MAC-VRFs, BDs, BTs, IRBs – it’s all L3. All the SYNC routes will lead to appropriate l3 states in the VRFs. Is that understanding correct?

If so, I think it needs to be explicitly called at the very beginning – even in the abstraction.

Other comments:

•      I don’t think you need/should use/reference the procedures in the ac-aware bundling. Since it is l3-only and there are no MAC-VRFs/BDs/BTs, there is no need to involve the service models, but you can still use Tag ID in the routes to distinguish between different VLANs. That’s simpler than using the Attachment Circuit IDs. In fact, I see section 2.8 mentioning not using the AC ID – so why not just make the Tag ID the only way and not mention the ac-aware bundling at all?
•      Initially, I was concerned about using the VRF RT by default for the sync routes. That means all other PEs will get the sync routes – even those not on the same MH ES. Then I realized that other PEs may not have negotiated the EVPN SAFI, so they would not get the routes even though the routes carry the VRF route target. It would be good to point that out.
•      While writing the above bullet, I realized that there could be one set of MH PEs and another set of MH PEs, all peering with the same RR. In that case, they would get the sync routes unrelated to them, which is not ideal. I would have preferred the alternative method in Section 2.1 to be the default. Is there a reason for the current choice?
•      A nit question – why do you say “Customer Subnet Route” instead of just “Customer Route”?

I don’t get the following, though:

   The synchronization over GRT is different.  In that specific
   situation, an EVPN instance may be assigned to support non-VPN
   layer-3 services.  The assignment is only serving the purpose of
   providing route targets as requested by [RFC7432]; where RT(s) are
   mandatory per EVPN route.

It mentions that an EVI is used only for the purpose of providing route targets in the case of GRT. But the sync routes will still have to be imported to or associated with the GRT, right? If one is concerned that GRT does not use route targets, I suppose it is more about the fact that route targets are not used to associate/import routes with/to the GRT. Getting a route target from an EVI will not solve that problem. If that is not a problem, then one can always just configure a route target for the GRT, w/o having to create an EVI.

Some nits about the following:

   This extension to [RFC9135] and to [RFC9136] brings EVPN based MC-LAG
   all-active multi-homing load-balancing to various services (L2 and
   L3) delivered by EVPN.  Although this solution is also applicable to
   some L2 service use cases, (example Centralized Gateway) this
   document focuses on the L3VPN [RFC4364] use case to provide examples.

“This extension” is not defined. Perhaps you meant “This document extends [RFC9135] and [RFC9136] procedures”. However, I don’t think you’re extending those procedures – you’re just using the 7432/9135/9136 procedures for this use case.

“… to various services (L2 and L3) delivered by EVPN” is also confusing. We’re only talking about L3 services, right? The L3 services may not be delivered by EVPN either – it could be L3 VPN by rfc4364, or could be GRT using IGP.

It’s not clear to me about the applicability to some l2 service use cases, but I notice that the title is “l3mh-proto”.

Perhaps the following?

   This document adapts [RFC7432], [RFC9135] , and [RFC9136]’s all-active multi-homing procedures to L3 services.

Thanks.
Jeffrey




Juniper Business Use Only
From: Patrice Brissette (pbrisset) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 5, 2025 4:55 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [bess] draft-mackenzie-bess-evpn-l3mh-proto

Hi,

We believe this draft is ready for WG adoption.
How can we move it forward?

Draft is here: https://datatracker.ietf.org/doc/draft-mackenzie-bess-evpn-l3mh-proto/

Regards,
Patrice Brissette
Distinguished Engineer
Cisco Systems



_______________________________________________
BESS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>