Hi Les,
On 3/31/19, 7:34 PM, "Les Ginsberg (ginsberg)" <[email protected]> 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 <[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
