Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

On Thu, Oct 6, 2022 at 2:44 AM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Martin,
>
> Thanks for your review and comments/feedback. Please check inline below
> for responses.
>
> We have also posted an update that includes the changes discussed below:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09
>
> On Thu, Oct 6, 2022 at 5:56 AM Martin Duke via Datatracker <
> [e-mail]> wrote:
>
>> Martin Duke has entered the following ballot position for
>> draft-ietf-lsr-ospf-reverse-metric-08: Discuss
>>
>> 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-reverse-metric/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I hope this is a quick one.
>>
>> A naive reading of Sec 2.2 implies that a router could generate
>> reverse-metric
>> TLVs quite rapidly,
>
>
> KT> Did you mean send reverse-metric TLV over all its links to its
> neighbors OR generate multiple reverse-metric TLVs with changing values OR
> a combination of them both?
>

A combination of both.

>
>
>> triggering a storm of TLVs from a potentially large number
>> of neighbors. Each reverse metric advertisement generates N LSAs,
>
>
> KT> This is not correct. It would end up generating a single update to the
> neighbors Router LSA. Perhaps more if we think of multiple parallel links
> between those routers. But then there is also dampening built into the
> protocol to slow down the rate of (re)generation of the same Router LSA too
> frequently.
>

Sorry, typo: a storm of LSAs from neighbors, not TLVs. But yeah, OSPF LSA
rate limitations will help here, even if with N routers doing it it's still
pretty bad.


>
>
>> increasing
>> the amplification of any sort of misconfiguration or misbehavior far more
>> than
>> a traditional LSAs that is updated too often.
>>
>
> KT> As described in my first response above, a combination of varying
> reverse metric values being signaled can trigger multiple updates to the
> neighbor's Router LSA - which despite dampening may be problematic.
>
>
>>
>> At the very least, this ought to come up in security considerations, but I
>> wonder if applying some sort of rate limit (beyond which neighbors are
>> free to
>> ignore) would be a firmer way of limiting the problem. I'm flexible on
>> the best
>> way forward.
>>
>
> KT> Added text in the security considerations that cover this issue as
> well as a proposed mitigation. Please let us know if that works.
>

Yes it works.


>
>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> A "don't be stupid" warning in 2.2 certainly wouldn't hurt, either.
>>
>
> KT> I am not sure how exactly to put that into the document. Any help is
> appreciated. Perhaps something that generically goes into the
> Internet-Draft and RFC boilerplate maybe ;-)
>

How about:

Routers SHOULD NOT issue repeated frequent updates to reverse metrics as a
fine-grained response to congestion, as this would generate multiple
neighbor LSAs and route instability.


>
> Thanks,
> Ketan
>
>

I don't know if we need to have a discussion about rate limiting, but I'll
lift the DISCUSS as soon as Alvaro (who supported it) is satisfied.