Greg, Lots of thanks for a prompt response. Please see some comments inline below. Hope these comments would be useful.
Regards, Sasha From: Greg Mirsky <[email protected]> Sent: Monday, July 21, 2025 6:15 PM To: Alexander Vainshtein <[email protected]> Cc: RTGWG <[email protected]> Subject: [EXTERNAL] Re: My questions about draft-ietf-rtgwg-vrrp-p2mp-bfd-12 Hi Sasha, thank you for your comments; much appreciated. Please find my notes below tagged GIM>>. Regards, Greg On Mon, Jul 21, 2025 at 3:48 PM Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Hi all, I have asked the following question about the Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) draft<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-vrrp-p2mp-bfd-12> during the RTGWG session in Madrid today: Q1: What happens if one of the VRRP routers on the LAN in question does not support BFD for Multi-point network? My guess (FWIW) that such routers would receive P2MP BFD packets at high rate and trap them to the CPU – and then to generate Destination Unreachable – Port Unreachable IGMP messages… GIM>> AFAIK, routers are not expected to generate ICMP error message Port Unreachable. If that is the case, VRRP that does not support RFC 8562 would not be able to detect the failure of the Active Router and, likely, would not become the next Active Router. [[Sasha]] First of all, I think routers norma;;y generate ICMP error messages Destination Unreachable – Port Unreachable when they receive IP packets addressed to them but with the TCP/UDP port for which there is no listener– e.g., this is how IP traceroute works when it uses UDP packets instead of ICMP Echo ones (the process stops when the originator receive an IGMP Destination Unreachable – Port Unreachable message instead of TTL Expired). But this is not so important – the main point is that all these packets would be trapped to CPU and not to the HW accelerator used in modern routers to support fast BFD. Generation of IGMP error messages would simply increase this load. With 1-hop IP BFD the session would not ever reach its UP state and, therefore, unicast BFD Control Packets would only sent at 1 packet/second rate. Q2: What happens to the hosts on the LAN in question if the L2 switches implementing this LAN flood multi-point BFD packets? My guess is that these hosts would experience high load receiving these packets at presumably high rate. GIM>> Would these L2 switches be flooding VRRP messages? If that is the case, would the hosts on the LAN segment be flooded by VRRP messages being transmistted at 1 decasecond interval without BFD being used for fast VRRP convergence? As proposed in draft-ietf-rtgwg-vrrp-p2mp-bfd<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-p2mp-bfd>, BFD Control messages source MAC address follows rules set in Section 7.3 RFC 9568<https://datatracker.ietf.org/doc/rfc9568> and transmitted to "VRRP IPvX multicast group", as specified in Section 7.2 of RFC 9568. Am I missing something here? [[Sasha]] I think your argument is not valid – because it is based on an assumption that VRRPv3 is really used with minimal encodable advertisement interval. And, IMHO, this assumption is incorrect - nobody really sends VRRP Advertisement messages at this rate. Were it not so, you would not need fast BFD – regardless of its flavor – for fast detection of Active Down. I have also clarified that, to the best of my understanding, the purpose of using BFD for detection of the Active router down is to replace fast advertisement of VRRP Advertisement messages with something else. GIM>> Indeed, that was our motivation. [[Sasha]] I consider this as agreement with my previous point – nobody wants to use very fast VRRP Advertisements. With this understanding, using some form of 1-hop IP BFD (RFC 5881) looks obviously preferable to using P2MP BFD flavors. GIM>> We believe that using Asynchronous BFD (RFFC 5881) introduces significant overhead (number of BFD Control messages increases times 2 power of N, where N is number of Backup Routers in the given VR ID, and unnecessary control state on the Active Router per a Backup Router that monitors the state of the Active Router) compared with using the Demand BFD mode per RFC 8562. [[Sasha]] AFAIK, most live deployments use just two routers in a given VRRP group, and you need just one 1-hop IP BFD session for that. If you use unsolicited BFD sessions (RFC 9468<https://datatracker.ietf.org/doc/html/rfc9468>) you would need just (N-1) sessions where N is the number of routers in the given VRRP group – each Backup router would set up an unsolicited session vs. the Active one. If the Active router does not support it, the session would not reach its UP state, and the Backup router would not use it for fast detection of the Active Down. Regards, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
