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.
* 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
