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 <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月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 <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
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
