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, triggering a storm of TLVs from a potentially large number of neighbors. Each reverse metric advertisement generates N LSAs, increasing the amplification of any sort of misconfiguration or misbehavior far more than a traditional LSAs that is updated too often. 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A "don't be stupid" warning in 2.2 certainly wouldn't hurt, either. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
