Hi Prasad,
1) Thanks for your feedback about the Index(ed TLV) structure.
2) Ack. We do have such text already in place. It currently reads as "An
NLRI index can be listed as part of multiple Group TLVs within the same
message. NLRI indexes within a Group TLV SHOULD be sorted by the sender.
A Group Index MUST NOT reference an NLRI index 0. A Group TLV MUST NOT
include its own or another Group Index. Multiple non-Group TLVs MAY
point to the same Group Index, i.e., a group can be reused within the
same Route Monitoring message.": would you recommend some edit to it?
3) Surely, always open to feedback. Look forward discussing offline.
4) draft-younsi-grow-bmp-snts proposes to modify the current peer flags
structure so to allow for more. Open question, i will re-iterate also
tomorrow during my presentation of draft-ietf-grow-bmp-tlv, is whether
we want to merge that draft into the TLV draft;
5, 6 10) Ack all!
7) Good point, no it should not in my opinion;
8) We can, surely. I would be grateful to receive some text from you
about the router part;
9) Especially now that we merged e-bit and hence the document became
larger, i agree with you, it makes sense beyond the MUSTs and SHOULDs to
recap what is mandatory, what is optional and hence what is a minimal
implementation supposed to include.
Paolo
On 4/11/25 11:00, Narasimha Prasad S N (snprasad) wrote:
Hi Paolo, Yunan,
On the discussion below:
1> Index field
It would be beneficial to keep the 'index' field optional controlled by the
I bit
a> This provides flexibility for us in defining TLVs that are both dependant
/ independent of NLRIs and leverage them across msg types.
- We are exploring one such use-case for RIB-View TLVs in our draft where
they need to be used with both Route-Mon message or the GEN message.
- The Same would apply to the timestamp TLV defined in
draft-younsi-grow-bmp-snts.
- The stateless parsing TLV defined in this draft also suggests using 0 for
index
b> For use-cases where 'index' does not apply, this saves a few bytes per
message. Especially if used for RMons in scale deployment, millions of such
messages would be sent across the lifetime of a Router, so the benefit though
small, adds up.
Having said that I do see the simplicity of keeping it static and would be
good to see more use-cases from the WG for this.
2> It is good that nested Group TLVs are NOT allowed, Indexed / Grouped TLVs
are already complicated to implement. Can we add some explicit text that this
isn’t allowed please.
A few more comments :
3> Since the scope of this draft is widened to more TLVs 😊, can we leverage the
'v4' version to add other things to the draft, that would replace previous
definition rather than defining new msg types or bumping version again ? I could
discuss this with you offline.
4> Can we make the Peer Flags 2 bytes or 4 bytes - we are coming close to using up
all the bits recently & the WG started to worry about the size of this field
5> While individual sub-sections mention the ordering of the TLVs, it would be
helpful to have a section that covers the e2e ordering requirement across all the
TLV types (and indexed/group etc within them) and what can be combined or not in
the same message.
6> Add some text around indexing for withdraws (presume it is the same as
updates)
7> Clarify if same BMP connection can carry both v3 and v4 encoded messages ?
8> Should we consider adding migration strategy / guidelines for transitioning
from v3 to v4, both for the router and collector ?
9> Should we define implementation considerations regarding the minimal
features that should be supported from this draft ?
10> More examples covering other variations of indexing and each TLV type would
be very helpful
Thanks
/snnp
(Prasad)
Cisco Confidential
-----Original Message-----
From: Paolo Lucente <[email protected]>
Sent: 04 November 2025 05:24
To: Dhananjay Patki (dhpatki) <[email protected]>;
[email protected]
Cc: [email protected]
Subject: [GROW] Re: Comment on draft-ietf-grow-bmp-tlv
Hi Dhananjay,
Many thanks for your comments. Will fix figures and editorial ones in the next
iteration of the document. Some comments here:
4 + 7 + previous email. You are right that an all-zero index equals to
no-index. I thought to the all-zero index to keep the format static for the
specific message type; i think the trade-off is between slightly more verbosity
(all-zero index) vs a variable structure that needs to be flagged, which is an
extra complication. I'd be for the current choice but i am open to feedback if
there is solid opinion against it;
5. That is right.
8. I agree with your comment. And, little spoiler, next revision of the
document will include something that got a bit left out: TLV for Stats message.
Stats are already TLVs, they should be put in a container, like we did for the
BGP PDU with the BGP PDU TLV in Route Monitoring; this way optional trailing
TLVs can apply to that message too. This came out of a conversation with
Maxence during the hackathon last weekend.
Paolo
On 3/11/25 04:32, Dhananjay Patki (dhpatki) wrote:
A few more comments on this draft.
1. Section 4.2: Instead of ‘set to one’ it should say ‘set to 1’.
2. Section 4.3: E bit set to value 0 must be shown in figure 4. E bit
is mandatory in every TLV.
3. Section 4.4: G bit must be shown in figure 5.
4. Since we may have grouped and non-grouped TLVs, specifying index = 0
to imply that the TLV applies to all NLRIs of the PDU is kind of
redundant. An indexed TLV with index = 0 is as good as a non-indexed
TLV. In that case, we may as well omit the index if its value is
going to be 0.
5. The draft says ‘A Group TLV MUST NOT include its own or /another
Group Index/.’ Does it mean that nested groups are not allowed?
6. In Appendix A, in Figure 6, all TLVs must show E bit set to 0.
7. Section 4.3 states ‘/The reported length in indexed TLVs refers to
the total encoded TLV value (ie. with the length of the index field
excluded)./’. Should we include the ‘I flag’ (as mentioned in my
previous mail below) that specifies if it is an index TLV vs
non-Indexed TLV, then the TLV length should include the length of
the index field.
8. Figure 6 shows NLRI indexes from 1 to 10 and then group indexed
0x000b and 0x000c. That is the group indexes start at one more than
the last NLRI index. Is that necessary? Can the group indexes also
not start from 1? Since we anyway have the G bit, we know that it’s
a group index and not an NLRI index.
9. I think the title of this draft should be ‘BMP Version 4: TLV
Support for all BGP Monitoring Protocol (BMP) Messages’. Though in
this draft the TLV support is being added only for Route Monitoring
and Peer Down (which the abstract mentions anyway), the highlight of
this version is TLV support for all BMP message types.
--
Regards,
Dhananjay
*From: *Dhananjay Patki (dhpatki) <[email protected]>
*Date: *Friday, 31 October 2025 at 11:42 PM
*To: *[email protected]
<[email protected]>
*Cc: *[email protected] <[email protected]>
*Subject: *[GROW] Comment on draft-ietf-grow-bmp-tlv
Hi Paolo, Yunan,
It looks like we can have a combination indexed TLVs and non-indexed
TLVs in the BMP messages. While this draft defined indexed TLVs, we
may still have TLVs that need not be indexed as they won’t be per NLRI
or NLRI group.
*Non-indexed*(Figure 1):
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Type | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*Indexed*(Figure 4): *NOTE*: This figure in the draft does not show
the E bit. But it should show as I have shown below. Also, the length
of Type should be 15 bits and not 2 octets.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*|**E|* Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G| Index (15 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to be able to parse them separately, we need something like
‘I bit’ shown below that indicates whether this is an indexed TLV or
non-indexed TLV?
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|*I*| Type (*14 bits*) | Length (2 octets)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G| Index (15 bits) | /<-- Included based on the value
of I bit/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If I = 0, the TLV won’t have 2 octets of G bit+Index
If I = 1, the TLV will have 2 octets of G bit+index
--
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]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
