Hi Dhananjay,
On the “Generic BMP TLVs”, what is the tangible benefit that you would
see by defining it?
I mean, for sure you would not have to define the same code point in
multiple registries -- but that is just like saving some words in a
document and some effort to keep the registries sync'd up (i admit that
we can be a bit smarter with allocations).
On the other hand, guess you have a generic namespace and per message
type namespaces, with the per message type namespaces already populated:
what do you do with existing code points. Also probably not many TLVs
may apply to message types like Init and Term.
Paolo
On 31/10/25 13:15, Dhananjay Patki (dhpatki) wrote:
Hello Authors,
This draft requests Timestamp TLV type be assigned from “BMP Route
Monitoring TLVs” registry. However, the section below indicates that the
timestamp TLV could be included in Peer-Up/Peer-Down messages (since it
mentions ‘BMP session going down or up’).
2.1.1.
<https://datatracker.ietf.org/doc/html/draft-younsi-grow-bmp-snts-01#section-2.1.1>Trigger
Time
<https://datatracker.ietf.org/doc/html/draft-younsi-grow-bmp-snts-01#name-trigger-time>
The Trigger Time is the timestamp of the event which triggered BMP to
report the event. This might be a received message, a BGP peering or a
BMP session going down or up, etc.
Should the Timestamp TLV belong to a new “Generic BMP TLVs” registry
that has TLVs that could be used in multiple BMP message types? This
TLV, in all possibility, can go in messages other than just the Route
Monitoring message.
--
Regards,
Dhananjay
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
