Hi Renato, Thank you for the review and comments. We really need this.
About the "length", I agree with you and Acee that it's not necessary for some fixed length TLV. However, from coding and modeling perspective, I would think it's better to stay consistent. If we only need length for unknown-tlvs and not the rest, that's fine. But that's not the case, and we have to figure out where it's needed. Also it is a read-only leaf. Thoughts? Thanks, Yingzhen On Fri, Jul 14, 2023 at 8:16 AM Acee Lindem <[email protected]> wrote: > 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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
