IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Sun, 31 March 2019 22:00 UTC

Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF112022A for <lsr@ietfa.amsl.com>; Sun, 31 Mar 2019 15:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.503
X-Spam-Level:
X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qt4qQoQi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nAEFyhjX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaG_y5pJprvR for <lsr@ietfa.amsl.com>; Sun, 31 Mar 2019 15:00:26 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37AA120225 for <lsr@ietf.org>; Sun, 31 Mar 2019 15:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3014; q=dns/txt; s=iport; t=1554069625; x=1555279225; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=S1adtrfvtnTSTEmwf9B64evkiXXwsIrUouUK7+0FYmw=; b=Qt4qQoQi9yN3LiZeuBNj9J1bPxWg5GiHendWbcONO7t8pCRpNSGRfmv8 AhNc8KBAWa25ONBxUoi32kc49ss72VD4nhWoh43KxsXaJJrtZq0R7liB1 E7//j9dwq0mqaYEkhANFDOFSzexMD7NVR++DhYQiB+eWhkRec+rnH7Uer E=;
IronPort-PHdr: 9a23:j2JplBd5Z43PTf1LCjj4102mlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFlcejNkO2QkpAcqLE0r+effhYiESF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANAAAPN6Fc/5hdJa1jGwEBAQEDAQEBBwMBAQGBUQYBAQELAYE9UAOBXAQLJwqEBINHA4RSimBKgWiXNIEuFIEQA1QOAQEshEACF4UgIjQJDQEBAwEBCQEDAm0cDIVLBiMRDAEBOA8CAQgODAImAgICMBUQAgQBEoMigV4DFQGdXAKKFHGBL4J5AQEFgkaCMxiCDAiBCyQBizIXgX+BEAEnDBOCTD6ELAKDIDGCJo0Di1+MC2AJApNeGoIDizaGc4s/gRiSNgIEAgQFAg4BAQWBTTiBVnAVOyoBgkGCCoNuilNygSiOFAGBHgEB
X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="scan'208";a="252382104"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 22:00:24 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VM0OUh026386 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 22:00:24 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 17:00:24 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 17:00:23 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 31 Mar 2019 17:00:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S1adtrfvtnTSTEmwf9B64evkiXXwsIrUouUK7+0FYmw=; b=nAEFyhjXVUNoBeU6MZbBsPuAb2bmLzJb+RD4o30xTHZ9rk18pGyf81x8VvCvwZg7n139r26V+tPj850PEisJACJjhJxrLLD4a1cXVe+WwM7PqEdQ35rTizkllNgBMrGFiEanjv2bq/DeAbGAwbxY7s+ULlvNUwAagakXyTUByz0=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2227.namprd11.prod.outlook.com (10.174.112.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Sun, 31 Mar 2019 22:00:22 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1%8]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 22:00:22 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Christian Hopps <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] "unknown TLVs" in YANG data models
Thread-Index: AQHU5//Kv0gcxLN43E+UAD+JsSxLR6YmBzeA
Date: Sun, 31 Mar 2019 22:00:22 +0000
Message-ID: <068C6E29-B716-4137-AD71-8898F84285EB@cisco.com>
References: <FEF33125-8B40-4E19-AB72-049C5C9EB2EC@chopps.org>
In-Reply-To: <FEF33125-8B40-4E19-AB72-049C5C9EB2EC@chopps.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [173.38.117.65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 253008c1-a937-4508-cec3-08d6b62445be
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2227;
x-ms-traffictypediagnostic: BN6PR1101MB2227:
x-microsoft-antispam-prvs: <BN6PR1101MB2227AF5BCCAFA6CDB5A03692C2540@BN6PR1101MB2227.namprd11.prod.outlook.com>
x-forefront-prvs: 0993689CD1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(136003)(366004)(376002)(199004)(189003)(6486002)(229853002)(71190400001)(2616005)(106356001)(33656002)(86362001)(68736007)(6116002)(3846002)(105586002)(446003)(11346002)(81156014)(81166006)(8676002)(53936002)(8936002)(486006)(6506007)(76176011)(476003)(305945005)(14454004)(25786009)(26005)(14444005)(99286004)(7736002)(97736004)(5660300002)(82746002)(478600001)(2501003)(256004)(6246003)(102836004)(36756003)(2906002)(110136005)(186003)(83716004)(66066001)(316002)(6436002)(6512007)(71200400001)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2227; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cD6ys0ZmzMwvYPh9GqusAJ3mKiYIG86jnVBf79NMKDUbdwj7o21HSwHgU1NwvncU5gIMA0kv/22zaLSRqntqKUm+RCRUPPmuhXUBQAS6zMJqms0+3VUkwn8c1ppvi/UjDasJWNVhpQZBYf+TETl4GjpHiZEXIdCrg/DxdPzdapcAJ3D5n1ymin8nGy6thCQ7KgtA+LCkYPCUIVf9gesx+Ai7J6PDA8EPALmAS2WT3Xxxhy2Kq/HL7vr2e+J3GfhV9tcza4A1XDsk5fonQ5hGVCNcQQCse6cAkL2tMrPjYLKPNeTws8NJMxlfZCcWnwkf7KQRkFiao05a5Ys/boMeGxjbhDJ7skCJB7c8GCgUqkulTY1T82njX1HBaTYxzgoyo9Q4RI3vxpFoh2Vz5MlxD1CdvMEPNaAv9dR4/V9fz9M=
Content-Type: text/plain; charset="utf-8"
Content-ID: <899FC496BF8D3F41B930A86BFD2A50F2@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 253008c1-a937-4508-cec3-08d6b62445be
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 22:00:22.2962 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2227
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/MPliq6WJ921OIOoK7jaywFa729c>
Subject: Re: [Lsr] "unknown TLVs" in YANG data models
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2019 22:00:28 -0000

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.

v2.23.0 | Report a Bug | By Email