Re: [Lsr] "unknown TLVs" in YANG data models

Hi Les,

On 3/31/19, 7:34 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote:

    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.

For OSPF, that ship sailed a long time ago in support of GMPLS Optical network signaling (OTN, WDM, etc). The TE parameters for these technologies nest multiple levels deep and their definition is the purview of the CCAMP WG. However, in OSPF have avoided the repetition of "Sub-" for TLVs below the second level. We only have top-level TLVs (aka, TLVs) and sub-TLVs which are precisely defined for the subsuming TLVs and Sub-TLVs.  I'm not sure who came up with the IS-IS  "sub-sub-" semantics but it was a mistake - especially if we intend to continue the redundant repetition at every level.

Thanks,
Acee

    I do agree with you that "raw" seems to be sufficient to cover "unknown" as well.

       Les

    > -----Original Message-----
    > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
    > Sent: Sunday, March 31, 2019 3:00 PM
    > To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
    > 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-
    > bounces@ietf.org on behalf of chopps@chopps.org> 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
    > Lsr@ietf.org
    > https://www.ietf.org/mailman/listinfo/lsr