>>> Are you saying you need to know about import complete about per-route as >>> well ? No, I think that would be too much. We just need this indication to at the VRF level. Just an indication of to/from table name would be good enough.
>>> Peer configured down Yes 10-15 minutes seems reasonable, but I think we need to provide full context to the station about this peer for any future state change. For example, another indication if this peer is removed completely by the user. If the peer comes up then anyway peer UP would be sent. >>> BMP health Yes, there needs to some other high priority thread/or other channel to report CPU constraints which is causing slow BMP feed generation. That is probably implementation detail. Other scenario is when BMP may consume lot of memory because it may build up lot of state internally due to slow feed generation. This can be used for network operator to take corrective action. Thanks Mukul From: Narasimha Prasad S N (snprasad) <[email protected]> Date: Thursday, November 6, 2025 at 7:13 PM To: Srivastava, Mukul <[email protected]>, [email protected] <[email protected]> Subject: RE: Some comments from IETF-124 Hi Mukul Thank you for reaching out and sharing your comments, sorry you couldn’t ask your questions during the preso.. 1. Route Import Complete use-case came from Jeff Haas, so happy to extend it with filters based on both your needs. * The example we shared, indicates if the import activity on the router is complete, it is a coarse event (no filters). * From a filters pov, we were thinking may be VRF/RD could be added to indicate amongst which tables/VRFs is the import complete (so extension may be required to indicate From/To etc). We would prefer to keep this at the most to a VRF/table level. * Are you saying you need to know about import complete about per-route as well ? That would make this message per-route then. Scalability would be an issue if we start sending this per-route I think. But happy to hear more on the use-case from you and see if we can accommodate it here or if not use the REL message draft. 1. Peer configured down – we have suggested the time for down needs to be configurable on the router (in Ops considerations), something long enough to avoid false triggers like you bringup. I have heard from Luuk something like 10-15 minutes down is what they had in mind & we agree that would be a long enough time. What do you think ? 1. BMP Health – this is an interesting one. Could you please share more on what you had in mind for the different health metrics please. * When you say lack of CPU, are you suggesting Router send a Health event, that BMP couldn’t send messages because of lack of CPU or other reason code on why it is stuck ? Since this is a BMP message, for it not to be stuck because of lack of CPU or other things, presume some out of band/ higher priority thread would be used to send the health event ? Thanks. Prasad Cisco Confidential From: Srivastava, Mukul <[email protected]> Sent: 07 November 2025 04:38 To: [email protected] Subject: Some comments from IETF-124 Hello authors I had below comments during the presentation which I wasn’t able ask due to time constraints. 1. Route Import Complete: Can you clarify a use case where this event would be useful for a network operator who is monitoring a network. If we want to make this event useful then I would assume it needs some more details like - * From which RIB route has been imported. * To which RIB route has been imported. * Etc. 1. 2. Peer Configured is Down: How long a router waits before sending this event for a configured BGP peer? The BGP peer may take time to come up and it may not be very useful to send this event to station too early. The other event that I think would be useful to add is “BMP health” event. This event can be used by router to indicate the BMP station about its BMP operation health, for example, BMP process on the router might be stuck or not getting enough CPU to generate BMP feed. Thanks Mukul
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
