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://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Wed, Oct 1, 2025 at 10:42 PM Jeffrey (Zhaohui) Zhang <zzhang= [email protected]> 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) <[email protected]> > *Sent:* Friday, September 5, 2025 4:55 PM > *To:* [email protected]; [email protected] > *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/ > <https://datatracker.ietf.org/doc/draft-mackenzie-bess-evpn-l3mh-proto/>* > > > > Regards, > > Patrice Brissette > > Distinguished Engineer > > Cisco Systems > > > > > > > _______________________________________________ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
