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]
