Rohan, Please see responses inline.
> I reviewed draft-ietf-lsr-ospf-ls-link-infinity-17 and have the following > comments/questions focused on clarity and interoperability. > 1) Section 2.2 Flex-Algorithm use case vs. Section 3.1 pruning semantics > (potential inconsistency) > The Use Case Section 2.2 describes using “Red” links exclusively for > Flex-Algorithm 128 (Metric-Type other than the OSPF metric) and suggests > advertising the OSPF metric of those links as unreachable such that they are > excluded from the base SPF. > The Section 3.1 states that when the OSPF metric is LSLinkInfinity > (0xffff), the link MUST NOT be considered during the associated SPF > computation, and says this applies to both Flex-Algorithm SPF and base SPF as > long as LSLinkInfinity is specified for the OSPF metric. > As written, it implies that the “Red” links would be pruned from > Flex-Algorithm SPF as well, which appears to conflict with the intent in > Section 2.2. Could you clarify the intended behavior? For example: > a) Is LSLinkInfinity intended to exclude the link only for SPF > computations that use the OSPF metric (so a Flex-Algorithm using a different > Metric-Type can still use the link)? > b) Or is LSLinkInfinity intended to exclude the link from all SPF > computations, including Flex-Algorithm SPF (in which case Section 2.2 may > need to be revised)? This comment misses the whole purpose of the document. There are SEPARATE metrics for the base SPF and the Flex Algorithm advertisements. Since the base SPF metric is always advertised for a link, a way is needed to exclude it from the base SPF computation. > 2) Section 3.1 Define “associated SPF computation” and representation > consistency > The Section 3.1 lists multiple TLVs/LSAs where the OSPF metric with > LSLinkInfinity is applicable (Router-LSA, OSPFv2 Extended Link TLV, OSPFv3 > E-Router-LSA Router-Link TLV). It may help to specify: > a) If the LSLinkInfinity must be set consistently across all > applicable representations for a given link (when multiple are advertised), > and > b) If there is any precedence/authority rule when both a base LSA > and an extended representation exist. Again, the whole purpose of the draft is missed with this comment. The metrics are set independently to allow the link to be excluded from the base SPF computation but used in others. > 3) Section 3.2 Unreachable Link Backward Compatibility: clarify “All OSPF > routers in the area” > The Section 3.2 says LSLinkInfinity should be treated as unreachable > only when all OSPF routers in the area advertise the RI LSA Router Functional > Capability Bit. Could you clarify: > a) How should a router determine the set of “all OSPF routers in > the area”? For example, is this based on the current area LSDB (e.g., > Router-LSAs present and not aged out), or is it meant to be based on some > other notion (e.g., configured/expected membership)? Of course, it is the LSDB. I added this in parentheses. > b) How should transient states be handled (e.g., Graceful > Restart, partial/incomplete LSDB during convergence, or brief loss of > connectivity that splits the area’s LSDB view) to ensure routers make > consistent decisions about whether to treat LSLinkInfinity as unreachable? The current content of the LSDB is used in all cases. > c) In the RI LSA, is Router Functional Capability Bit intended to > be area-scoped (advertised separately per area) or AS-scoped (one > advertisement applying to all areas)? Please read RFC 7770. It is clear that these OSPF Router-Information LSAs are scoped. > 4) YANG vs. Security Considerations: clarify what enabled controls > In Section 4.2.5, the YANG leaf unreachable-link-advertisement/enabled > is described as controlling advertisement of unreachable links but Section 5 > says modifying this setting can prevent routers from treating LSLinkInfinity > as unreachable, which sounds like it affects how routers interpret received > information (not just what they advertise). Could you clarify what enabled is > intended to control? : > a) only whether a router advertises unreachable links, > b) whether it also advertises the capability bit, and/or > c) whether it changes how the router interprets LSLinkInfinity. It indicates whether the router OSPF supports the specification, which would include all these. However, a link would only be advertised as unreachable if it is not used in the associated SPF computation. > If it controls more than advertisement, consider clarifying it in YANG > description. > 5) Editorial nits (with section references) > “Similarily” --> “Similarly” > Section 1 (Introduction) — sentence beginning “Similarily, Label Distribution > Protocol…” > Duplicate “and and” > Section 4.1 (Configuration Parameters) — sentence discussing metric > computation “based on the inverse of the link's bandwidth …” > “desabled” --> “disabled” > Section 4.2.5 (YANG Module for OSPF Advertising Unreachable Links) — in the > YANG leaf enabled description. > “proporational” --> “proportional” > Section 4.1 (Configuration Parameters) — sentence stating the metric is > “inversely … to the link bandwidth …” > Table placeholder consistency (“TBA” vs “TBD”) > Section 3.2 (Unreachable Link Backward Compatibility) — Table 1 uses “TBA” > for the capability bit. > Section 6.1 (Registering OSPF Router Functional Capability Bits) — Table 2 > uses “TBD” for the same capability bit. Fixed. Thanks, Acee > Regards, > Rohan Bhosle _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
