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.
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
