Ketan, Can you please check the latest and hopefully clear your DISCUS?
Thanks, Acee > On Jun 26, 2026, at 4:19 AM, Ketan Talaulikar via Datatracker > <[email protected]> wrote: > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-lsr-ospf-flex-algo-yang-08: 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://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-ospf-flex-algo-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to the authors and the WG for their work on their document. > > I have two meta topics which I would like to discuss and then a couple of > other > points. > > 1) The link-attr-op-mode knob is not clear since it is neither offering > detailed description nor referencing the RFC 9492 subsections. > > choice link-attr-op-mode { > default "legacy"; >>> Why is this the default? Is that coming from > RFC9492? Note that backwards compatibility is dependent on the > application. leaf legacy { > type empty; > description > "Only send legacy advertisements."; >>> I am assuming this means > advertisement via OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA > that were originally meant for RSVP-TE use? i.e., per section 12.1. > However, this does not work for FlexAlgo. > } > leaf transition { > type empty; > description > "Send both application-specific and legacy > advertisements."; >>> I am assuming this is referring to sec 12.3 > and if so, it is important to point to that section since there > are several considerations. > } > leaf app-specific { > type empty; > description > "Only send application-specific advertisements."; >>> I am not sure > what this means that advertisements via TE Opaque LSA are not even > used for RSVP-TE. This would contradict RFC9492 - please check > section 12.3.4. > } > description > "Link attributes mode. Default to legacy mode for > backward compatibility."; > } > > Based on my understanding of RFC9492, we can only think of an enablement knob > for ASLA advertisements at global level. Certain applications like FlexAlgo > mandate the use of ASLA. For RSVP-TE, use of TE Opaque ("legacy") is > recommended. For others like SR and LFA, it can be either ASLA or "legacy" or > both based on the knob. I am not sure if we want to have this knob on a > per-app > level at least for SR and LFA - for RSVP-TE and FlexAlgo as well as newer > apps, > this is already clearly specified. This is different from IS-IS as OSPF does > not have the L-bit. > > 2) When new sub-TLVs are introduced under ASLA TLV or under FAD TLV, how does > the current structure make augmentation of the module easy and > straightforward? > I am not a YANG expert and hence I would like to cross-check. > > 3) The grouping ospf-te-link-attrs is missing SRLG which is also something > that > is configurable on a per-app basis. > > 4) Can't we use IANA maintained modules for fad-flags > (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-flexible-algorithm-definition-flags > - also shared with IS-IS) and fapm-flags > (https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml#flex-algorithm-prefix-metric-bits) > > > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
