Hi, We have 2 parts to the Generic BMP TLVs
* Definition of the encoding / structure of the TLVs * The name space of the types The main benefit may be is with having a common definition of encoding, so we define it once and re-use them across message types when possible, managing the updates is common (implementations can have re-usable common encode/decode routines). They could still have separate or same name spaces on a case-by-case basis perhaps. But on the con side, having common encoding, limits some flexibility with customization per msg type, Eg: Info TLV has evolved from being generic (and used by init and peer-up) to being specific with init info tlv and peer up info tlv (though they still have the same encoding now). Thanks. Cisco Confidential From: Dhananjay Patki (dhpatki) <[email protected]> Sent: 05 November 2025 22:11 To: Paolo Lucente <[email protected]>; [email protected] Cc: grow <[email protected]> Subject: [GROW] Re: Comment on draft-younsi-grow-bmp-snts-01 Hi Paolo, There’s perhaps no compelling reason, more so since we already have per message type registries. — Regards, Dhananjay Cisco Confidential From: Paolo Lucente <[email protected]<mailto:[email protected]>> Date: Wednesday, 5 November 2025 at 4:57 AM To: Dhananjay Patki (dhpatki) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: grow <[email protected]<mailto:[email protected]>> Subject: Re: [GROW] Comment on draft-younsi-grow-bmp-snts-01 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]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
