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. > > * To make the term consistent with RFC 8562, s/root/head. >> > GIM>> Good catch, thank you. > > * "As a result, the Backup Router may become the Active router of the >> given Virtual Router or continue as a Backup Router." >> >> For readability, suggest to break the sentences following the above one >> into two bullets, among which >> >> one bullet for "if the former is the case" and another bullet for "if the >> latter is the case". >> > GIM>> Would the following format address your recommendation: > NEW TEXT: > As a > result, the Backup Router may become the Active router of the given > Virtual Router or continue as a Backup Router. > > If the former is the case, then the new Active router MUST select > its new My Discriminator value, include that value in the VRRP > packet to bootstrap a new p2mp BFD session, and start transmitting > p2mp BFD control packets using the Active Router IP address as the > source IP address for p2mp BFD control packets and its new My > Discriminator value. > > If the latter is the case, the Backup Router MUST wait for the > VRRP packet from the new VRRP Active Router that will bootstrap > > the new p2mp BFD session. > > [XM]>>> OK. > >> >> == Section 3.1 >> >> * Suggest to add bullets on how to set the source and destination MAC >> address. Note that in Section 7.2 >> >> of RFC 9568 it specifies that VRRP packets MUST set the source MAC >> address to the Virtual Router MAC >> >> address, is it the same rule applied to BFD Control packets for VRRP? >> Please specify. >> > GIM>> Thank you for the suggestion. I agree with you, keeping selection of > MAC addresses consistent might help implementors. I added the following > text: > NEW TEXT: > Set the source MAC address according to rules in Section 7.3 of > [RFC9568]; > [XM]>>> OK. > > Although, I couldn't find any specific rules for setting the destination > MAC. > > [XM]>>> By using Google it says "The destination MAC address for VRRP > advertisements is 01:00:5E:00:00:12 for IPv4 and 33:33:00:00:00:12 for > IPv6. These are multicast MAC addresses." However, the same as you I > couldn't find the rules in RFC 9568, so I think we can let it be. > >> * If any, please specify how to set the source UDP port. >> > GIM>> The following text is added: > NEW TEXT: > Source UDP port value selection follows the rules defined in > > Section 4 of [RFC5881]; > > [XM]>>> OK. > > > Cheers, > > Xiao Min > >> >> Best Regards, >> >> Xiao Min >> > >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
