Hi Med, Thanks for correcting me - I missed that aspect.
Thanks, Ketan On Tue, Mar 3, 2026 at 10:39 PM <[email protected]> wrote: > 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]
