Hi Nicola, thank you for your interest in this work and your kind words; much appreciated. I hope that your would not mind adding the RTGWG community to the discussion. Please find my notes below tagged GIM>>.
Regards, Greg On Thu, Nov 28, 2024 at 11:31 PM Nicola Serafini <n.seraf...@tutanota.com> wrote: > Hi Authors, I'm hoping you are doing well and you also enjoined your week. > > First of all, thanks for you work on draft-ietf-rtgwg-vrrp-p2mp-bfd-xx and > for your effort. > > Regarding the DRAFT, I have a first little question about the introduction > section: > > "Single-hop BFD may be used > to enable Backup Routers to detect a failure of the Active router > within 100 msec or faster." > > Here, we state that a failure can be detected within "100 msec or faster"; > in this case, what "msec" states for? > GIM>> Perhaps we can re-word this passage as follows: OLD TEXT: Single-hop BFD may be used to enable Backup Routers to detect a failure of the Active router within 100 msec or faster. NEW TEXT: Single-hop BFD may enable a Backup Router within sub-seconds to detect a failure of the Active Router. I hope that makes it clearer and is consistent with the document. > I'm also trying to answer to the question: Do we really need to extend the > VRRP protocol to achive an autodiscovery capability with BFD? GIM>> I am not sure that the autodiscovery is mentioned in the draft, less positioned as one of the goals of using BFD in VRRP. Could you kindly point out to me to the text that you lead you to such conclusion? > Looks like that the "My Discriminator" field is already present in the > VRRP packet so maybe the Backup Router, after validating the first VRRP > control packet sent by the Active Router, can sub-configure the BFD with > those parameters and relaying on it only if available; GIM>> I checked RFC 9586 <https://datatracker.ietf.org/doc/rfc9568/>whether it defines My Discriminator field, but I couldn't find it. Could you please clarify in which IETF document do you see My Discriminator field defined in VRRP Hello message. > implementing draft-ietf-rtgwg-vrrp-p2mp-bfd might require old VRRP > software implementations to be rewritten in some parts and it might be > challenging to have this adopted and supported by the community. GIM>> I agree that using p2mp BFD for fast detection of a network defect would require SW (at least VRRP implementation) update. AFAICS, that is not uncommon situation, and vendors and operators will make their decisions based on their vision and plans. > (.) Looks like this DRAFT will help to achieve a more fast > failure-detection within a VRRP cluster so it would be great to have it > working independently and autonomously because in that case of BFD service > disruption the VRRP protocol is not affected (how they communicate is > off-topic I believe). > > Finally, section "3. Applicability of p2mp BFD" does not really allow a > fast-convergence but maybe it allows a more fast-failure detection. > GIM>> Yes, formally, the use of BFD detects a network defect. That, in turn, may be used to trigger VRRP convergence. > > I have some dead-lines to meet so I have not too much space on my brain > but I wasn't able to not write you :). I'm hoping my comments are not > off-topic. > > > Have a nice weekend! > > Regards, > > -- > Nicola >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
