On Fri, Nov 01, 2019 at 07:57:06PM +0000, Colin Petrie wrote: > On 01/11/2019 19:22, Paolo Lucente wrote: > >> The one addition I'd suggest for the document is that information about > >> peer-up/down messages is needed to usefully decode some information or > >> context about the other BMP messages. You'll want a bit of operational > >> procedure in your text about "please save this bit of state in each file”. > > > > Or we can “save this bit of state” in the BMP message itself :-) I > > indeed refer to make this MRT draft depend on BMP v4 ( > > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/ ) since, for > > example, we define there a handful TLVs for Stateless Parsing (it was > > more done to PoC the mechanism but indeed they would result entirely > > useful here). Should this be an approach we'd like to consider, of > > course it opens the door to further considerations, one for all: shall > > these TLVs be made mandatory? > > Yes either the BGP update encoding information need to be in the TLVs > (like in BMP v4) or some more metadata in MRT to store this. > If the TLVs are not mandatory then this would have to be captured via an > MRT method.
Minor issue with TLVs: They're decoration on an entire BMP PDU. An impact of such TLVs on individual prefixes means that you end up impacting route packing in the BGP state in the PDU. More messages, more work to encode/decode. Note that I'm not saying there's anything WRONG with this. However, people are going to find that the cost of decoration is perhaps higher in terms of performance than they may have expected. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
