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? > 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. > 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. > > > ---------------------------------------------------------------------- > 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 ;-) Thanks, Ketan
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
