Hi Xiao Min, thank you for your helpful suggestion to clarify the use of the extension of the VRRP Advertisement packet defined in the draft. Please check proposed updates, I hope these address your concern (I attached the diff highlighting all updates): OLD TEXT: Figure 1 displays the extension of VRRP Advertisement packet [RFC9568] to enable a Backup Router, acting as a tail of the p2mp BFD session, to monitor the state of the Active Router, acting as the head of the p2mp BFD session. NEW TEXT: Figure 1 displays the extension of the VRRP Advertisement packet [RFC9568] to enable a Backup Router, acting as a tail of the p2mp BFD session, to monitor the state of the Active Router, acting as the head of the p2mp BFD session. OLD 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 [RFC9568] 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, MUST transmit VRRP Advertisement as shown in Figure 1. Allso, the Active Router starts transmitting BFD control packets with IPvX address associated with the Virtual Router [RFC9568] as a source IP address and the locally allocated value as the value of the My Discriminator field ([RFC5880]).
Regards, Greg On Wed, Feb 12, 2025 at 10:58 PM <xiao.m...@zte.com.cn> wrote: > Hi Greg, > > > Thank you for the note on the last open item. > > Please see inline. > Original > *From: *GregMirsky <gregimir...@gmail.com> > *To: *肖敏10093570; > *Cc: *draft-ietf-rtgwg-vrrp-p2mp-...@ietf.org < > draft-ietf-rtgwg-vrrp-p2mp-...@ietf.org>;rtgwg@ietf.org <rtgwg@ietf.org>; > *Date: *2025年02月13日 05:49 > *Subject: **Re: Document Shepherd Review for > draft-ietf-rtgwg-vrrp-p2mp-bfd* > Hi Xiao Min, > thank you for your expedient response. I am glad that we are rapidly > converging. One more note below tagged GIM2>>. > > Regards, > Greg > > On Wed, Feb 12, 2025 at 2:02 AM <xiao.m...@zte.com.cn> wrote: > >> Hi Greg, >> >> >> Thank you for addressing my comments. >> >> Please see my responses inline. >> Original >> *From: *GregMirsky <gregimir...@gmail.com> >> *To: *肖敏10093570; >> *Cc: *draft-ietf-rtgwg-vrrp-p2mp-...@ietf.org < >> draft-ietf-rtgwg-vrrp-p2mp-...@ietf.org>;rtgwg@ietf.org <rtgwg@ietf.org>; >> *Date: *2025年02月11日 13:16 >> *Subject: **Re: Document Shepherd Review for >> draft-ietf-rtgwg-vrrp-p2mp-bfd* >> Hi Xiao Min, >> thank you for taking on shepherding the draft. Please find my notes below >> tagged GIM>>. Attached, please find the diff highlighting updates applied >> in the new working version of the draft. >> >> Regards, >> Greg >> >> On Sat, Feb 8, 2025 at 1:27 AM <xiao.m...@zte.com.cn> wrote: >> >>> Dear Authors, >>> >>> >>> I did my shepherd review on this concise draft. Comments are as below. >>> >>> >>> == Section 1 & 2 >>> >>> * As a new reader of this draft, I wonder whether it's possible to merge >>> the two sections. >>> >> GIM>> I agree with your suggestion. Please review the updated Section 1 >> as it now includes the problem statement, previously presented in Section >> 2. >> >> [XM]>>> LGTM. >> >> >> * Even more, I noticed there is another WG draft >>> (draft-ietf-rtgwg-vrrp-bfd-p2p) talking >>> >>> about the applicability of p2p BFD for fast failure detection in VRRP, >>> so I wonder whether >>> >>> it's possible to merge the two drafts. >>> >> GIM>> Indeed, two WG documents propose solutions to the same scenario. In >> my opinion, these solutions are very different in terms of their impact on >> the VRRP protocol, additional management of the VRRP, and impact on the >> network. If documents progressed separately, it would be easier for an >> operator and developer to select a particular solution and verify >> implementation conformance to the specification. >> >> [XM]>>> That's acceptable to me. Thanks for your explanation. >> >>> >>> == Section 3 >>> >>> * This section extends VRRP advertisement packet to bootstrap a tail of >>> the p2mp BFD session. >>> >>> As far as I understand, VRRP advertisement is sent by a Active Router to >>> one or more Backup >>> >>> Routers, and there is no any response from the Backup Routers, and as >>> tails of the p2mp BFD >>> >>> session the Backup Routers wouldn't send BFD Control packets to the head >>> of the p2mp >>> >>> BFD session which is the Active Router, so it's not clear to me how the >>> Active Router can determine >>> >>> the extended VRRP advertisement packet has been received and >>> demultiplexed by the Backup >>> >>> Routers correctly. >>> >> GIM>> AFAICS, the Active Router doesn't change its behavior in the >> Virtual Redundancy group because of the presence or absence of a Backup >> Router. If that is correct, what would be the advantage of the Active >> Router to track processing of VRRP advertisements by the Backup Router? >> >> [XM]>>> As to the standard VRRP advertisements, I agree with you. As to >> the extended VRRP advertisements used to bootstrap a tail of the p2mp BFD >> session, I'm not sure whether the logic applies too, because the Active >> Router may choose not to use p2mp BFD if the Backup Routers don't like to >> use it. A potential simple way is to start a timer at the Active Router >> while sending the bootstrap packet, and after time out the Active Router >> can start sending BFD Control packets if no negative reponse received. And >> the format of negative response can be out of scope of this draft. >> > GIM2>> The purpose of the extended VRRP advertisement is to be used for > the lifetime of the Active Router, not only for the period of bootstrapping > of p2mp BFD session. By using the extended VRRP advertisement in such a > way, we seamlessly support a late-joining Backup Router to monitor the > state of the Active Router. And because the Active Router doesn't change > its behavior based on the state and number of available Backup Routers, I > don't see a benefit in introducing a wait timeout on the Active Router or > an explicit response message from a Backup Router. > > [XM-2]>>> If I understand your words correctly, you mean that the added > "Active Router Discriminator" would be always contained in the VRRP > advertisement even after the Active Router starts sending BFD Control > packets, which is different from what I thought it should be (similar to > use LSP Ping for MPLS BFD bootstrapping). If that's the case, I suggest you > to make it explicit in this document. > > > Cheers, > > Xiao Min >
<<< text/html; charset="US-ASCII"; name="draft-ietf-rtgwg-vrrp-p2mp-bfd-12.diff(1).html": Unrecognized >>>
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
