< as a co-author of this document > Hi Mahesh,
Top posting to respond on the following part: >> I agree with Juergen that this section could do more to explain the >> motivation >> for the draft, and move all the implementation details to later sections. For >> example, and as Juergen asks, what are the implications of other routers not >> knowing about the advertisement? I know that Ran provided the explanation in >> his response, but it would be even better if that was added here. > > No - we already went down a rat hole with this in the WG and Ketan suggested > to remove it. > Please discuss with him. Ok. I will wait for him to respond. The document did have a very short/terse use-case section in it which was expanded based on the WG discussion in https://www.ietf.org/archive/id/draft-ietf-lsr-anycast-flag-06.html#section-2 by the authors. This was shared by Ran (the editor) with the WG [1]. That was followed by discussion with the WG (please check that thread). It came across that those use-cases were not asked for by the WG and since this was a parity feature for OSPFv2 for something that was already supported in IS-IS and OSPFv3, there was no need for use-cases. The use-cases themselves were related to use in TI-LFA and SR TE which were outside the scope of LSR WG but the discussion did get into those details (I believe this is the "rat hole" that Acee refers to). The need for use-cases was also discussed as part of the RTGDIR review thread. Finally, that use-case section was removed [2] and the required clarifications by the WG was included in the normative text portion. I believe the document has become more succinct as a result of that. Thanks, Ketan [1] https://mailarchive.ietf.org/arch/msg/lsr/4UMJXjcpFnMSv_pQA4ZJz0JVw2M/ [2] https://mailarchive.ietf.org/arch/msg/lsr/DT8wlycVZpQWlWbycYbDVW0KTrU/ On Thu, Jan 8, 2026 at 4:39 AM Mahesh Jethanandani <[email protected]> wrote: > Hi Acee, > > On Jan 6, 2026, at 5:03 PM, Acee Lindem <[email protected]> wrote: > > Hi Mahesh, > > On Jan 6, 2026, at 7:31 PM, Mahesh Jethanandani via Datatracker < > [email protected]> wrote: > > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-lsr-anycast-flag-11: No Objection > > 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to all the folks who have provided review comments on this > document. In > particular want to call out OPSDIR review comments from Juergen, and YANG > Doctor comments provided by Joe Clarke. Some of these comments builds on > the > review they have provided. > > Section 1, paragraph 0 > > An IP prefix may be configured as anycast and as such the same value > can be advertised by multiple routers. It is useful for other > routers to know that the advertisement is for an anycast prefix. > > > I agree with Juergen that this section could do more to explain the > motivation > for the draft, and move all the implementation details to later sections. > For > example, and as Juergen asks, what are the implications of other routers > not > knowing about the advertisement? I know that Ran provided the explanation > in > his response, but it would be even better if that was added here. > > > No - we already went down a rat hole with this in the WG and Ketan > suggested to remove it. > Please discuss with him. > > > Ok. I will wait for him to respond. > > > > > Section 2, paragraph 0 > > An IP prefix may be configured as anycast and it is useful for other > routers to know that the advertisement is for an anycast prefix. > > > I would encourage the authors to add some of the responses Ran gave to the > OPSDIR review to be added in this document. In this case, the question > asked > was, what is prefix and where is it being applied? This might be obvious to > "router folks" but it cannot be assumed that everyone knows what it means. > > Section 4.2, paragraph 0 > > The following is the YANG module: > > > Please reference all the RFC from which the module imports data from or > refers > to. For example, it could say - "This YANG module imports definitions from > [RFC8349] and [RFC9129]". > > Section 6.2, paragraph 3 > > There are a number of data nodes defined in this YANG module that are > writable/creatable/deletable (i.e., config true, which is the > default). These data nodes can be considered sensitive or vulnerable > in some network environments. Write operations (e.g., edit-config) > to these data nodes without proper protection can have a negative > effect on network operations. Specifically, the following subtrees > and data nodes have particular sensitivities/vulnerabilities: > > > Is it true that this YANG module defines multiple data nodes? I can see > only > one. The last statement should also be corrected for its pluarity. > > > As you well know, this is the boiler plate from > draft-ietf-netmod-rfc8407bis. Perhaps > this should be corrected there with "(s)"s rather than "s"s. > > > Yes, it is boilerplate, but nothings says it cannot be modified. > > > > Section 6.2, paragraph 3 > > As specified in Section 2, the AC-flag and the N-flag MUST NOT both > be set to 1. An attacker or a misconfiguration that violates this > rule creates a configuration anomaly. The handling of such anomalies > is defined in Section 2. Modifications to these data nodes without > proper protection could prevent interpreting the IPv4 prefix as > anycast or node-specific. > > > If the idea is to detect a configuration anomaly, why is that not detected > using a "must" statement? Please add one. Otherwise, this hardly belongs > in a > Security Considerations section. > > > We don't normally validate read-only data, i.e., operational state. > Rather, it is rendered as is so that anomalies can be detected. > > > I do not understand. The YANG module is defining a RW leaf for > ‘anycast-flag’. A must statement there could check if the N-flag is set or > not before allowing the flag to be set to true. No? > > Something like > > must > ‘not(/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/node-flag)' > > And I just noticed that the 'identity ac-flag’ is not used in the module. > Is it being used somewhere else? If not, do we need it? > > An example would really help here. > > > > > > Section 6.2, paragraph 3 > > Some of the readable data nodes in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control read access (e.g., via get, get-config, or > notification) to these data nodes. Specifically, the following > subtrees and data nodes have particular sensitivities/ > vulnerabilities: > > > Same issue with pluraity in this section. > > Section 6.2, paragraph 3 > > Exposure of the OSPF link state database may be useful in mounting > Denial-of-Service (DoS) attacks. > > > How is lsdb being exposed by this model? If not, please remove. > > > The new flag is part of an LSA encoding which is in the Link State > Database (LSDB). > > > Sure. But the module that is defining the LSDB or access to it should be > the place where this statement would make sense. > > Thanks. > > > Acee > > > > > > ------------------------------------------------------------------------------- > NIT > > ------------------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may > choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so > there > will likely be some false positives. There is no need to let me know what > you > did with these suggestions. > > "I", paragraph 2 > > OULD be logged as an operational error (subject to rate-limiting). The > AC-fla > ^ > > It appears that a white space is missing. > > "I", paragraph 9 > > eted according to OSPFv2 [RFC7684]. Thus the Flags field of the BGP-LS > Prefix > ^^^^ > > A comma may be missing after the conjunctive/linking adverb "Thus". > > > > Mahesh Jethanandani > [email protected] > > > > > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
