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. (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? 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. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
