Acee - A minor correction. IS-IS has no limit to the number of levels "TLVs" can be nested. The most we have needed thus far is 2 (i.e., sub-sub-TLV) - but there is no protocol limitation. That said, I do not encourage deep nesting - I am not thrilled to have sub-sub-TLVs - but when it makes sense then we define them.
I do agree with you that "raw" seems to be sufficient to cover "unknown" as well. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee) > Sent: Sunday, March 31, 2019 3:00 PM > To: Christian Hopps <[email protected]>; [email protected] > Subject: Re: [Lsr] "unknown TLVs" in YANG data models > > Hi Chris, > > On 3/31/19, 4:24 PM, "Lsr on behalf of Christian Hopps" <lsr- > [email protected] on behalf of [email protected]> wrote: > > So this came up during the second session at IETF104. Our base YANG data > models have "baked" representations of TLV data and then a catch all > "unknown tlv" list for the unrecognized data. > > When a new feature is added that adds a new TLVs it would seem obvious > to also add an augmentation to the base model to provide a similar "baked" > version of the new TLV data. However, does this now mean that the TLV is > no longer "unknown"? Is the data removed from the unknown list or just > present in both cases? > > If the device supports the new feature, it is no longer unknown and > removed. > > > Thinking about this made me realize the following: It's very common to > want to get *all* the TLV data in raw form. With the current design the client > has to settle for reverse engineering the baked data in addition to pulling > the > TLV data from the unknown list. > > We already provide the whole LSA in "raw" format do the data is there. > > A more functional choice is to simply have the "unknonwn-tlv" list return > *all* the TLV data. Whether a TLV is "known" (i.e., a baked version is > present) to the server is already indicated by looking at the servers reported > capabilities. > > Well, this would be a 3rd representation of the same data. Also, note that > TLVs can be nested so this would be applied recursively. I know that IS-IS > only nests two level and refers to the latter as sub-sub-TLV. OSPF doesn't > have this limitation. > > At least with the IS-IS module this could be a minor change (rename > "unknown-tlvs" to "tlvs" and update the description). I believe the change is > also similarly minor for OSPF as well. > > Right - only it would be applied at each level. For example, a TLVs would have > a raw list of sub-TLVs. > > It would be nice, if people agree, and agree its not too late, to make > this > change now rather than wait for the IESG/IETF LC to complete and then have > to do a BIS update. > > I'm not opposed though I'd ask why the raw LSA format would not suffice. > > Thanks, > Acee > > Thanks, > Chris. > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
