Re: [mpls] [Technical Errata Reported] RFC8960 (7059)
tom petch <ietfc@btconnect.com> Wed, 03 August 2022 08:21 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9AAC14CF1C for <mpls@ietfa.amsl.com>; Wed, 3 Aug 2022 01:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOiGdk5_X9uJ for <mpls@ietfa.amsl.com>; Wed, 3 Aug 2022 01:21:34 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2136.outbound.protection.outlook.com [40.107.21.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA01DC14CF13 for <mpls@ietf.org>; Wed, 3 Aug 2022 01:21:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RCzxqTGrOiOkycps7PzMgbMyv30Nua5SMqnfRTW8CFGLpWPYYX/8NjYylAtaRFCF/2A4s+czieFlJm623Jk4LGlJ5IgVqGvsNjBtqcUK+GXAo2a1GaCBQKQAg64+gS2nRMv09uVi7OURvQOhfZwKqUzBTnBG+36B9+X48BGo6EzOYfjdLSexqDo55UA/c5+AyoWT3p/RWNdn720cAIxUfaDhZwUKLpkxdMvj/zyJPAB1LIGsMZ/eN6gv05h7EcCqifSQ8Ds08qcyC0cZOa/Y+Gqhfk76LM7KdgrL+PaZVqYdKk6/I/zYFnHtw9YuelG9Ev5GpxSN9rwV/MrFZlJRNw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BhYf0BVnaY2vF5/EwXFRj7r47+2B0JRqstlO9W84DOM=; b=AFGBScghuczh+cANvku2DNuF+XW0psMST65kgJzvM/TcSf2g4/iRC9elYyZEdSXDjHMgepxBGCbTFuAWsu239DVX2X5LA/9XtykF2bH6zkFAPnQBPrNUp05C4ItG51jDfj4RNiRofk8w0LklWANrtxD04Yfdb962bqZCiW7bQlsXD1t909Gzl/BOf4Cn2pRxTupWTBPqWgY/utVjeEs7UcD96qnsHoQr/P14mr2lpclUxDbw5V9nRJJItLWPh/MEVBJgfTt2oA2Dh0dqpNrifiCv8GbZB/IRmhALwpYPBi/oyITLdFhUuIKysQ2lRSEL+dPjKP5FTpQaqAcHtFojRg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BhYf0BVnaY2vF5/EwXFRj7r47+2B0JRqstlO9W84DOM=; b=rzw6eZpvCz4pZOvi8H9Pv08Yi5199U16fDvaayo5W0+rDLhQfMv8knEDNNqURvz1Z0XieeBTJO1HmnPVEemsLd+6/CEZfxYuDUhEzsCeAO7je+DqmOu9roAdxh1iW6MA6cHVg+l1bDKNj3N1DADNYzoz2zrEwXmtiJQgXM84xdE=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by PAXPR07MB8472.eurprd07.prod.outlook.com (2603:10a6:102:2b6::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.13; Wed, 3 Aug 2022 08:21:30 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::9005:7594:94ee:30a9]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::9005:7594:94ee:30a9%9]) with mapi id 15.20.5504.014; Wed, 3 Aug 2022 08:21:30 +0000
From: tom petch <ietfc@btconnect.com>
To: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
CC: "tsaad@juniper.net" <tsaad@juniper.net>, "Kamran Raza (skraza)" <skraza@cisco.com>, "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>, "vbeeram@juniper.net" <vbeeram@juniper.net>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "jgs@juniper.net" <jgs@juniper.net>, "loa@pi.nu" <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] [Technical Errata Reported] RFC8960 (7059)
Thread-Index: AQHYoz2DAiRH7ZVcGkOj3IfOYvsyX62VNflQgAaX1xuAAP7rgIAAD3sM
Date: Wed, 03 Aug 2022 08:21:30 +0000
Message-ID: <AM7PR07MB6248B66AA26F89734A8DCCBBA09C9@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <20220729112223.B2AED4C29E@rfcpa.amsl.com> <AM7PR07MB6248E186845F71CFA7A0324EA0999@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB624883E90215862389F4C5E5A09D9@AM7PR07MB6248.eurprd07.prod.outlook.com> <B1BB6EE6-B884-48D5-858A-FB2ACD2FB3EA@cisco.com>
In-Reply-To: <B1BB6EE6-B884-48D5-858A-FB2ACD2FB3EA@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 75d9e653-356c-48a8-babf-08da75292b01
x-ms-traffictypediagnostic: PAXPR07MB8472:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +83VHewSIdUrGRjH/tyuPn9+9ojb5PHGareZ5tFe9pf3U+1WZJVFWoWPbdCj8e/u8j+2nbKSo1oPXyVn+w5o/t9rkO6/G/BzJ0DOdPABVXUvc9Ld40vCk7AfOClMzJiJVkUdQ4+DD8pkw9LTx8qbH0QufMzwPUDUK3/S7vMKvCcDhi4e9ceB83soiM0I0XvGxfNt2gIQ4JjTVYM5gHHwHqPhwLsL/4B8lDiVj66J0gyZg9nCbLYXccghLJe8psOhy8sal+iifD+d369n9VVUOzA8rv5mnNMHpRdh6yafrmvS9/K/waGMkPakpAb7iJ/CZ1OfxYwYXbPzxU8nxxsrQtqa16yQ47NwxsgI0WWiNmnV7gUJTfOFJnGLweTGX5h/nUg/krTyrHnGio0cUDRgruLQro96NNiO1/DCJHM9aZT4ApKWKpsqfANzs4VgSZcsLHTJ9PEW2aUkUxT0j/LK3v0w9GBjeKjWnjBaUHjpVDB8oXG5dfzx3hIkTCqFEGxjrZzNlgSFbo5MWEpa9z2j0gJYrGDVIwzaIRADtzgcE6o7CUcpi0MljMu7bpcgv7S+sD+O5kWgPBj9ckOTPceE5iXFaXHw2jLYtOTsZlLkwClOXstIiAulbx5WHK1fc4KhJOFDleXilNpv4iYpIt29kEMVstxCaO771mDbSVDxjaE7tb1Vj5YpzN5NUALWsnBiSB3oQ+cxkXoVrh2SBDqD4bQo1tkvo2uYm53GyqcbJG77HMMOqqjwtV6/5e872fMUd3SQ0E7Nu3IVouBLzuyrhWcKj2/ZQnI/MgRk4Sg05u760vJ3+eCIpGXhkiMhYpzxRBJjopjxMHV8VGpi9xifPw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(346002)(396003)(376002)(39860400002)(366004)(136003)(26005)(53546011)(7696005)(86362001)(9686003)(41300700001)(54906003)(6916009)(55016003)(6506007)(71200400001)(316002)(966005)(478600001)(38100700002)(38070700005)(122000001)(82960400001)(186003)(5660300002)(91956017)(83380400001)(4326008)(64756008)(66446008)(66556008)(66946007)(33656002)(2906002)(66476007)(8676002)(8936002)(52536014)(76116006); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: qA18ESdW/kG3wMyh+ZqgBX7BJQ2W3ALU/fWHdvHYYoFRcx/NhgVGsmbeC6bSHwF8QUMgKi6yDwt73bG81LftsVY9EKkd6ihpdY5SfunEIXB/4Yv8jRjvTgnCLAZm3gpqvvajJo1stroPWqKyDdwO7PyBgLIkJZ+7t686vrll/em8sl0pCgAIA5NbHY2lySukwTyivzhu3mOLKFtr45IU3W9N3BnldNytCEnQ1ZT+f4q+F8tVIEuDmpcfWF201m8qgX5atZg76x8MZ34aYRNEuGY+0++ES0fnLbXwCqA0LfxkLDyu7vsy656XKaID6kgEOqW93ibmr7+gxgJvVS0QdajcNd6iNGF2rKjofLNkCRDhys6O0tcnyk2nsUjSYGBBfS4HA8EqcPsB4GhIaPRfmIfZOvIUEYevLKK7GOLWYQaTKzOzH1911dJ9UlbqK51tb5NJ5cNY4MXdyLV5EGJXc65ar36yJuG6O2PzLsWamrQHVOWdyAZjccrK51O2hZUa6IESWdJk0nmD23eABjM2S7sQctMenYoWaYfwMRcWJXji7EEy56vEDza6J+P18Tv2/njR+yvT66S/PVR20tBEYtv16r5USxLTnqVf9g9SfeHJilBWZEkCaDYRwc03FkxmodiArQPq7vB4wBCrbaoImn5OqD15gUD0evNQmvyfFuO0RlF8UutWmvHNqL79I4Qb1fXqf+4wjRW5xEUQLClxHGAVKwwuVnSMR8XVP4jmPB1sXrSl/j8xV2yw8yjbpwY6N8YPPvhA0LfG8YTGckvE4GfYaMMvWbro67jyTjkMP18S94l40dAdz/R1P4qBl0aCCzO6+7BVEPka1EKo0m5TaRZV7oVoAvaYjs4CADA/9Ft2U/3xXDJq2+yKeobG0OW4yUyRDCCqfsUP5M1FlUuaB3LS5Vqvn/0V/D3yTscUspytuwiV9FbOhcozha/ZIVSHo7ubt6lHsElh69jq4SLVeiJQ9UfE2+y89xTeM340PjQlljVpJSl+PXFsDusUyejv4r+w2fxIEZqrTqI7+AbEkUQ6U2w7meD2fnulzbXj9IkjYyszpmQAlkkrNt1sbVW9hAdNHci+2w0xncEDsZzIOhTvDszh0yg+ssIC1w/SLdKBIlPAeRILI49KKHFCEK0dxXFEwseafSfERvYQcSw4rnlVGZeOTVVMsGC4wi4d9SR1SQ12K1WuRCB6SnfSsYOdzsI6EwjbNDUV0tDaoPNmpB394X+9eMf0diO0xG9NaL6aoGKlqczg84oo1bSXIiYKiLOtSZsg7ZK0nkXwCN0HtIMBnfWbW3PUEZb/NCxdYOi9jCgQRLpzzmxBgSWo9/EMOGik+ujAmOExi+t1a+iK5jVeurgrjb9DqVt+O3+MVHLUQ8oVgmkNP3r3vnbOFYMphxr2nJAP/1pXZ8wL47y9yRKxuGGz4+Wa2yX63xx2Kwcj1NamsBMyWzq0PfKSr4tw3JmutsJKcpdEd1Yqgz88nZ/J9weaYS8Vh6D1OewdoFqU1Nj70cWoH7SlHzPfXbiPuAEZ5MpZvmJhnHsc0GNkmJj6b+GeNwUbkT/esgWbtxbxZyh4kEMp2isn1Y50+LWu
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 75d9e653-356c-48a8-babf-08da75292b01
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2022 08:21:30.1363 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: z44M07h4OVT99TCCKi33C7EdvytuMUG2f/hnS9q17AZmeG1sMi3j9i26OJsq0Nty12RiyKnip+AxdDalOVDaYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR07MB8472
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/1NvIa1mgzSLAXhohv-sfzHBFD0k>
Subject: Re: [mpls] [Technical Errata Reported] RFC8960 (7059)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 08:21:37 -0000
From: Jan Lindblad (jlindbla) <jlindbla@cisco.com> Sent: 03 August 2022 08:21 Tom, Excellent clarification, it describes the situation perfectly. Let me add that it's usually not important whether the path is relative or absolute. You can get the same semantics using an absolute path as with the relative variant, but in that case you need to add "XPath predicates", i.e. filters, to distinguish which instance(s) that are targeted. Something like this: uses nhlfe-single-contents { when "/rt:routing/rt:ribs/rt:rib[rt:name=current()/../../../../../rt:name]/rt:routes/rt:route[rt:name=current()/../../../rt:name]/mpls:mpls-enabled = 'true'"; } Except that in this case, the approach above won't work. The rt:route list is keyless, so there is no rt:name key to match on. So in this particular case, only the relative variant can give the semantics of enabling the augmentation on individual MPLS-enabled routes. <tp> Jan, yes, and then there is the solution we discussed at the start of the year which was not 100% accurate but was much terser, looking for the object anywhere in the branch of the tree, not necessarily at the required level of the tree. Meanwhile, did you see my post to Netmod which suggests that the proposed change is illegal in that it does not conform to the permitted updates in RFC7950 for a YANG module? ie the solution is a a new RFC, new module, new name, new prefix and so on. Tom Petch Best Regards, /jan On 2 Aug 2022, at 18:32, tom petch <ietfc@btconnect.com<mailto:ietfc@btconnect.com>> wrote: Trimming the list a little and adding more to explain what is going on under <tp2> ________________________________________ From: tom petch <ietfc@btconnect.com<mailto:ietfc@btconnect.com>> Sent: 29 July 2022 12:32 From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>> Sent: 29 July 2022 12:22 The following errata report has been submitted for RFC8960, "A YANG Data Model for MPLS Base". ------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7059 -------------------------------------- Type: Technical Reported by: Jan Lindblad <jlindbla@cisco.com<mailto:jlindbla@cisco.com>> <tp> I think that Jan is right in the sense that - the author did not understand the YANG that they specified (or at least the XML part) - it renders the when clause more or less meaningless It is also very widespread across WG and I-D/RFC which makes fixing it a challenge (a bit like having or not having zone in an ip-address type). <tp2> The YANG DDL allows conditional statements, that parts of the syntax tree can be made dependent on other parts of the tree, on the presence of an object, the value of an object and so on. This is widely used in conjunction with the YANG 'augment' so that if e.g. MPLS is enabled on a route, then additional parameters can be configured which relate to MPLS; and if not, then not. The conditional is commonly expressed in XPath. The syntax tree is a tree(!) and the XPath can point to anywhere in the tree. If it points to the root of the tree, then the whole tree is in scope and if the condition is satisfied anywhere in the tree, then the 'when' is true and the augment happens. Thus is a box has one interface with MPLS on it and 1000 not, then that one interface will satisfy the 'when' and all 1001 will be augmented. This may be what is wanted but the suspicion is that it is not. If, on the other hand, the XPath points to a branch of the tree, then the 'when' is satisfied only for that branch so the one MPLS route will be augmented and the other 1000 not. Trouble is, pointing to a branch in the tree can be cumbersome. Thus a CCAMP module has augments of the form when "../../../../../../../../nw:network-types/tet:te-topology/" + "otnt:otn-topology" { and there can be over one hundred in the module such so the use of the absolute form, pointing at the root, is tempting but then the result is different - 1001 augments instead of one. Jan's erratum give the two formats for RFC8960. HTH Tom Petch </tp2> It is also a technical change to what the WG endorsed at the time. Challenging. Tom Petch Section: 2.5 Original Text ------------- augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { description "Augments the 'simple-next-hop' case in IP unicast routes."; uses nhlfe-single-contents { when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" + "/mpls:mpls-enabled = 'true'"; } } Corrected Text -------------- augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { description "Augments the 'simple-next-hop' case in IP unicast routes."; uses nhlfe-single-contents { when "../../../mpls:mpls-enabled = 'true'"; } } Notes ----- The original YANG statements make the "uses" statement apply to all rt:rib and all rt:route instances as soon as there is at least one instance that has mpls:mpls-enabled set to true. I suspect this is not the author's intent. The corrected YANG statements make the "uses" statement only apply to the specific route instances that have mpls:mpls-enabled set to true. There are also other ways to fix this issue. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8960 (draft-ietf-mpls-base-yang-17) -------------------------------------- Title : A YANG Data Model for MPLS Base Publication Date : December 2020 Author(s) : T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG
- [mpls] [Technical Errata Reported] RFC8960 (7059) RFC Errata System
- Re: [mpls] [Technical Errata Reported] RFC8960 (7… tom petch
- Re: [mpls] [Technical Errata Reported] RFC8960 (7… tom petch
- Re: [mpls] [Technical Errata Reported] RFC8960 (7… Jan Lindblad (jlindbla)
- Re: [mpls] [Technical Errata Reported] RFC8960 (7… tom petch