Hi, Regarding VRF/Table Name TLV: Based on my understanding of RFC7854, I think the processing of VRF/Table Name TLV can be the same as Type 0 String TLV of BMP Initiation Message in RFC7854: The VRF/Table Name TLV MAY be included multiple times. If multiple strings are included, their ordering MUST be preserved when they are reported.
At the same time, this spec can also support processing multiple String Information into one composite String and then putting it into one TLV. Thanks, Shunwan -----Original Message----- From: GROW [mailto:[email protected]] On Behalf Of Paolo Lucente Sent: Friday, July 19, 2019 12:22 AM To: Jeffrey Haas <[email protected]> Cc: [email protected] Subject: Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits Hi Jeff, Thank you for your feedback. Inline my comments: > On 18 Jul 2019, at 14:55, Jeffrey Haas <[email protected]> wrote: > > Thanks for addressing my comments. One final reply on this thread: > > On Thu, Jul 11, 2019 at 12:30:53PM +0000, Paolo Lucente wrote: >> Done. This opened a further consideration at my end. The document >> lacks a statement as in >> https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about “TLVs can be sent >> in any order. > > While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by > their code point." > > Many implementations that deal with TLV based protocols will > canonicalize data structures based on the TLVs using sorted > structures. Having them sorted on the wire means the canonicalization step > is cheaper. > > Note that this is a general justification for the procedure and it's > not critical for something like BMP. Suggestion accepted, thank you, i will include it in the next edit. >> Multiple TLVs of the same type can be repeated as part of the same >> message and it is left to the specific use-cases whether all, any, >> the first or the last TLV should be considered.”. In the specific >> case of VRF/Table Name one could have both a VRF id/name and a Table >> Name, hence the same TLV could be repeated twice (my take is that >> it’s a perfectly valid scenario). I’d tackle this case once i get >> green light from you that we are good about how your feedback was >> processed. > > I suspect most vendors will eventually generate a composite name and > send a single TLV for the name. > > It would not shock me at some point if this becomes sufficiently > vendor specific that we start seeing vendor specific TLVs here. Totally, i agree on your both points. My line of thought was: there are two main approaches for using the standard VRF/Table Name TLV: stacking values in a single TLV (what you mention) and breaking values in multiple TLVs. The former method is a given; i was simply thinking why not allowing also for the latter: while it increases flexibility “it does not seem to produce any harm” (tm). Paolo _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
