Roman Danyliw has entered the following ballot position for draft-ietf-lsr-flex-algo-24: 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-flex-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Charlie Kaufman for the SECDIR review. ** Section 4. We want the mapping between the Flex-Algorithm and its meaning to be flexible and defined by the user. Is a “Flex-Algorithm” (with hyphen) the same as a “Flex Algorithm” (no hyphen) defined in Section 3? Why the difference in notation? ** Section 4. The set consisting of (a) calculation-type, (b) metric-type, and (c) a set of constraints is referred to as a Flexible-Algorithm Definition. Flexible-Algorithm is a numeric identifier in the range 128-255 that is associated via configuration with the Flexible-Algorithm Definition. This text repeats the text in Section 3 verbatim. Is it needed twice? ** Section 5. ... and (b) are in the same Flex-Algorithm definition advertisement scope What is a “FAD advertisement scope?” Should this be an additional term defined in Section 3? ** Section 5.1. Should the explanation of “Metric-Type” say that it’s value comes from the “IGP Metric-Type Registry” per Section 18.1.2? Section 5.1. Is it possible for a peer not to support a particular Metric-Type? If so, have is that signaled? ** Section 5.1. An IS-IS L1/L2 router MAY be configured to re-generate the winning FAD from level 2, ... What is the “winning FAD?” ** Section 5.1 and 5.2. Editorial. Definition of Flex-Algorithm in the TLV. -- Section 5.1 Flex-Algorithm: Single octet value between 128 and 255 inclusive. -- Section 5.2 Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255 inclusive. Should this text be the same? ** Section 5.2. Editorial. Why is the text defining Metric-Type repeated verbatim from what is written in Section 5.1, but Calc-Type and Priority cite Section 5.1? ** Section 6.4. New flag bits may be defined in the future. Implementations MUST check all advertised flag bits in the received IS-IS FADF Sub-TLV - not just the subset currently defined. Let’s assume bits other than those define in this document are set. Is there an IANA registry to check to understand their semantics? ** Section 13.1. During the route computation, it is possible for the Flex-Algorithm specific metric to exceed the maximum value that can be stored in an unsigned 32-bit variable. In such scenarios, the value MUST be considered to be of value 0xFFFFFFFF during the computation and advertised as such. Should this guidance be referenced in Section 8 – that 0xFFFFFFFF could be 0xFFFFFFFF or an overflow value? ** Section 17. This draft adds two new ways to disrupt IGP networks: An attacker can hijack a particular Flex-Algorithm by advertising a FAD with a priority of 255 (or any priority higher than that of the legitimate nodes). An attacker could make it look like a router supports a particular Flex-Algorithm when it actually doesn't, or vice versa. What are the consequences of the described attacker behaviors? Is “disrupt[ing] the IGP networks” just a denial of service? Could it also be steering traffic in a particular way to allow inspection or modification; or to avoid network based mitigations? _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
