On Thu, Oct 6, 2022 at 2:44 AM Ketan Talaulikar <[email protected]> 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 < > [email protected]> 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.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
