Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

tom petch <ietfc@btconnect.com> Tue, 11 August 2020 08:58 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBA03A0EAD; Tue, 11 Aug 2020 01:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUDdCqFAAxyz; Tue, 11 Aug 2020 01:58:49 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80091.outbound.protection.outlook.com [40.107.8.91]) (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 1B4CE3A0EA0; Tue, 11 Aug 2020 01:58:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XrlS6gH3HmxORYXdSJRRfhc9bICuGm1tbSqrGrrrwqWDG8LqqHFOqWpkIWsjDazsdcSFTvzQdabV/CGffAOiNp4P/LgkjIi/8TAAlq0VBtxDkDEFYUzyCHyLAATQdpO7Jp+l4taHdxOXnarR8JiXl+irgelKT/W62L0HTfFKM8mllblzH3gw0iIrMkQKmhWnVpIvGUAQPN6MVj6xPwHatiew3+SQTwXy5c8u6R9TUXljQ3l0+73I6IRqCbtbd4rhAyAHv5QzLfXBUvgFfcqgj758W5m/dantg3Bkwvbn1XPRviWQzZuzg9w4esA5D1CrWpe7xchZfgpGtnHNtAM6TA==
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=FOOD/pqkXj4dRworNcqyrCqPZufimjn2Ox4Bdvsf8Io=; b=Wa3pWRYWx+24xne9yr6HQ28kXEUqDYuvdO64N3BpS5vlPz2yLEdic4qNnV5KxGm7+YBlofDHxhSid4WyhM6liu5JW+jyKpMvbCmxZ3TShV+qGPUfyYCfx8FaUFFAsMOYyZn511srbVdK6nUF02S++znX1pVVKoguzC67XImPI8vm4MtT8coBWzPVA15wpolWIsiqOnPLjPL5L1Zb0PmGxaPI0lzrnkgUkuTUmVaae5A0vYWlYHL7BP+VlCJoL6yZiIN9g3LewdgT3EwskvxX9MOaXAC+yOertsnFOAQa0pqU8J17VXR91Teh7KZr8frWfDv8EJd46Gw7seByigEI8A==
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=FOOD/pqkXj4dRworNcqyrCqPZufimjn2Ox4Bdvsf8Io=; b=PDUFme46By/D/tX+W+K62BuafwVhWFHRAj5G554DsRDD7tCy8k9WSwb3SyD+YHoLR6w+kMpXldqK2kyUCcoZcMrhuDWahEQtBJ/8LUtMBriH/i5o2wgafd1MJhyN/zeV4ehgevxnC8zFLh+SmLo3Uc1/y6fBoQSyF5GePSSu1iI=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6946.eurprd07.prod.outlook.com (2603:10a6:20b:1b8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.6; Tue, 11 Aug 2020 08:58:45 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::b570:437a:db46:400a]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::b570:437a:db46:400a%9]) with mapi id 15.20.3283.014; Tue, 11 Aug 2020 08:58:45 +0000
From: tom petch <ietfc@btconnect.com>
To: Tarek Saad <tsaad@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "lhotka@nic.cz" <lhotka@nic.cz>, "yingzhen.qu@huawei.com" <yingzhen.qu@huawei.com>, "warren@kumari.net" <warren@kumari.net>
CC: "netmod@ietf.org" <netmod@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC8349 (6251)
Thread-Index: AQHWbzHSqdMkE6HM9EyxkyvyiFxhiKkxhqvjgAAjZ4CAAA/wAIAAD+gAgADRdRI=
Date: Tue, 11 Aug 2020 08:58:45 +0000
Message-ID: <AM7PR07MB6248984045BBA46199BE751CA0450@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <20200807154534.98486F4074B@rfc-editor.org> <AM7PR07MB62480F112A28FA0B0F068D91A0440@AM7PR07MB6248.eurprd07.prod.outlook.com> <MN2PR11MB43664780B4844ABA07C84D0AB5440@MN2PR11MB4366.namprd11.prod.outlook.com> <3073B02B-7413-4C00-ACF1-CA2679C0C949@cisco.com>, <57AAC8FB-65D7-40D9-BFE7-B16A7F680C0E@juniper.net>
In-Reply-To: <57AAC8FB-65D7-40D9-BFE7-B16A7F680C0E@juniper.net>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=42648655-a83a-47dd-85df-00007a4a57df; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-10T20:01:11Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [81.131.229.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0db55d5e-b4d5-4922-be76-08d83dd4c150
x-ms-traffictypediagnostic: AM7PR07MB6946:
x-microsoft-antispam-prvs: <AM7PR07MB694678ADEAA4AE8484CBF149A0450@AM7PR07MB6946.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: d/Fw5tRhbUu0UWttsVahrrpHIxAeQG1/YQ7RqMaXO7XWzHz8G5TG5Kh9KljanBixJxrn+4QF7llQ0isddgRn7U2pcUSg3usK9Q/JAAtXz/xl9hDys3KHqH6IHwgV3H2ecIeoz5F09aMldwqPSJsZy7HCVDtq6JCSdKXlpmZmW3dIOl2qsp0ZN7HFv/Wq4rbZmlEgmjCCXhBHhqb1B2mt5lam1zQVJSze3ndRh0xYo2giehaOl2VKrqthXX00wmDoi3Z33Aa2uGH5zEKYptvFgJG2RRlgbMrIoVRcCI9olpeo7KuRDCxewhRcSkYhQjjWymda0caAA9LPRFaDID0bhTq2Mjx2qimkRNl7lYFS+eSYZOBdrrTIVGEwFNwfUdQLdpeF83R6p5RpvLPokXyvcA==
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:(346002)(376002)(39860400002)(396003)(366004)(136003)(316002)(91956017)(52536014)(66946007)(478600001)(76116006)(5660300002)(71200400001)(33656002)(966005)(83380400001)(86362001)(8676002)(2906002)(6506007)(53546011)(66446008)(64756008)(66556008)(66476007)(7696005)(26005)(186003)(54906003)(8936002)(4326008)(110136005)(55016002)(9686003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 7Qb0mL9sI2fMxGul6q4JPUqBRR2N7oqfLHwbHrF62v4UE9Sc5BY+rDZMheSyuuXhqkjRp5kX5yGZ/4M15OGJH7nS5hvcvj1+j11xMOJ9F0ckemZ+OD4Rc1XxXR9TulKp6frlMbPT9efayOdJuMD6gUiI/rBc2vQ+ezN7zjPwM1h4pF6wAya51X830LsSecK3LAA42DKU6E3B0TCSfelAk6Z+r3hsqRcGgmzfn0R6Dh9ukjcAOt0XTHuIdH+wA8yhpB8n1T8p16drOEclmFVW3ng0ym5j97Pnh6bF9asaZChAvTKwu0sKSq/qe6qxZ+KwCI6Hdd+8HyKSOKzvJ1S5k1CXmBu0+GFUP07WIOwrh3xowmcdyDD15cq0xdhvH1d40AKPR/urwsDcNnuF+56Gj6ksdbPRhB2x/ldVb6BNKidJgppshP02yufXZTlul+tyPpEq3aS3vnVtGMWiohSh7yMy0BjwGgAkN44oODs/HdJRLIQS+lYTzbJHIJMs6DrBKkVafEHfO0bPwYXE4sKhdWhDEzZfYzpZXwnH6P7blScgDLInMTyzVhZG93gIsq6dV4/HclEJt6PbVoTaX7mq/mxcTyB3pobzVHAJu4bX5f/8hTmRwnZhrogW3K82OlBYT880hxEaPgg7b1hEnuVRsw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 0db55d5e-b4d5-4922-be76-08d83dd4c150
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 08:58:45.6808 (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: 2qAIyTs+J9o3LWekJWRyoyWlnf/59LjRUi0TIoPd6Cph0i52lmjJvyRi9myl0YgIluAeeYsn0FXCup5yUAnUkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6946
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dpqPRGSUDX0WQJMYeIwmGgu81eE>
Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 08:58:52 -0000

Tarek

Picking up on an earlier point,

________________________________________
From: Tarek Saad <tsaad@juniper.net>
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it (/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name that identifies an entry in RIB to "destination-address" only - in MPLS RIB the entry leaf name that identifies an entry is "local-label".

<tp>
There should be a 'when' check to enforce the 'MUST' but the rules of YANG do not allow it in this structure.  I raised this on the NETMOD list at the time of WGLC and Martin pointed me to a rule in the ABNF which prohibits such a check.  He also said that the rule was not needed and would be a candidate to remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a constraint that must be enforced in the YANG

Tom Petch
        >            action active-route {
        >              description
        >                "Return the active RIB route that is used for the
        >                 destination address.
        >
        >                 Address-family-specific modules MUST augment input
        >                 parameters with a leaf named 'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

    [External Email. Be cautious of content]


    All (Speaking as an author of RFC 8349),
    I just looked at this in more detail and I don't think the ietf-mpls.yang model should be augmenting the /rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to return the address-family specific active-route corresponding to the destination-address. This model attempts to overload this RPC with a different action all together - returning a route that has the local-label as an optional attribute. I'd reject the Errata and believe the augmentation should be removed from ietf-mpl.yang. Whether it is replaced with a different one is up to the co-authors of ietf-mpls.yang.
    Thanks,
    Acee

    On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:

        [Resend to hopefully pass recipient limit filter]

        Hi Tom,

        I would be interested to hear from the original authors.

        My impression is that this is a technically reasonable change, but I don't think that an erratum can create a new revision of a YANG module.

        If this erratum was processed as "Hold for document update" then would that be sufficient to do the right thing in the MPLS YANG module?

        Regards,
        Rob


        > -----Original Message-----
        > From: tom petch <ietfc@btconnect.com>
        > Sent: 10 August 2020 17:32
        > To: RFC Errata System <rfc-editor@rfc-editor.org>rg>; lhotka@nic.cz; Acee
        > Lindem (acee) <acee@cisco.com>om>; yingzhen.qu@huawei.com; warren@kumari.net;
        > Rob Wilton (rwilton) <rwilton@cisco.com>om>; joelja@bogus.com;
        > kent+ietf@watsen.net; lberger@labn.net
        > Cc: tsaad@juniper.net; netmod@ietf.org
        > Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
        >
        > From: netmod <netmod-bounces@ietf.org> on behalf of RFC Errata System
        > <rfc-editor@rfc-editor.org>
        > Sent: 07 August 2020 16:45
        >
        > <tp>
        > This is the erratum of whose arrival I speculated on this list on June
        > 16th.
        >
        > There is a degree of urgency about it.  The I-D in question is mpls-base-
        > yang, currently in IETF Last Call, which is a Normative dependency of bfd-
        > yang which is a Normative dependency for a small mountain of I-D which
        > have been waiting a year or so (e.g.  ospf-yang).
        >
        > I suspect that the technically perfect solution would involve a YANG
        > union, choice or some such structure but as I said in my Last Call comment
        > I can live with a label that contains such as 'address' encompassing such
        > as 'label' in the context of forwarding.  I take labels to mean what
        > labels mean rather than what I might find in a work of reference.
        >
        > Tom Petch
        >
        > The following errata report has been submitted for RFC8349,
        > "A YANG Data Model for Routing Management (NMDA Version)".
        >
        > --------------------------------------
        > You may review the report below and at:
        > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6251__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A$
        >
        > --------------------------------------
        > Type: Technical
        > Reported by: Tarek Saad <tsaad@juniper.net>
        >
        > Section: 7
        >
        > Original Text
        > -------------
        > The RPC "active-route" is used to retrieve the active route in a RIB.
        > RFC8349 defined two AFIs (v4/v6).
        >
        > draft-ietf-mpls-base-yang is defining a new RIB AFI for MPLS as per
        > section 3 in RFC8349.
        >
        > The RPC has a "MUST" statement that all RIBs must augment input
        > parameters with a leaf named 'destination-address'.
        >
        > For MPLS RIB, it makes sense to augment with leaf named 'local-label'
        > since MPLS routes are identified by MPLS label.
        >
        > We ask to make the following change:
        >
        > OLD:
        >            action active-route {
        >              description
        >                "Return the active RIB route that is used for the
        >                 destination address.
        >
        >                 Address-family-specific modules MUST augment input
        >                 parameters with a leaf named 'destination-address'.";
        >
        >
        > Corrected Text
        > --------------
        > NEW:
        >            action active-route {
        >              description
        >                "Return the active RIB route that is used for the
        >                 destination address.
        >
        >                 Address-family-specific modules MUST augment input
        >                 parameters with a suitable leaf that identifies the
        > route.";
        >
        >
        > Notes
        > -----
        >
        >
        > 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.
        >
        > --------------------------------------
        > RFC8349 (draft-ietf-netmod-rfc8022bis-11)
        > --------------------------------------
        > Title               : A YANG Data Model for Routing Management (NMDA
        > Version)
        > Publication Date    : March 2018
        > Author(s)           : L. Lhotka, A. Lindem, Y. Qu
        > Category            : PROPOSED STANDARD
        > Source              : Network Modeling
        > Area                : Operations and Management
        > Stream              : IETF
        > Verifying Party     : IESG
        >
        > _______________________________________________
        > netmod mailing list
        > netmod@ietf.org
        > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$



Juniper Business Use Only