Hi Renato, > On Jul 14, 2023, at 10:58, Renato Westphal <[email protected]> wrote: > > Hi Acee, > > Thanks for accepting my suggestions. > > Em qui., 13 de jul. de 2023 às 18:23, Acee Lindem > <[email protected]> escreveu: >>> Lastly, this might just be a small nitpick of mine, but I don't think >>> having a "length" leaf for all TLVs and Sub-TLVs adds much value. In >>> my opinion, it's only relevant for unknown TLVs that couldn't be >>> decoded; otherwise, it just adds unnecessary noise. If we take a look >>> at the IS-IS model, for instance, we can see that it doesn't have a >>> "length" leaf for the LSP TLVs and Sub-TLVs. >> >> I’ve removed the three "length" leaves that were fixed length. I left the >> ones that were variable due to contained sub-TLVS. >> Are you saying that these TLVs would be malformed if the length weren’t >> correct? > > No. I just can't see how the TLV/Sub-TLV length is a useful piece of > information. > > For the "unknown-tlv" and "unknown-sub-tlv" lists, I think the > "length" serves a purpose, as the management application might want to > parse the TLV raw data. For known TLVs and Sub-TLVs, I don't see much > point. I understand this might be nitpicking from my side, so feel > free to ignore this suggestion if you prefer.
Let me talk to others. These higher level containers COULD include unknown Sub-TLVs so I was thinking it would be better to include the containing TLV length as well. I agree the length serves no useful purpose for the fixed length Sub-TLVs. Note that it seems NETMOD is going the way for “config=false” information as draft is being proposed for unknown bits - https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/ However, I’m not a fan of this draft. > >>> By the way, I've generated some sample data using the updated module. >>> Feel free to check it out here: >>> http://westphal.com.br/holo/ospfv3-topo/ >> >> What testing infra-structure are you using? > > It's a tool called netgen I wrote several years ago, mostly for > personal use. It uses Linux namespaces and veth interfaces to create a > virtual topology. Today there are similar tools that are better > documented and maintained, but I'm too lazy to migrate to those tools > so I keep using netgen :) Okay, it looked “similar” functionally to the FRR munet stuff but with a different schema, etc. I was just curious. Thanks, Acee > > Best Regards, > -- > Renato Westphal _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
