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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 05 May 2020 17:28 UTC

Return-Path: <ketant@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 417313A0A74; Tue, 5 May 2020 10:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, 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=nLSXakiR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RGJ4U5w/
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 D7EdwA1HGFDV; Tue, 5 May 2020 10:28:56 -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 80F153A0A73; Tue, 5 May 2020 10:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9410; q=dns/txt; s=iport; t=1588699736; x=1589909336; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/tOiE2hRcBfGhYOSpK1PPcEkX34YXFtz4O4IJrXWmVM=; b=nLSXakiRFHpeVNJ1AOCORyQDzn8V0bCobybGtxfOuTHTvwrGYaQoGnlE k5VdJ3+01l568pxnhBukEwpTsrHyD7ZwE44TWmwSvWb0WHkL2qH8uKMF+ uO0t/QD+rTN9Uico1Gm4akLB6IRbVmY0PDMfv0xXHCgvj+RxlPQeaWF/b o=;
IronPort-PHdr: =?us-ascii?q?9a23=3Asg5uJhYXQcUKZfAnPJLb85H/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD4re4vNAzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXxYlTTpju56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAB+obFe/5RdJa1eCA4LAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBEgEBAQEBAQEBAQEBAUCBNQIBAQEBAQsBgVNRBW5YLyo?= =?us-ascii?q?KhBmDRgONRoEBiHiOPIEuFIEQA1QLAQEBDAEBIwoCBAEBhEQCF4FnJDYHDgI?= =?us-ascii?q?DAQELAQEFAQEBAgEFBG2FVgyFcQEBAQEDEhERDAEBNwELBAIBCBEEAQEBAgI?= =?us-ascii?q?mAgICHxEVCAgCBAENBQgagwWCSwMtAQEOqHACgTmIYXaBMoMAAQEFgUZBgwM?= =?us-ascii?q?NC4IOAwaBDioBgmKJYRqBQT+BEUOCGDU+gh5JAQEBAQEBgSwBDQUBI4MQM4I?= =?us-ascii?q?tjkKCSzyGPplRM0oKgkiIGIs0BIRjgluIYYR7jGmQF4lUgkaRAgIEAgQFAg4?= =?us-ascii?q?BAQWBWQMvZlgRB3AVgnABATJQGA2QQgwXFYM6hRSFBD50AgE0AgYBBwEBAwl?= =?us-ascii?q?8kDoBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,356,1583193600"; d="scan'208";a="473740423"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 May 2020 17:28:55 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 045HSt9b014140 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2020 17:28:55 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 12:28:55 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 13:28:53 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 5 May 2020 12:28:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rej3nGjQcSs6HLcxYBMZqgK4SvaZZYgmkFbQBhfsxWhHZeTBFNKC8CunPgdGlOFxEQPkSAI5iVHeBTIBHfcJ5/sUdKb9Z/tVBRMj3YG1Pg3A4DgKNQOHWO8/nO4EnfXz3xHog6ycfeQDT8z6ogeID4kWvcNOOkN4IXAI0Fh92KSUXpErgrh2BgeRGfqftbX5x/E/IGa706IlpXI3sCzfyUijkaTYs04KZh3DIU4TUy9Cpx+rdU/Al+DJg4SPm2XdPM/lRfGJfrXpW1Oioo2+IC0Smewz2Uym2e//Fg8Jez4A/b5sLBK4JIcDojEcXUbBwmH/JsitoOahAQvvk1VzNA==
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=/tOiE2hRcBfGhYOSpK1PPcEkX34YXFtz4O4IJrXWmVM=; b=QkV7bFFMw8SpFMgDvxF/KIUldVgqW9K3bsN4CycuYfoOr7oBE8LY9GevjukzbiPczZmFknFDuofPja+KXanAXxzF65+juTKWzzgzduZrrc3JiwL6uTR1qd/nlYU5Qknv5+fSYov/FNgMCzho/Lkfv2EzrcUjXUpfh1UD2YzkPYpMT+yZwJAejxECO0N1bvAoBQFFGZEf0L0Qfu2K6k+X5SelHqz8fEOSjxvAEUyRXCIMCCnHBZTxnBQA76D4BSIf4hwVGzMeePmPB8pRUfpvgAmGcE8VaxCkEZnpVPuceR60ptLAUvDV8GRDsZ0rgnB3QsTynefYNqAn9MRcnKpJSw==
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=/tOiE2hRcBfGhYOSpK1PPcEkX34YXFtz4O4IJrXWmVM=; b=RGJ4U5w/aLS74Cqb4fqJ2AJSo+URebdaD6BjIELip3aaUbyWttx1CFc/ny0XVDvARstRjQDCWGYdkATyN9NdkZOs/wgmS8gvmJJ4Aga493XFkoNkeHmasgx6S9r42CkZ5qbmx1K8ZfhtFmjV4z2VzLxFgzKRgERINmWYnMqGCF8=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4682.namprd11.prod.outlook.com (2603:10b6:303:2e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Tue, 5 May 2020 17:28:52 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%6]) with mapi id 15.20.2958.030; Tue, 5 May 2020 17:28:52 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: 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>, "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)
Thread-Index: AQHWIl5oMvHnTOQ840+2sMxwiO4f/KiYhLQAgAE6RkA=
Date: Tue, 5 May 2020 17:28:52 +0000
Message-ID: <MW3PR11MB45707F5257E0A583D0E243C8C1A70@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <158862918074.23288.8494237048042781894@ietfa.amsl.com> <7534cbdd-a370-4d40-b49e-a30158d46a44@Spark>
In-Reply-To: <7534cbdd-a370-4d40-b49e-a30158d46a44@Spark>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [49.36.52.93]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7188acad-b409-41cf-f8f3-08d7f119c7d7
x-ms-traffictypediagnostic: MW3PR11MB4682:
x-microsoft-antispam-prvs: <MW3PR11MB46824D4E95657B0857D14476C1A70@MW3PR11MB4682.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: KO/zTUms5WOz88RFxJD+KsneOyNyJWpVHF6jud9m04o+C6WA9V2pjgu5+ZllNzt8jC2eeDOTBc0B5gZsg6kCQ3TcfDqlDoNA7QsDztP16UQea940ZBYsHiCfZA7BUB/B5YfWqmEy4orBNI8bjdlQWcRDbhs1ZSEO7CeIN7WyHBVWedfvwLohKA2OTqUaWaJnAJ/c2TIN7La7YceABH6tnbekjf7LahdGtKawUWTrFjOTHEa2+pnkEOC5haEZBmbEuutnYxc7rT8gSeDBiV+pjWt4EHBHAJUj/KCzEEyhe8S/b2XapztG00ScqJmzX1mUKQ69SF3LUhj7lfGbNOntXCzx5+qDw9wB2bPhmP2GhdlJxJPG/dDWyf6klVfadGoeuQdtuuvKeb+3fyTEVyySzgYhrcBKvcwtOan5dgxeJeW1Xb/P8DSMChs9ZDxtQMNqtGZEIWqP1AtC2wbWMbux9+5ixTCRGzNuZvmQcDDujKIB3IVd3mAVC7CjIf9QlY3ne9/15ZMRe8vasFxsDwQbrfpCZs7ijKTk+4OPd1uOj/Sflsfv8dMXrhBEXxS33mwb2Fd3xgO6jtcFYo/cjt/fehTjgeZV8VFHtbqa7njm4zE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(39860400002)(396003)(366004)(376002)(33430700001)(7696005)(6506007)(8936002)(26005)(4326008)(53546011)(186003)(71200400001)(478600001)(33440700001)(5660300002)(86362001)(33656002)(55016002)(966005)(9686003)(8676002)(66946007)(76116006)(54906003)(110136005)(316002)(66476007)(66556008)(66574012)(66446008)(64756008)(2906002)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: jLKrjchrFkQGvx0OnbuM5uEYxshPYFa2I9HcycqYXwkSLCSBC17MTFHMUNfSDrwVtXSNz3Iifth+8Hs7XOS77ORvLgEnUiBRcXJJBZi6ZP7/bl+5hZyqJlTkbifZGst/5AaMsu/MNEBHsYi3iR/XvDEX5VV/UsUj+bmmNTf3Uc7ICqKaYAbeQXTJriWZi0WLFExuUFBuW0ztfnP01eF4KN87BKW9O9ns5JpZKrsRQO8t8VLlI63WwcG4arIYCF8ZxoZW85eFS7dRA6cNc4968ecjfJi1NCMeKylJCQj3+jADV3/d7eqIfPnnE4jSOkydAS2XlaOT+GZ6Nr3nlICcaqtMgPULV2V1u56qBZAttnnm2WhbyB30WP16h/nzev/p2Eut2YlkX1GPootKFELX1KNGDZDsMG3n7CZFq0Syw7bcd+CIX6lPlD7K3caM7zUdR4cife56+8oFqLQ4qghVGXk4cOOoR2QCEOVPM9hxJuYIawmhrvE5YXZT4iavfAC515t0GaKPoXbhYl2rB483R8QiTNZRyCR2Tbl9S/a9b/K9l34aMsJezZZobPq4hnQAPhWOn+CD34s1hI2w5ZWrU+TcjOV5ygBtxzxt/2mJol8zTaGc8W86k0Qs2wrvxMuuX9iiODqvIUjglVaFfFGThUtz/f5l5oXHEEc+t/qfnt0xe60gkq2zPt8d4CA7/IqfAegr3AcgsSs7sanltY4oswGcSL61wkVQnd49s/uS7MfxpIBC/wMMo2xF1a6oh+RdPw9RWY+ngsHM0ACOCeMD1H4FymTqPyzEBgl+mejwYAY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7188acad-b409-41cf-f8f3-08d7f119c7d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 17:28:52.4714 (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: NtLzz/3FyF8IThrKnjfV07sN3GxRRz4zFdGe5x0JKX79wFdsl5Hb7EAskOMcyWhG4NpMml9xSVIOBw1mA8qwRQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4682
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/EN4nlN_NcPGVUmla_i7_hO9KhFo>
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 17:29:01 -0000

Hi Ben,

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

-----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]