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
