> On Mar 31, 2019, at 6:00 PM, Acee Lindem (acee) <[email protected]> wrote: > > Hi Chris, > > On 3/31/19, 4:24 PM, "Lsr on behalf of Christian Hopps" > <[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.
OK, I didn't see the entire LSP was included in raw format. Well, that's a bit more work for the client, but the data is still available, so probably not worth the late change. Thanks, Chris. > > > 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. > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
