Hi Gunter, Thanks for the review. See inline.
> On Jan 28, 2026, at 6:41 AM, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > # Gunter Van de Velde, RTG AD, comments for > draft-ietf-lsr-ospf-ls-link-infinity-14 > > # The line numbers used are rendered from IETF idnits tool: > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-ls-link-infinity-14.txt > > # it took me re-reading few paragraphs and sections to understand the nuance > difference between the prior and the new 0xffff and how 0xfffe usage. Is > there a way to add a paragraph to more explicit explain the key difference > and how this differs between old and new meanings? > > # I believe this draft is almost ready for LC. Please find some review > observations next. > > # COMMENTS > # ========== > > 20 calculation for other purposes. In order to advertise these links > 21 and not use them in the base SPF calculation, the metric > 22 LSLinkInfinity (0xffff) is used to specify that the link is > 23 unreachable. to be used > > GV> Line 23 reads odd. Is that intended? No. The fragment "to be used" will be removed. > > 159 algorithm [RFC9350] devoted to specific traffic. These links have an > 160 Extended Administrative Group (EAG) [RFC7308] attribute specifying > 161 the "Red" color. > > GV> Is the use of Extended Administrative Group fully accurate? RFC9350 does > not seem to exclude Administrative Groups. > (see for example section 13 where both Admin and Extended Admin Groups are > discussed). Maybe more correct to be more opaque and simply refer to both as > being "Administrative Groups" instead of Extended Administrative Group? This is just a use case that uses an EAG, It in no way precludes administrative groups. > > 289 When an OSPF router supports [RFC6987] and the Unreachable Link > 290 support capability defined in this document, it MUST also support > 291 advertisement all its non-stub links with a link cost of > 292 MaxReachableLinkMetric (0xfffe). Since MaxLinkMetric will not be > 293 used to indicate a link is unreachable unless all OSPF routers in the > 294 area support this specification as specified in Section 3.2, all > 295 routers in the area will also support the usage of > 296 MaxReachableLinkMetric to discourage the usage of stub router links > 297 for transit traffic. > > GV> This section, at least to me, reads slightly confusing. Can it be more > clarified what routers not supporting this new draft are expected to do? I am > not sure i am able to unmuddle this from the text in this section, because > router not supporting this new draft do not understand the meaning of > MaxReachableLinkMetric and use it as a normal, but rather high. metric. It > could well be i misunderstood the text? if i did, maybe rephrase the text > slightly to help my understanding I think is clear as it is. However, I have added a somewhat redundant statement to clarify the behavior when there are routers in the area that do not support the specified Unreachable Link capability. > > 331 links, the computation may result in the maximum metric. In this > 332 case, OSPF routers supporting this specification can disable the > 333 Unreachable Link support capability and still treat links with > 334 maximum metric as reachable. > > GV> Does the disable explicitly result is the "Unreachable Link support" bit > to be unset? If yes, can this be explicitly added in this section? No!!! I don't know how you could come to this conclusion. This would preclude routers from knowing when they all supported the Unreachable Link capability. > > 336 It is also RECOMMENDED that implementations supporting this document > 337 and auto-costing limit the maximum computed cost to > 338 MaxReachableLinkMetric (0xfffe). > > GV> While i am convinced that most will routing engineers understand > auto-costing, i am not sure that is accurate assumption for everybody in > networking. Maybe add a definition or reference. Auto-costing isn't standardized (other than ietf-ospf.yang model configuration). I'll add something. > > 846 The document does not introduce any new security issues for the OSPF > 847 protocol. The security considerations for [RFC2328],[RFC5340], > 848 [RFC6987], and [RFC7770] are applicable to protocol extension. > > GV> I am not sure this is a correct claim. Assume a rogue router is set/unset > the "Unreachable Link support" bit at a rapid rate, then this instability > will trigger on all routers in the area spf's. This is documented in last > phrase of section "3.2. Unreachable Link Backward Compatibility" I've added this case. Thanks, Acee > > Kind Regards, > Gunter Van de Velde _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
