Hello Greg, many thanks for your response. Please see my comments below.
Regards, -- Nicola Nov 29, 2024, 21:19 by gregimir...@gmail.com: > 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. > NS>>> My curiosity here was related on what this DRAFT can bring to the failure-detection of VRRP; we have production systems with adv 1 centisec and at first glance we would like to know if this can be reduced. > > >> >> 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? > > NS>>> My curiosity here was if we can use the standard VRRP packet to bring up the tail session and I'm trying to cover the case where the value of "My Discriminator" can be "guessed" with those values received from the first Active Router packet. In any case of p2mp, I believe a possible problem could be if the head sends the BFD control packet before VRRP. > > >> 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. > > NS>>> It is an extension of my previous response. VRRP is a LAN protocol with 1 to 255 value for the VRID - which is a limit - and the Interface IP which join the multicast path to receive and transmit VRRP packets; can we try to work with those values to guess the "My Discriminator" associated with the VRRP instance and bind it to the BFD session? I believe we will not have two Interfaces with the same IP and VRID in the same LAN. >> 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
