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.
> * 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.
>
> == 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?
* 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.
>
> == 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];
Although, I couldn't find any specific rules for setting the destination
MAC.
> * 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];
>
> Best Regards,
>
> Xiao Min
>
<<< text/html; charset="US-ASCII"; name="draft-ietf-rtgwg-vrrp-p2mp-bfd-12.diff.html": Unrecognized >>>
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
