Dear Jeff,
* This means if there are any lingering issues that must be addressed before publication that they're on the must-fix list. Great. Could you please answer the second question in slide 17 of https://datatracker.ietf.org/meeting/125/materials/slides-125-grow-bmp-yang-model-for-network-telemetry-messages draft-ietf-idr-bgp-model states that the model supports ipv4-unicast and ipv6- unicast address-families and defers the remaining AFI/SAFI to other or future drafts. draft-netana-nmop-message-broker-bmp-telemetry-msg authors intend to cover l3vpn-ipv4-unicast, l3vpn-ipv6-unicast, l2vpn-evpn and ipv4-labeled- unicast for covering operational BGP RIB. The current understanding is that this has not been addressed at the IETF yet correct? * In your case, we see the unit test was "broken" since this example module only worked because it was in the BGP namespace Unclear what you mean with that. The YANG schema tree of https://datatracker.ietf.org/doc/html/draft-netana-nmop-message-broker-bmp-telemetry-msg-02 defined YANG modules were validated with yanglint 5.0.6. We are able to generate the YANG schema tree and validate example message against schema. You find here the yang modules, YANG library, generated YANG schema tree and example messages used for validating with yanglint. https://github.com/network-analytics/draft-netana-nmop-message-broker-bmp-telemetry-message/tree/main/examples https://github.com/network-analytics/draft-netana-nmop-message-broker-bmp-telemetry-message/tree/main/yang Best wishes Thomas From: Jeffrey Haas <[email protected]> Sent: Monday, March 16, 2026 4:39 PM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> Cc: [email protected]; draft-netana-nmop-message-broker-bmp-telemetry-msg.auth...@ietf.org Subject: Re: [Idr] draft-netana-nmop-message-broker-bmp-telemetry-msg Be aware: This is an external email. Thomas, On Mar 16, 2026, at 04:30, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: Thanks a lot! I understood that the document is still active and your are working on an update and implementations. There is a desire to move the document to publication ASAP. This means if there are any lingering issues that must be addressed before publication that they're on the must-fix list. I had a look at https://github.com/mjethanandani/ietf-bgp-yang/blob/v19/src/yang/ietf-bgp-commands.yang and compared to ietf-bmp-bgp-rib-entry https://datatracker.ietf.org/doc/html/draft-netana-nmop-message-broker-bmp-telemetry-msg-02#section-4.1 but was not able to recognize commonalities in terms of having the capability to serialize RIB entries in messages/notifications. This example module, not shipping in the draft, was proof of concept for re-using the various groupings in a different form. The comparison for your use case is a similar need to serialize routes with all of the related content close-by. It's not intended to be a direct replacement for your use case. It is, effectively, a unit test of our modularity for the groupings. In your case, we see the unit test was "broken" since this example module only worked because it was in the BGP namespace. You need the sub-modules exposed as public modules. -- Jeff
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
