Hi Med, Dhruv, Thank you for your review. We appreciate your thoughtful comments and suggestions.
All your comments have been addressed in latest version. Link: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/11/ Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-ospf-ls-link-infinity-07&url2=draft-ietf-lsr-ospf-ls-link-infinity-11&difftype=--html The main modifications are as follows: 1. Restructuring of Operational Considerations 2. Further splitting of the YANG file into three parts: 1) IANA Module for OSPF Functional Capability Bits 2) YANG Module for OSPF Functional Capability 3) YANG Module for OSPF Advertising Unreachable Links 3. Addressing the comments mentioned in the link below: https://github.com/boucadair/IETF-Drafts-Reviews/commit/a1a5cb614011c9cdf555bc5a498b4055e895f117 Pls check and let us know if there are any further comments. Thanks, Changwang 发件人: [email protected] <[email protected]> 发送时间: 2025年9月22日 21:09 收件人: Acee Lindem <[email protected]>; Dhruv Dhody <[email protected]> 抄送: [email protected]; [email protected]; lsr <[email protected]> 主题: RE: [OPS-DIR]Re: draft-ietf-lsr-ospf-ls-link-infinity-07 early Opsdir review Hi Acee, all, Zooming on this comment from Dhruv: > > The document does not include a dedicated Operational > Considerations section. > > There is a Management consideration, though. Consider changing > that to > > Operational and adding other operational details — some useful > > information in draft-opsarea-rfc5706bis. I also think that your content can be better structured as follows: OLD: 4. Management Considerations 5. YANG Data Model 5.1. Tree for the YANG Data Model 5.2. YANG Data Model for OSPF Advertising Unreachable Links NEW: 4. Operational Considerations 4.1 Configuration Parameters 4.2 YANG Data Model 4.2.1 Tree for the YANG Data Model 4.2.2 YANG Data Model for OSPF Advertising Unreachable Links # IANA-maintained module for OSPF Router Functional Capability Bits Given that there might be in future up to 32 values, I wonder whether you considered offloading this part of the module to an IANA module that will mirror the OSPF Router Functional Capability Bits registry. CURRENT: identity functional-capability { description "Base identity for router informational capabilities."; } identity unreachable-link { base ospf-unreach-link:functional-capability; description "When set, the router is capable of advertising unreachable links."; } # Bonus :-) FWIW, you may find some quick fixes at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/YANG/ietf-ospf-unreachable-links.yang. The diff can be tracked here: https://github.com/boucadair/IETF-Drafts-Reviews/commit/a1a5cb614011c9cdf555bc5a498b4055e895f117. Thank you. Cheers, Med > -----Message d'origine----- > De : Acee Lindem <[email protected]> Envoyé : jeudi 18 septembre > 2025 22:18 À : Dhruv Dhody <[email protected]> Cc : [email protected]; > draft-ietf-lsr-ospf-ls-link- [email protected]; lsr <[email protected]> > Objet : [OPS-DIR]Re: draft-ietf-lsr-ospf-ls-link-infinity-07 early > Opsdir review > > > Hi Dhruv, > > Thanks for the view. > > > On Sep 11, 2025, at 8:56 AM, Dhruv Dhody via Datatracker > <[email protected]> wrote: > > > > Document: draft-ietf-lsr-ospf-ls-link-infinity > > Title: Advertising Unreachable Links in OSPF > > Reviewer: Dhruv Dhody > > Review result: Has Issues > > > > # Early OPSDIR Review of draft-ietf-lsr-ospf-ls-link-infinity > > > > I have reviewed this document as part of the Operational > directorate's > > ongoing effort to review all IETF documents being processed by > the > > IESG. These comments were written with the intent of improving > the > > operational aspects of the IETF drafts. > > > > The document is well-written. The motivation is clear. Thank you > for > > including the use cases with clear examples. > > > > The document does not include a dedicated Operational > Considerations section. > > There is a Management consideration, though. Consider changing > that to > > Operational and adding other operational details — some useful > > information in draft-opsarea-rfc5706bis. > > > > ## Major > > > > - Don't use BCP14 MUST in the abstract. > > I'd already removed this in -08. > > > > > - It is unclear what exactly the update to existing RFCs is. The > draft > > states > > "OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to > > MaxReachableLinkMetric(0xfffe)", RFC 6987 defines this as a > value - > > "MaxLinkMetric: The metric value indicating that a router-LSA > link > > (see Section > > 2) should not be used for transit traffic. It is defined to be > the > > 16-bit binary value of all ones: 0xffff. How to interpret the > update? > > Do you mean to say that every instance of MaxLinkMetric in RFC > 6987 > > and RFC 8770 needs to be updated to MaxReachableLinkMetric? > > It means that MaxReachableLinkMetric is advertised rather than > MaxLinkMetric as the text says. > I've added "with respect to the advertisement of > MaxReachableLinkMetric rather than MaxLinkMetric" in two places. > > > > > - For "Support of the Unreachable Link support capability SHOULD > be > > configurable", because the draft itself highlights loop risks > with > > inconsistent behaviour, shouldn't configurability be a MUST? > > No - the backward compatibility mechanism assures that links with a > metric of MaxLinkMetric are not interpreted as unreachable unless > every OSPF router in the area supports this. > > > > > > ## Minor > > > > - The introduction does not set enough context. Here is a > suggestion > > that you can wordsmith further: "OSPF advertise all active links > in > > the network as part of the link-state database. Each advertised > link > > is assigned a cost that is used by the Shortest Path First (SPF) > algorithm to compute forwarding paths. > > Existing mechanisms allow operators to influence this > computation. For > > example, [RFC6987] describes the use of maximum link metrics to > > discourage the use of a router or its links, and [RFC8770] > specifies > > host-router support that prevents a router from being used for > transit > > traffic. In both cases, however, the links are still considered > > reachable and may still be used under certain circumstances." > > > > - Can we have a clear definition of an Unreachable Link up > front? > > I strongly disagree that this is needed. What part of "unreachable" is > unclear??? > > In certain scenarios, it is necessary to advertise OSPF links > that > are not applicable to the default SPF (Shortest Path > First) calculation > for other purposes. > In order to advertise these links and not use them in the base > SPF > calculation, the metric LSLinkInfinity (0xffff) is used to > specify > that the link is unreachable. > > > > > - Add references for Flex Algo > > This was done in -08. > > > > > > - I had a hard time parsing the 2nd paragraph of 3.1. Let me > know if > > this interpretation is correct - In the base topology, > LSLinkInfinity > > (0xFFFF) MUST always mean unreachable (mandatory). Flex-Algo > feature > > is optional, but if implemented, LSLinkInfinity MUST also mean > > unreachable there. I suggest rephrasing! > > I've re-written much of this. I agree it was confusing. > > > > > > > - Is there a reference for the term 'auto-costing'? If not, > consider > > rephrasing and explaining it. > > Ok - at the risk of confusion, I explained this. > > > > > > - Update security consideration as per draft-ietf-netmod- > rfc8407bis > > Fixed. > > > > > > > ## YANG > > > > - Remove reference RFC XXXX statement after description. > > > > - Should functional-capability be a separate IANA-maintained > module? > > > > ## Nits > > > > - Expand on first use: SPF, > > Fixed. > > > > -s/his document specifies using LSLinkInfinity(oxffff)/This > document > > specifies using LSLinkInfinity(0xffff)/ > > This was changed before. > > > > -s/links between nodes A, and B/links between nodes A and B/ > > Fixed. > > > > > > -s/IGP metic/IGP metric/ > > Fixed. > > > > > -s/it MUST also support advertise all its non-stub links/it MUST > also > > support advertisement of all its non-stub links/ > > Fixed. > > > > > Thanks! > > Dhruv > > > > > > _______________________________________________ > OPS-DIR mailing list -- [email protected] To unsubscribe send an email > to [email protected] ____________________________________________________________________________________________________________ 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. ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
