Jeff, > On Apr 13, 2023, at 15:36, Jeffrey Haas <jh...@pfrc.org> wrote: > > Acee, > > >> On Apr 13, 2023, at 9:57 AM, Acee Lindem <acee.i...@gmail.com> wrote: >>> I unclear on the "ease of use" gained by using YANG bits to define bit >>> positions. >>> IMO is would be much easier to use a protocol-specific leaf if you want to >>> debug >>> a specific protocol. An operational leaf like "raw-foo-field" is sufficient >>> and easy to use. >> >> I have to agree. We did this for LSAs in the ietf-ospf.yang model. > > I see this for TLV and, LSA raw-data, not bit vectors. Different use case. > >> Also, I tend to think this extension (if it were to become a requirement) is >> overkill. > > I believe my comments at various points has been that this is a tool, and > perhaps may be a best practice when it's helpful. > >> Typically, extensions using reserved bits must be backward compatible so why >> do we need to encode these bits explicitly in the YANG models for nodes not >> supporting extensions using the formerly reserved bits??? Also, reserved >> bits typically “MUST be ignored upon receipt” and this is inconsistent with >> that guidance. > > Sorry, did you read the draft?
I scanned the whole thing and read the recommended solution of having a second leaf for the unknown flags. I also saw the entire IETF 116 presentation. I believe I understand your motivation. > > The purpose of this mechanism is to provide visibility into unknown bits - > and yes, previously reserved is the likely case. Such things are useful for > debugging - especially during incremental deployment of new features. > > A common failure mode during some protocol's incremental deployment is the > older code passes along something that is problematic for its neighbor and > something goes awry: > > A ---> B ---> C > > A and C support some new feature on formerly reserved bits. > A sends the PDU to B and B happily ignores the new feature according to > "ignored upon receipt". > B sends the PDU to C and Does Something Bad. > > B isn't at fault. > C is likely buggy. > > You want visibility at B facing C to debug it. I don’t believe the above use case justifies duplicating every bit field. > > I'm not trying to boil the ocean for the raw PDU cases. You've illustrated > an example of one way to model that. I'm picking at a small piece of one use > case. Right, you how would you debug an unknown TLV? Acee > > -- Jeff > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
