Hi Prasad,
Thanks for picking this up. All clear the pros and cons. Couple of
points from my side below. Where i say "typed" i mean "per message type":
1) Init and Term message do real support a minimal amount of TLVs, very
likely all we want to support in some messages like Route Monitoring or
Peer Up / Down would not apply. Then how generic is generic?
2) We have per-message type defined TLVs, populated. Let's say we create
the generic TLV space. Not that it would not be doable - this is just a
comment - but i see quite some pain in coordinating generic vs typed
and/or migrating code points from typed to generic;
3) What is this real achieving us? Like you said, generic reduces the
flexibility of typed; in the end it seems all we achieve is: less text
on documents (as opposed to real benefit to implementations) and maybe
same code-point across messages. Do you see more to it?
Paolo
On 6/11/25 12:10, Narasimha Prasad S N (snprasad) wrote:
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
<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
<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]
