[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] "unknown TLVs" in YANG data models
From:       "Les Ginsberg (ginsberg)" <ginsberg () cisco ! com>
Date:       2019-03-31 23:34:37
Message-ID: BYAPR11MB36380AD7476B61E65C2ACDE0C1540 () BYAPR11MB3638 ! namprd11 ! prod ! outlook ! com
[Download RAW message or body]

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 <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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[prev in list] [next in list] [prev in thread] [next in thread]