Re: [Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospf-bfd-strict-mode-09: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]>
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 <
> [e-mail]> 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
>
>