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