Hi Rob, We've posted an update that includes the changes discussed in the thread below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-10
Thanks, Ketan On Thu, Oct 6, 2022 at 5:05 PM Ketan Talaulikar <[email protected]> wrote: > Hi Rob, > > Thanks for your review and comments/suggestions. Please check inline below > for responses. > > The changes as discussed will reflect in the next update of this document. > > On Thu, Oct 6, 2022 at 4:44 PM Robert Wilton via Datatracker < > [email protected]> wrote: > >> Robert Wilton has entered the following ballot position for >> draft-ietf-lsr-ospf-bfd-strict-mode-09: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for this document. I think that what is being proposed here is >> useful. >> >> A few minor/nit comments that may improve this document. >> >> Minor level comments: >> >> (1) p 6, sec 5. Operations & Management Considerations >> >> Not for this document, and ss per my other OSPF ballots, I assume that >> the LSR >> WG will update the OSPF YANG model will be updated to accommodate this >> feature. >> > > KT> Ack. I will add a similar reference to the OSPF YANG model draft and > text to what was discussed in the context of the OSPF L2 Bundles draft. > > >> >> (2) p 6, sec 5. Operations & Management Considerations >> >> In network deployments with noisy or degraded links with intermittent >> packet loss, BFD sessions may flap resulting in OSPF adjacency flaps. >> This in turn may cause routing churn. The use of OSPF BFD strict- >> mode along with mechanisms such as hold-down (a delay in the initial >> OSPF adjacency bringup following BFD session establishment) and/or >> dampening (a delay in the OSPF adjacency bringup following failure >> detected by BFD) may help reduce the frequency of adjacency flaps and >> therefore reduce the associated routing churn. The details of these >> mechanisms are outside the scope of this document. >> >> For my understanding, is the expectation that if a device supports this >> feature >> then it would (or is that SHOULD) be enabled automatically? >> > > KT> Since the mechanisms themselves are out of scope, I am not sure if we > can use normative language here. That said, this would be highly > recommended. > > >> >> Nit level comments: >> >> (3) p 6, sec 6. Backward Compatibility >> >> established successfully. Implementations MAY provide a local >> configuration option to enable BFD without the strict-mode which >> results in the router not advertising the B-bit and BFD operation >> being performed in the same way as prior to this specification. >> >> I find the text about enable BFD without the strict-mode to be slightly >> unclear, since presumably it is the OSPF interactions with BFD that the >> configuration is referred to, rather than BFD itself. Perhaps changing >> "strict-mode" to "OSPF BFD strict-mode" might be clearer. >> > > KT> Ack. Will update it. > > Thanks, > Ketan > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
