Hi Maria (+LSR list), On Aug 13, 2026, at 7:48 AM, Maria Boobesh (mboobesh) <[email protected]> wrote: > > Hi Acee, Yingzhen, > I have been looking at RFC 9129 (YANG Data Model for OSPF) and wanted to get > your thoughts on a possible enhancement to the LSDB overflow notifications. > Existing RFC 9129 > RFC 9129 defines: > • lsdb-approaching-overflow > • lsdb-overflow > The notifications currently report the configured AS-External LSDB limit > (ext-lsdb-limit). They indicate that the Type-5 LSDB is approaching or has > exceeded the configured limit, but do not provide any information about the > routers contributing to the LSDB size. > Problem > When the limit is reached, an operator knows that an overflow condition > exists, but still needs to determine which Advertising Routers are > contributing most of the Type-5 LSAs. This can be determined by walking and > correlating the LSDB, but in a large network it is useful to have this > context available directly with the event notification. > Proposed Enhancement > The idea is to augment the existing notification with the Top-N Advertising > Routers and their Type-5 LSA counts at the time the notification is generated. > For example: > Current notification: > Notification : lsdb-approaching-overflow > Configured Type-5 Limit : 5000 > > Proposed notification: > Notification : lsdb-approaching-overflow > Configured Type-5 Limit : 5000 > > Top Contributors: > Advertising Router Type-5 LSA Count > 10.10.10.10 2200 > 20.20.20.20 1200 > 30.30.30.30 700 > > This information is not intended to identify or declare a root cause. It > provides the operator with the major contributors at the time of the overflow > event, so that further diagnosis can start from that context. > IOS XR already maintains per-Advertising Router LSA counts as part of normal > LSA receive/update/MaxAge processing and exposes this information through > CLI. Based on learning from a customer max-LSA case, IOS XR also reports the > major LSA contributors through syslog when the max-LSA limit is hit. This has > been useful in identifying which routers should be investigated first. > Conceptually, the YANG augmentation could look like: > notification lsdb-approaching-overflow { > uses notification-instance-hdr; > > leaf ext-lsdb-limit { > type uint32; > } > > list top-contributor { > key "advertising-router"; > > leaf advertising-router { > type rt-types:router-id; > } > > leaf type-5-lsa-count { > type uint32; > } > } > } > > A similar augmentation could be applied to lsdb-overflow. > This does not change any OSPF protocol behavior or the overflow procedure. > The intent is only to provide additional operational context with the > existing notification. > Would appreciate your thoughts on whether this information would be useful to > include in the OSPF YANG model.
I agree that this augmentation is backwards compatible and could be useful for overload if the OSPF domain doesn't deploy other mechanisms for monitoring external LSAs. However, I don't see it as a high priority for the OSPF WG. We still have catch-up to do with respect to YANG models corresponding to existing RFCs. Additionally, one could almost take any OSPF (or IS-IS) feature and improve the operational state or notifications. On the other hand, I don't want to dissuade you if you want to write a draft. Thanks, Acee > Thanks, > Boobesh > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
