Support WG adoption. The draft provides a relevant optimization to A/A multihoming for L3VPN.
Pls see below for some review comments. cheers, Eduard General - If I understand correctly the proposed default behavior is distribute the 'synchronisation' information within the VPN. I would think the recommended behavior would be to keep this distribution, or at least the processing, limited to the PEs involved in the multihoming. This is also suggested in the introduction section. - For completeness also include the case with static PE-CE routing, next to IGP and BGP - It would be good to also include a description of the behavior in case of failures, next to 'normal' operation. Is this part of the planned convergence considerations? Section 1 "which previously required a proprietary ICL control plane link between them", or need for EVI, MAC/VRF, BD as mentioned in the abstract. "This is used to synchronize ARP/ND, multicast Join/Leave, and IGP routes replacing need for ICL link", IGP / BGP instead of only IGP routes? Section 1.3 Could there be cases where IGP messages sent by the CE arrive at the PE that does not have the active adjacency due to inconsistent hashing? Section 1.9 Item 9, and ISL? Section 2.1 "By default, any routes used for synchronization are advertised with IP-VRF route targets." Would be good to clarify the relation with VPN topology. For example in case of a hub spoke topology where the multihoming is at a spoke site, the RTs for the distribution of routes between the sites in the VRF cannot be used for sync info as it will end up at the hub sites only. See general comment, I would recommend to distribute synchronisation info only to the PEs involved in the multihoming. "Alternatively, EVPN routes may be advertised with ES-import", would suggest to make this recommended. Section 2.7 If I understand correctly the ESI approach and IP gateway approach are the same for RFC4364 case. The text is slightly different though. Suggest to align in case it is the same. Section 2.7.2 IP gateway approach for RFC9136 case refers to "before" , not fully clear whether this refers to ESI for RFC9163 or IP GW for RFC4364 ________________________________ From: Jeffrey (Zhaohui) Zhang <[email protected]> Sent: Wednesday, October 22, 2025 01:48 To: 'BESS' <[email protected]> Subject: [bess] WG Adoption and IPR poll for https://datatracker.ietf.org/doc/draft-mackenzie-bess-evpn-l3mh-proto/ Hi, This starts a two-week WG adoption process for https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mackenzie-bess-evpn-l3mh-proto%2F&data=05%7C02%7Ceduard.metz%40kpn.com%7Ce79e344fe42d4859a9df08de10fcd5e4%7Cd77905498c3540eaad75954ac3e86be8%7C0%7C0%7C638966875258342280%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dz80Iwjjys9eI04d%2FQCsE71mO7L2rURGBs%2FuEfPrkVA%3D&reserved=0<https://datatracker.ietf.org/doc/draft-mackenzie-bess-evpn-l3mh-proto/>. Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not progress without answers from all the authors and contributors. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on Nov 4th 2025. Regards, Stephane, Matthew, and Jeffrey Juniper Business Use Only _______________________________________________ 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]
