Hi Ketan, One quick comment on:
> 1018 9.1. Normative References > > 1020 [IANA-OSPF-FC-Bits] > 1021 IANA, "OSPF Router Functional Capability What is in the draft is correct as this is needed to create the IANA-maintained module (iana-ospf-functional-cap-bits). Cheers, Med > -----Message d'origine----- > De : Ketan Talaulikar via Datatracker <[email protected]> > Envoyé : mardi 3 mars 2026 17:24 > À : The IESG <[email protected]> > Cc : [email protected]; lsr- > [email protected]; [email protected]; [email protected] > Objet : Ketan Talaulikar's Discuss on draft-ietf-lsr-ospf-ls-link- > infinity-23: (with DISCUSS and COMMENT) > > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-lsr-ospf-ls-link-infinity-23: 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67cf11 > 2eeff4d0e51ea08de79415ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > %7C639081518875439034%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=Xwz%2BSTZTpRqXRP38FLH0pLHCRl2rt0jU4pnJ7dywbBM% > 3D&reserved=0 > for more information about how to handle DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found here: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-ospf-ls-link- > infinity%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67cf112 > eeff4d0e51ea08de79415ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C639081518875464864%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=tsPIdbOw6tw7oeX9USLcag8wGLYCTyQJNAMhfxWGzU8%3D& > reserved=0 > > > > -------------------------------------------------------------------- > -- > DISCUSS: > -------------------------------------------------------------------- > -- > > Thanks to the authors and the WG for their work on this document. > > This document attempts to bring in a feature to the OSPF protocol > that has been > there in IS-IS and I believe this to be useful. However, I have some > points > that I would like to discuss about the proposal in the document. > > <discuss-1> I am trying to understand if there is such a thing as an > unreachable > link. Isn't reachability evaluated for nodes and prefixes advertised > by those > nodes? I was trying to find RFCs in either IGPs that cover > unreachability for > links. What we do have is for a link to be not used/considered in > the SPF > computation. That makes the link unusable for SPF, but not > unreachable, right? > This is important since the document talks about > reachability/unreachability of > links throughout the text, while that notion applies to nodes & > prefixes. > > <discuss-2> I would like to discuss if the authors/WG considered > using an > approach similar to RFC8379 to signal un-usability of links in SPF > rather > than disturbing all the link metric constants and calculations that > are widely > implemented. This feature requires a new capability anyway, and so > using > a TLV for this indication would have been just fine? One argument in > favor of > this approach that I would like the WG to consider is that it does > not change > the semantics of existing MaxLinkMetric and its treatment. This > means that in > a partial deployment where this feature is being introduced > gradually, the > nodes don't link to update their Router LSAs in response to change > in the > area-wide capability. I understand that the current approach is > taken from > IS-IS, however, that was a day 1 feature in that protocol while in > OSPF one > needs to factor in existing implementations that perhaps warrant a > different > approach? > > <discuss-3> Doesn't the MaxLinkMetric value remain 0xffff if not all > routers in > an area support this new capability? The value changes to 0xfffe > only when > all routers in an area support this new capability. This means the > values > change based on area-wide capability and hence are no longer > constant.So, > why is there a need to introduce two new "constants" (keeping aside > for now the > 'reachability' in their names), when this document could have simply > changed > the value of MaxLinkMetric to 0xfffe when this capability is turned > on across > the area. This way, the document only needs to update RFC6987. > > <discuss-4> When IS-IS introduced this concept via RFC5305 it > covered both the > IGP as well as TE metric. Should OSPF also not consider covering > both? > > 230 * The OSPFv2 Extended Link TLV of OSPFv2 Extended Link > Opaque LSA > 231 [RFC7684] > > <discuss-5> I don't see how it applies to OSPFv2 Extended Link > Opaque LSA. Which > specific TLV/sub-TLV is going to carry this metric? > > 235 3.2. Unreachable Link Backward Compatibility > > <discuss-6> Can the authors/WG please consider if this section > should be updated > along the lines of > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.rfc-editor.org%2Frfc%2Frfc8770%23section- > 5&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67cf112eeff4d0e51 > ea08de79415ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63908151 > 8875484188%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > C%7C&sdata=RX2zER12mjcEkppAbKfpP2dmVPJqCP9RIlG6txMxBuo%3D&reserved=0 > as that is > quite good and thorough. The current text is missing some important > aspects such > as LSA scope. > > 330 4.1. Configuration Parameters > > 332 Support of the Unreachable Link capability SHOULD be > configurable. > > <discuss-7> Why not MUST? Isn't this a very operator driven thing > and therefore > there MUST be a config option? Also, I don't seem to find the knob > in the YANG > module to mark the link usable/unusable. Am I missing something? > These knobs > (default OFF) are needed for both the router level capability and > the per-link > setting. > > > -------------------------------------------------------------------- > -- > COMMENT: > -------------------------------------------------------------------- > -- > > Please also find below some comments provided inline in the idnits > o/p of v23 > of this document. Look for the tag <EoRv23> at the end to ensure > that you have > received the full review. > > 16 Abstract > > <minor> Could the abstract convey that all these changes are > contingent on > the presence of a new capability? > > 107 In order to advertise these links as unreachable, the > metric > 108 LSLinkInfinity (0xffff) is used to specify that the link > is > 109 unreachable and OSPF routers supporting this > specification will > 110 exclude the link from SPF calculations (subject to > backward- > 111 compatibility constraints, refer to Section 3.2). > > <minor> perhaps s/backward-compatibility constraints/capability > negotiation ? > > 113 Stub Router Advertisement [RFC6987] defines MaxLinkMetric > (0xffff) to > 114 indicate a router-LSA link should not be used for transit > IP traffic. > > <major> Isn't this is a wrong characterization of RFC6987? RFC6987 > is setting > this highest level of metric in the hope that the link gets used > only as a last > resort. The "should not be used" is incorrect. > > 121 Similarly, Label Distribution Protocol (LDP) IGP > Synchronization > 122 [RFC5443] specifies OSPF advertisement of MaxLinkMetric > (0xffff) to > 123 indicate that while the OSPF adjacency is in FULL state, > LDP has not > 124 been synchronized between the two neighbors and transit > traffic is > 125 discouraged. This document updates [RFC5443] with > respect to the > 126 advertisement of MaxReachableLinkMetric rather than > MaxLinkMetric. > > <major> You are missing implications on RFC8379 ? > > 218 While the interpretation of LSLinkInfinity is only > required in the > 219 base topology as other topologies are optional [RFC4915], > OSPF > > <major> I am not sure that I understand why MT is being brought in > here. Can you > please elaborate the implications on MT? > > 222 This applies to both the Flex-Algorithm SPF [RFC9350] and > the base > 223 SPF as long as LSLinkInfinity is specified for the OSPF > metric. > > <major> Perhaps what you mean to say is that it applies to Flex-Algo > where the > metric type used for computation is IGP Metric. Please clarify. I > believe it > also applies to Algo 1 - > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w.iana.org%2Fassignments%2Figp-parameters%2Figp- > parameters.xhtml%23igp-algorithm- > types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67cf112eeff4d > 0e51ea08de79415ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390 > 81518875506751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% > 7C%7C%7C&sdata=oJq2BlSyOK0oUMGSomvkAjSLXCkSgOYDRI8g1R3h%2FSs%3D&rese > rved=0 > > 307 An OSPFv3 router can simply advertise R-bit in its > router-LSA options > 308 [RFC5340] to prevent usage stub router links for transit > traffic. > 309 Similarly, OSPFv2 routers supporting [RFC8770] can > advertise the > 310 H-bit in the router-LSA options. > > <major> Please consider removing the above paragraph. It is not > relevant to this > feature and may only cause readers to ponder if they are missing any > relation > between these two separate procedures. > > 334 In some networks, the operator may still want links with > maximum > 335 metric (0xffff) to be treated as reachable. For example, > when the > 336 cost of links is automatically computed based on the > inverse of the > 337 link's bandwidth and there is a mix of low-speed and > high-speed > 338 links, the computation may result in the maximum metric. > In this > 339 case, OSPF routers supporting this specification can > disable the > 340 Unreachable Link capability and still treat links with > maximum metric > 341 as reachable. > > 343 It is also RECOMMENDED that implementations supporting > this document > 344 and auto-costing limit the maximum computed cost to > 345 MaxReachableLinkMetric (0xfffe). An example of auto- > costing would be > 346 to automatically set the link metric to be inversely > proportional to > 347 the link bandwidth (refer to the auto-cost feature in the > ietf- > 348 ospf.yang [RFC9129]). > > <major> What is meant by "OSPF routers supporting ... can disable"? > Would this > not cause churn and instability as capability is turned on/off based > on link > bandwidth changes (e.g., in the case of a bundle?). Why not change > RECOMMENDED > to MUST to fix this issue in a proper way? > > 862 5. Security Considerations > > 864 A compromised OSPF router could advertise changes to its > Unreachable > 865 Link capability rapidly resulting in repeated route > recalculations on > 866 routers in the area supporting this specification > (Section 3.2). > 867 Hence, it is RECOMMENDED that routers supporting this > specification > 868 also support the SPF back-off delay algorithm described > in [RFC8405]. > > <major> It is not just about a compromised router. It could be an > older router > or one that does not support this feature becoming > connected/disconnected to > the rest of the routers in the area. This is enough to cause the > area wide > capability to flip back/forth. This isn't for the security > considerations but > perhaps should be there in the operational considerations - i.e., > recommend > that care be taken when this capability is enabled and some > router(s) in the > network does not support it? > > 1018 9.1. Normative References > > 1020 [IANA-OSPF-FC-Bits] > 1021 IANA, "OSPF Router Functional Capability > Bits", > 1022 > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > ww.iana.org%2Fassignments%2Fospf- > parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67cf112e > eff4d0e51ea08de79415ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C639081518875545183%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > %7C0%7C%7C%7C&sdata=TAVSUhhQV1js7XN6CDdAp5xcYQ2x1mwkpS6pd7qjk1I%3D&r > eserved=0>. > > 1024 [IANA-YANG-Parameters] > 1025 IANA, "YANG Module Names", > 1026 > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > ww.iana.org%2Fassignments%2Fyang- > parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67cf112e > eff4d0e51ea08de79415ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C639081518875569682%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > %7C0%7C%7C%7C&sdata=%2FdnEhjLPO3fBMLUVB9W0cVPYrth%2FarwuSX1p%2Fg5wbb > g%3D&reserved=0>. > > <major> The above two references seem informative to me. > > 1127 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. > Lindem, "OSPF > 1128 for IPv6", RFC 5340, DOI 10.17487/RFC5340, > July 2008, > 1129 > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > ww.rfc- > editor.org%2Finfo%2Frfc5340&data=05%7C02%7Cmohamed.boucadair%40orang > e.com%7Cb67cf112eeff4d0e51ea08de79415ebb%7C90c7a20af34b40bfbc48b9253 > b6f5d20%7C0%7C0%7C639081518875588840%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zG7GM4pblHgcOZafRjdquoX7CI6tnjT > scVvMiuLl1dM%3D&reserved=0>. > > <major> Should RFC5340 not be normative? > > <EoRv23> > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
