Ballot for draft-ietf-lsr-ospf-flex-algo-yang
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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)
Section 7: Consider asking the RFC Editor to swap out RFC 8446 with RFC 9846 (in Auth48) which deprecates it.
Thanks for addressing my DISCUSS and COMMENTs.
I support Med's DISCUSS.
Hi Yingzhen and Acee, The changes made are great [1]. Thank you for taking caring of all the comments in my previous ballot [2]. Much appreciated. Cheers, Med [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-ospf-flex-algo-yang-08&url2=draft-ietf-lsr-ospf-flex-algo-yang-14&difftype=--html [2] https://mailarchive.ietf.org/arch/msg/lsr/cq0moRbY8Dh5s5xJrHzZbpUMKZM/
Thank you to Stewart Bryant for the GENART review.