Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)

"Acee Lindem (acee)" <acee@cisco.com> Tue, 05 May 2020 18:18 UTC

Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172343A0B9E; Tue, 5 May 2020 11:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=ZeNouh5+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WJQ28yga
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 TSZYn7npfAWA; Tue, 5 May 2020 11:18:19 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483FE3A0B9B; Tue, 5 May 2020 11:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10782; q=dns/txt; s=iport; t=1588702699; x=1589912299; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=JiZ/fENSbMDSBsy0b3D7P42T4E0O6kwJTIn+/yJyQ1M=; b=ZeNouh5+a4LM4nToyi30xsbXcy9hz0fNom5yjaZeTN9AsMs57lejM+1t rx6XeqQXwi8yUBV3xX8PDpTLdXyUy4hvP2+cW1MgNKC7cvl5Zm2ERpMgL asdJ5nHHRw/MSJba+TgJPCrSqhg0McGEdUb/hAhjDyHbiUaJ5f2uyLciC Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ax7JqzBUBpZRoioIHd+qRLf5YsozV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+Huf5BgvDd9aHtRWJG5oyO4zgOc51JAh?= =?us-ascii?q?kCj8he3wktG9WMBkCzKvn2Jzc7E8JPWB4AnTm7PEFZFdy4awjUpXu/vjIXEw?= =?us-ascii?q?/0cwt4OuqzHZTd3Iy70umo8MjVZANFzDO2fbJ1KkCwqgPc/skbiIdvMOA/0B?= =?us-ascii?q?zM93BJYO9Rg2hvIAGe?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AAC/rLFe/5JdJa1eCA4LAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBEgEBAQEBAQEBAQEBAUCBRwKBUlEFblgvKgqEGYNGA41?= =?us-ascii?q?HgQGIeI48gUKBEANUCwEBAQwBARgLCgIEAQGERAIXgWckOBMCAwEBCwEBBQE?= =?us-ascii?q?BAQIBBQRthVYMQhYBhRgBAQEBAwEBEBERDAEBLAsBCwYBCBEEAQEBAgIfBwI?= =?us-ascii?q?EHwYLFQgKBAENBSKDBAGCSwMuAQ6pBwKBOYhhdoEygwABAQWBRkGDCw0Lgg4?= =?us-ascii?q?DBoEOKgGCYolhGoIAgREnHIIYNT6CHkkBAQEBAQGBLAENBQEhgxIzgi2OQoM?= =?us-ascii?q?Hhj6ZUTNKCoJIiBiLNASERh2CW4hhhHuMaZAXiVSCRpECAgQCBAUCDgEBBYF?= =?us-ascii?q?pImZYEQdwFTsqAYIKAQEyUBgNkEIMFxWDOoUUhQQ+dAIBNAIGAQcBAQMJfIt?= =?us-ascii?q?1hEUBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,356,1583193600"; d="scan'208";a="747518941"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 May 2020 18:18:17 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 045IIHUI029061 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2020 18:18:17 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 13:18:17 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 14:18:16 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 5 May 2020 13:18:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h+K+thseFqzYoO44Ly5PxkEKuVf7Dy8cCT9x5GVfJKyzquT37mBs+kZs6sRuQ5Rvg5TUMiDa3Gc5x1lVtOnAjBAOQTuJOnE1x7NVuXU/uK5nH6SnUq+I26Ui0o36Ox2jvbGhUrDVGapDvwmXsQ0+/TglzN8xHI4NJKITR5i1Bw7Yeivl6O42Ss2RUX3Ln69PAipbE8FoUu3mPtprl9NU/7ZxSbIRxsy++mwl04XywluvpzdYDVH9Vm0hg2umbhm5FOKb5OrJLbh3j0qddYiIczWmwPuFpxC4IbuvSRvB8IDFs2P1PGQL4QkJLrUVvCnf/9d5Ej2qlY4kLO5ywr0pnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JiZ/fENSbMDSBsy0b3D7P42T4E0O6kwJTIn+/yJyQ1M=; b=eqUGjNgX44QMhLaMbA/Lyt68FL1qa6Fn9ZeAIWzFs0dp7zPiMWit8GKbpbzx98ZoSG05xsYS50m03/jyup8XQVab77cDIeNEN59Gk/3DEMYdcAPJ8r/bYf+uTBM2TrKHtJR5Q6hQOJEBlu9FP5kQhmnC8N42U4Z43XaOd+T65b74hRl++ybKDIfaMbwAq0D6+1QEtj4BzoEZoNeslsRBQIMk9bMDhhmCCw99iaYSwLMh+PVnW/kWJV+VljpzLsvShgFPkuYWU/N5+JL66KK6k613j3HQCMZ+n1bly+htQHW90HXuq9Ir/Bx986WcrPMXs1HGQemDhOZEWit00sMU7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JiZ/fENSbMDSBsy0b3D7P42T4E0O6kwJTIn+/yJyQ1M=; b=WJQ28ygacaC579IGzdY4L8/F+C6OnA3V9UoDxzdhnOMMWESHo1qp44f7E9Fca3meMwJN3gtvmiojjdxJec/Tg7//DUtbg+n+2dZylHDUWssHkoo8/IsscmYlnESShOIuI+Rlb2QEUQxwIzc2OZz3pBhO9kg9Gq7gH49ZVutei8U=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3206.namprd11.prod.outlook.com (2603:10b6:a03:78::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Tue, 5 May 2020 18:18:14 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e%6]) with mapi id 15.20.2958.029; Tue, 5 May 2020 18:18:14 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "Jeff Tantsura" <jefftant.ietf@gmail.com>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)
Thread-Index: AQHWIwmKKKe5XtaULEyWJ26SKJBBjQ==
Date: Tue, 5 May 2020 18:18:14 +0000
Message-ID: <FC71A41D-0DB1-4BCE-80DD-4EBC60842C14@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e4090608-4703-4ce0-de81-08d7f120ad83
x-ms-traffictypediagnostic: BYAPR11MB3206:
x-microsoft-antispam-prvs: <BYAPR11MB320653EDED3AFF17F8C4B0AAC2A70@BYAPR11MB3206.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0394259C80
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /b2DV2s3HvGl5VdmLO4RvwkXikPb+7Co/Xj/Sdz9nzNwElsiCjOzXLdM7KrdsNUdTQFB0vNhtFrJI27529tYxLtbZdXIu7BLMosHKfoVKXMZop9mXbH+oAvs7/dkaFIfbYPh+MQ+nVsCwt2nuJZy0ENHAHQ7n0cTImwuxusDOndwsEBe1S04hZ/+b2XlVQ43mJwWKK1dDOdCfMHu4EnbydvcwCwnWxNEKe74lDL6uD4l41pw0oU/4pSrUhxSNyJiR6iKzIsasndZHlfEqWeWVbm1bCnVN7CbE9L/DaP9hucxy/Yz6AuPEqvOXgTGSkt0jIc2MMb7TrdqHWH581tTvcqYSoU0dCl0Is8y8/h99Q1gzgCr1rFgHtK1fJC+6uyx8evCJGmuUyluV5cs84rBQHQRVGMM58Be5pm1hl+VWstW+HiMtN7De1h+U+PffDEBHvFTODukVD9F7AN6x4oAVRO1Rm9PqSz9zco75zpsBz1erbaxGIB2tRTzjPq3DgRUUs4FaIyPsz9db0ukB3JYkKTVLgjarV93LGnuBlj71xcOKny6OOnfpGCHqFCcK9gwyKW55gaIlIYcWAYHhEiVhWFAfownjpgrCJjDILGmOpY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(136003)(366004)(39860400002)(33430700001)(2906002)(478600001)(76116006)(6512007)(26005)(4326008)(8936002)(86362001)(66946007)(8676002)(316002)(966005)(66556008)(36756003)(64756008)(66446008)(66476007)(186003)(53546011)(71200400001)(54906003)(66574012)(2616005)(6506007)(110136005)(5660300002)(33440700001)(33656002)(6486002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ePV4TqHS0SABF6Vd2LxtozWSOYSrpkIG0Jdf9MC7sSVvOXe6OvsYiW3tLMdpE6+RVQWI2yI9knjJXReRloUq6DtUZRzCCipmF8IL/cgEmrqmL4pAq/ilqeirSlSFuyBM5cOtqXrW8lMKqIy0XEuHBYlWoARGFvJ+NMmtzWed6J6A3nxXkqmxegHQP/fMR4RS4VH9iUT1wAfWdRCPfli82PvdZ+IeiBn0q1SI/ZJuJZQOuo8nn5LTCjNgbnn6XAttU9wBQd37X4ecpGkN61neuM4mUV1EFCiOYjdOX/eTkdRu1UYgLw466NmbDA/C/5+b2yG1M2YrH6UgWbsMOhgD7ZwbNDNQidFLACDhX/qZUKZDFLXDdrTwOrfh7exyc+77DitJUpZPAhDGPsycZkNCrs6ja+mYSzXK3O/VRIwHuKsR44lP1uW7isXVP+LXAjGuzmnEJrbieqc9Krk30qodHGihSiVPaWSp8trUNFDLaqSA5ysQhJMIh+zQkUpF4KLttWogPPc7ZCSt9Jnl6ZZO6cRJOsvay1dvHlj+eQv9PA+cMzQpuI87wtb9xbkSGav5IU7cyU/ZX0kTcmGdxuP0eFzlh8LwvorSk45oXTvrcD44f0xdmL/l7lIrcof6Qv3EW0iMzMT40T2pRFgi3sVsYl+j2RrnHAj+WZHQHcjtexBWi7DOD072yKf1T8i4WklghMkcQD16Dkp6RKL4GWqDFik1av6t8reiQcPZORz38Ayj2vcMhQ5enldM+La/G4eedtXsZpk5EmWK9EwC9kz59+CT8k55HDkIBzmHhU3Mwck=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <16447CD9F4908A4B99251C2DCF16322A@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e4090608-4703-4ce0-de81-08d7f120ad83
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 18:18:14.6703 (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-CrossTenant-userprincipalname: amep6eYrbuPkPTLzNm1jxoypxnt/Ma8pQOZK/JzQRAZ7cjtaK+UzjHEoc7uq4NCc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3206
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/UW275q2AHl2OjspIpgDnnMBBIsE>
Subject: Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 18:18:23 -0000

Hi Ketan, Ben, 


On 5/5/20, 1:31 PM, "Idr on behalf of Ketan Talaulikar (ketant)" <idr-bounces@ietf.org on behalf of ketant=40cisco.com@dmarc.ietf.org> wrote:

    Hi Ben,

    As co-author of this draft and also editor of the RFC7725bis WG document, please check inline below for one clarification.

You mean RFC7752bis - https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/

Thanks,
Acee

    -----Original Message-----
    From: Jeff Tantsura <jefftant.ietf@gmail.com> 
    Sent: 05 May 2020 04:08
    To: The IESG <iesg@ietf.org>rg>; Benjamin Kaduk <kaduk@mit.edu>
    Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org; idr-chairs@ietf.org; idr@ietf.org; Susan Hares <shares@ndzh.com>om>; aretana.ietf@gmail.com
    Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)

    Hi Ben,

    Many thanks for your comments!
    Please see inline

    Cheers,
    Jeff
    On May 4, 2020, 2:53 PM -0700, Benjamin Kaduk via Datatracker <noreply@ietf.org>rg>, wrote:
    > Benjamin Kaduk has entered the following ballot position for
    > draft-ietf-idr-bgp-ls-segment-routing-msd-17: No Objection
    >
    > When responding, please keep the subject line intact and reply to all 
    > email addresses included in the To and CC lines. (Feel free to cut 
    > this introductory paragraph, however.)
    >
    >
    > Please refer to 
    > https://www.ietf.org/iesg/statement/discuss-criteria.html
    > for more information about IESG DISCUSS and COMMENT positions.
    >
    >
    > The document, along with other ballot positions, can be found here:
    > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing
    > -msd/
    >
    >
    >
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    >
    > Not a whole lot of interesting comments on this one; it seems like a 
    > pretty straightforward codepoint allocation with relevant (security 
    > and
    > other) considerations covered in other documents. I do appreciate the 
    > discussion in the security considerations section; it looks good.
    > [jeff] thank you!
    >
    > This document talks about the MSD as being the depth of a stack that a 
    > given node can "impose". Is there a similar consideration (or protocol
    > element) for what a given node can read/process? (I think I remember 
    > such a document going by, but don't have enough keywords to search for 
    > it efficiently.)
    >
    > [jeff] The drafts talking about Readable Label Stack Deepth Capability 
    > (RLSDC) are draft-ietf-isis-mpls-elc/draft-ietf-ospf-mpls-elc (subcase 
    > in RFC8662)
    >
    > Is there a specific error-handling behavior to use when a Node MSD TLV 
    > is received with a value larger than the value of a Link MSD TLV 
    > associated with that node (for the same MSD-type)? Is that one of the 
    > things "left to the consumer of the BGP-LS information" by Sectoin 7?
    >
    > [jeff] the rule is that most specific (Link MSD) always wins, e.g if 
    > there’s a Node MSD of 5 and Link MSD of 3 for interface-3 and a router 
    > with 3 interfaces -
    > interface-1 and interface-2 will use the value signaled through Node 
    > MSD (5), while interface-3 would use the value from Link MSD In general - the logic is indeed left to the consumer of this information. Advertising different values in Node and Link MSD is not an error.
    >
    >
    > Section 1
    >
    > In the future, it is expected that new MSD-Types will be defined to 
    > signal additional capabilities, e.g., ELs, SIDs that can be imposed 
    > through recirculation, or SIDs associated with another data plane such 
    > as IPv6. MSD advertisements may be useful even if SR itself is not 
    > enabled. For example, in a non-SR MPLS network, MSD defines the 
    > maximum label depth.
    >
    > It's slightly interesting that we still call it "MSD" even though 
    > there are potential uses in a broader scope. Perhaps just a historical 
    > legacy and we need to remain consistent with the name in common use...
    > Though, perhaps the terminology section in this document does not need 
    > to be quite so constrained by the past.
    >
    > [jeff] we have adopted all new use cases to refer to MSD, so far works OK.
    > Indeed, there’s quite some history
    >
    > Section 3
    >
    > identified by the corresponding Router-ID. Node MSD is the smallest 
    > MSD supported by the node on the set of interfaces configured for use. 
    > MSD values may be learned via a hardware API or may be
    >
    > It is a shame that the semantics are already locked in (as was noted 
    > by a previous review that I can't find right now?) and the efficient 
    > encoding of "large per-node value with smaller per-link values for 
    > exceptions" is not admissible.
    >
    > [jeff] please see my response to Martin - 
    > https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs/
    >
    > Section 5
    >
    > MSD-type is not supported. The correct interpretation MUST be 
    > specified when an MSD-type is defined in [RFC8491].
    >
    > Is this "is defined in the registry defined in [RFC8491]" or "is 
    > defined according to the procedures in [RFC8491]" or something else? 
    > The current text doesn't scan properly, as it implies that a future 
    > new MSD-type will be defined in RFC 8491, an immutable document.
    >
    > [jeff] This doesn’t read correct, thanks!
    > RFC8491 states: "The correct interpretation MUST be specified when an MSD-Type is defined"
    > The correct interpretation MUST be specified when an MSD-type is defined, as described in [RFC8491] seems like a better text, would that be OK?
    >
    >
    > Section 7
    >
    > Specifically, the malformed attribute tests for syntactic checks in 
    > the Fault Management section of [RFC7752] now encompass the new BGP- 
    > LS Attribute TLVs defined in this document. [...]
    >
    > Interestingly, the referenced section of 7752 does not seem to 
    > explicitly say that other invariant properties of TLV lengths (e.g., 
    > that they must be a multiple of 2 as for the ones defined by this
    > document) should be checked.
    >
    > [jeff] RFC7752 is being updated as we speak (draft-ietf-idr-rfc7752bis), would a good addition.
    > IDR WG is CCed in this email.

    [KT] We have tried to capture the length verification for known TLVs in https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-03#section-7.2.2 - Would appreciate any comments/inputs on this.

    Thanks,
    Ketan

    >
    > [RFC7752]. The MSD information introduced in BGP-LS by this 
    > specification, may be used by BGP-LS consumer applications like a SR 
    > path computation engine (PCE) to learn the SR SID stack handling
    >
    > https://www.rfc-editor.org/materials/abbrev.expansion.txt lists "PCE" 
    > as having a well-known expansion to "Path Computation Element" (not
    > "engine") that can be used directly in abbreviated form without any 
    > expansion given.
    >
    > [jeff]ack, this is a typo, thanks and changed
    >
    > Section 8
    >
    > issues when propagating the TLVs into BGP-LS. The advertisement of the 
    > node and link attribute information defined in this document presents 
    > no additional risk beyond that associated with the existing node and 
    > link attribute information already supported in [RFC7752]
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr