[Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)
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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Martin Duke's No Objection on draft-ietf-lsr-ospf-reverse-metric-10: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-lsr-ospf-reverse-metric-10: No Objection 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/ -- COMMENT: -- Thanks for handling by DISCUSS. I understand you and Alvaro are working on the details, but I'll be satisfied with the outcome of that. *** A "don't be stupid" warning in 2.2 certainly wouldn't hurt, either. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Martin Duke's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-lsr-isis-flood-reflection-11: No Objection 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-isis-flood-reflection/ -- COMMENT: -- The introduction was extremely clear and useful; thank you. This document could use some text about what Experiment is being conducted, success criteria, etc. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Martin Duke's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ -- COMMENT: -- It might be helpful to define “ignore” as “skip the number of octets indicated by the length field.” An alternate interpretation might skip the number of bytes implied by the type code, if the type is known. Similarly, I take it that a length value beyond the end of the message ends processing of the PDU, but the PDU as a whole MUST NOT be discarded. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Martin Duke's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-lsr-isis-srv6-extensions-14: No Objection 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ -- COMMENT: -- (5) The paragraph that begins “ In cases where a locator advertisement...” appears to be mangled. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-isis-te-app-14: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ -- COMMENT: -- I know very little about this, but just checking: - I trust that a network that mixes routers that use application attributes, and not, will not lead to long-term routing loops in spite of them not having a common picture of the network? - It is odd that a link that advertises a zero-length flags field means support for RSVP-TE is “ambiguous” (sec 5). What are the implications of this? When is it OK to use a zero-length flags field given this ambiguity? In a standard, can we not decide on a meaning to eliminate the uncertainty? I would appreciate some language here to answer at least the first two questions. - as the TSVart review points out, the length field wastes 3 bits of 7 because the maximum length is 8. You could reserve them or even use them to encode these three legacy applications. Nits: Abstract: In “these link attributes for a given attribute” add a comma after both instances of attribute(s) Sec 4 2)Application. Add a space Sec 5. Missing a period at the end of “existence of link attribute advertisements” ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Martin Duke's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-ospf-te-link-attr-reuse-14: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ -- COMMENT: -- The link attributes are sub-sub-TLVs, but are sections 6 and 7 constantly refer to them as “TLV types”, which seems imprecise. Nits: S/other then/other than Throughout this document, the indefinite and definite articles ‘a’, ‘an’, and ‘the’ are often missing where needed and present where not needed. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
