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.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
