Hi Xiao Min, thank you for your constructive comments and help in improving the document. I'll upload the new version shortly.
Regards, Greg On Thu, Feb 13, 2025 at 5:40 PM <[email protected]> wrote: > Hi Greg, > > > Thank you for the prompt reply. > > I believe your proposed text changes have addressed all my comments. > > > p.s. It seems the first OLD TEXT should be > > "Figure 1 displays the > extension of VRRP [RFC9568] to bootstrap a tail of the p2mp BFD > session." > And there is one typo in the second NEW TEXT, s/Allso/Also. > > Cheers, > Xiao Min > > Original > *From: *GregMirsky <[email protected]> > *To: *肖敏10093570; > *Cc: *[email protected] < > [email protected]>;[email protected] <[email protected]>; > *Date: *2025年02月14日 08:18 > *Subject: **Re: Document Shepherd Review for > draft-ietf-rtgwg-vrrp-p2mp-bfd* > 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 <[email protected]> wrote: > >> Hi Greg, >> >> >> Thank you for the note on the last open item. >> >> Please see inline. >> Original >> *From: *GregMirsky <[email protected]> >> *To: *肖敏10093570; >> *Cc: *[email protected] < >> [email protected]>;[email protected] <[email protected]>; >> *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 <[email protected]> wrote: >> >>> Hi Greg, >>> >>> >>> Thank you for addressing my comments. >>> >>> Please see my responses inline. >>> Original >>> *From: *GregMirsky <[email protected]> >>> *To: *肖敏10093570; >>> *Cc: *[email protected] < >>> [email protected]>;[email protected] <[email protected] >>> >; >>> *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 <[email protected]> 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 >> > >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
