Thanks, Greg. I like both of these proposed changes. And I am looking forward to seeing more implementations of this as I think it’s generally quite useful.
Joe From: Greg Mirsky <[email protected]> Date: Friday, March 1, 2024 at 12:58 To: Joe Clarke (jclarke) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Opsdir early review of draft-ietf-rtgwg-vrrp-p2mp-bfd-06 Hi Joe, thank you for your comments and suggestions that help in improving this document. Please find my notes below tagged by GIM>>. If these updates address your concerns, I will upload the new version before the deadline. Regards, Greg On Thu, Feb 29, 2024 at 8:05 AM Joe Clarke via Datatracker <[email protected]<mailto:[email protected]>> wrote: Reviewer: Joe Clarke Review result: Has Issues I have been asked to review this document on behalf of the OPS directorate. This document describes the applicability of p2mp BFD to VRRPv3. It also defines an extension to VRRPv3 to support bootstrapping a p2mp BFD session. For the most part, I found the document clear, but there were a couple of issues I had describing the BFD traffic flow and operational process. First, in section 3, there is a statement: "The Active router, configured to use p2mp BFD to support faster convergence of VRRP, starts transmitting BFD control packets with VRID as a source IP address..." I think you mean a virtual IPvX address (or Active router IP) as the source as the VRID is just an 8-bit value. Below you do seem to indicate that the source should be a virtual IP when a Backup changes to Active. GIM>> Thank you for pointing this out to me. I propose the following update: OLD TEXT: The Active router, configured to use p2mp BFD to support faster convergence of VRRP, starts transmitting BFD control packets with VRID as a source IP address and the locally allocated value as the value of the My Discriminator field ([RFC5880]). NEW TEXT: The Active router, configured to use p2mp BFD to support faster convergence of VRRP, starts transmitting BFD control packets with IPvX address associated with the Virtual Router [I-D.ietf-rtgwg-vrrp-rfc5798bis] as a source IP address and the locally allocated value as the value of the My Discriminator field ([RFC5880]). Also in Section 3, there is text that reads: Backup router detects the failure of the Active router, it re- evaluates its role in the VRID . As a result, the Backup router may become the Active router of the given VRID or continue as a Backup router. I feel the use of VRID here is also wrong (or at least confusing). My understanding of VRID is just that 8-bit value for the ID of the Virtual Router. To me it would be clearer if both instances of VRID in the text above were replaced with Virtual Router. GIM>> Thank you for the suggestion. It does make it clearer. Updated as follows: OLD TEXT: When a Backup router detects the failure of the Active router, it re- evaluates its role in the VRID. As a result, the Backup router may become the Active router of the given VRID or continue as a Backup router. NEW TEXT: When a Backup router detects the failure of the Active router, it re-evaluates its role in the Virtual Router. As a result, the Backup router may become the Active router of the given Virtual Router or continue as a Backup router. As a nit, in Section 1, you have text: Bidirectional Forwarding Detection (BFD) [RFC5880] had been originally defined detect I think that should read "originally defined to detect". GIM>> Thank you for catching this, Fixed.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
