# 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? 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? 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 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? 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. 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" Kind Regards, Gunter Van de Velde _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
