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]
