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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 11 August 2020 00:24 UTC

Return-Path: <acee@cisco.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 6910D3A0E55; Mon, 10 Aug 2020 17:24:27 -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=bFhKOpEe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VOfG7OuT
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 m2suSm9FCFqX; Mon, 10 Aug 2020 17:24:24 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F170D3A0E54; Mon, 10 Aug 2020 17:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16952; q=dns/txt; s=iport; t=1597105464; x=1598315064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4vhSNToSARGCLf/WMSxTcS71aCHg3yfd5Sa9crbdnMQ=; b=bFhKOpEeWv71cY1RJ+4kEscHpYhHAkasV1DBGY4wk1TM4Bm6QlREhnHs ZDt+Z4pzB2mEzuLavXjYFF1uIzMipp5HNYT5tY/qNzhUy5r9fi7SjqoT6 ZLgabHGEmieQa+pzQkgihj4xX/JY3D6W26B1kmmWFnRtkLjVHyFZFsvyz Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3ABbd5vhewQJtrpN7nUtOx7jUplGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQDdfZ9vRFk+fM9abtRT9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Qv3uz9TMIXB?= =?us-ascii?q?PyKVk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgA45DFf/4kNJK1XCR0BAQEBCQE?= =?us-ascii?q?SAQUFAUCBOQUBCwGBUSMGKAdvWC8sCoQsg0YDjVKYZoFCgREDVQsBAQEMAQE?= =?us-ascii?q?YBg8CBAEBhAhEAheCHwIkNwYOAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAQI?= =?us-ascii?q?BAQEQEREMAQEsCwELBAIBCA4DBAEBAwImAgICJQsVCAgCBAENBRsHgwQBgks?= =?us-ascii?q?DDiABDqdYAoE5iGF2gTKDAQEBBYE3AoNYGIIOAwaBDioBgm+DX4ZAGoIAgRE?= =?us-ascii?q?nHIJNPoEEgVgBAQOBJwEIBAYBBxqDFzOCLY9kJ4J0hweCeYgKkSEKgmKIY4t?= =?us-ascii?q?QhWYDHoJ9NokiiCeLFpIugWyIUZBNhCoCBAIEBQIOAQEFgWkkZ3BwFRohKgG?= =?us-ascii?q?CPlAXAg2OHwwMC4ECAQqCQYUUhQkBNwF0AjUCBgEHAQEDCXyNXIE0AYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.75,458,1589241600"; d="scan'208";a="524811305"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2020 00:24:21 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07B0OLE0024035 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2020 00:24:21 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; Mon, 10 Aug 2020 19:24:21 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 10 Aug 2020 20:24:20 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 10 Aug 2020 20:24:20 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eZd9nkP2oEC+BiryFVbQUpDIdswfZOPhf9saXzTp2aMBz/M0dzGAZaYtb/siHN3IuIe4c3tNUNxlBv6oIFQ+JMfRlWnlj+ymQGexg2YwcY2R3u6rfHVQp9SPQc8bacBQIHotuTl5gVJJXPLl0+sTgSHWM9J3g9jeo+SIHMht4MM4hG2GYz3FN23CHrfKHms032V8aj+Zu5Yb9DUyw359IVKYwyhX03R5FDvOUHUSuZv9J4yZk5ok7lbnULoGfaO7pLTgJS4YweBOYKAjLux6p8mNpu0tWN4wxjYp715gvyZEIZPnB0eKnW4RDwSFZuItzkO31PEvNIaAPcx0ZTkEcQ==
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=4vhSNToSARGCLf/WMSxTcS71aCHg3yfd5Sa9crbdnMQ=; b=ISklDAuFHho48YmzctDCvnmfnm/9N+HCr+7kBU/ow36OzZmMuhYuEq73hRdGamsH+Kj+Q5kqp5SEiY2FCn+bD3ZrKDdN3dYGIZlBmvh/kb+RsjIUrV8TANGsDC+51CWTpk5vVaILFkjdPlIX9c7PROu9TG3h4dPOKYmz226LzEqJKlb9eHjkTrayit73h4IvQ0hcrChy2hfDvfuTB/d/8K87jQGYCKF+I4SiC+MHOV+hlXxDqhCwNVphfDTGn29km5lDXi7ImAzpkTTtRx0pRWr9VjnEHycH5ZsGIOCtYwKOKGCPo2Io7T9EIyjUbjttb3oIqn0IoHAIIn9MOE37rg==
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=4vhSNToSARGCLf/WMSxTcS71aCHg3yfd5Sa9crbdnMQ=; b=VOfG7OuT6QI7EC0KUG0Sn3B/TLUP0v3m8Z/wiHDOVb+TXif7nkefjF1bP4ri18JQALHDEv42qjzQ1MdSMLa6ArnFHWty0tOdJwzM9mHmaGu9ApAaxEQWGhzm0noKX9Jn76431rjMqo5W50Lm6j5KOfHQRhaCwdHVEHdEbBGNgKQ=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB4483.namprd11.prod.outlook.com (2603:10b6:a03:1bc::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.19; Tue, 11 Aug 2020 00:24:19 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::70a6:bb5b:16b:4f9b]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::70a6:bb5b:16b:4f9b%7]) with mapi id 15.20.3261.024; Tue, 11 Aug 2020 00:24:19 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Tarek Saad <tsaad@juniper.net>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, tom petch <ietfc@btconnect.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: AQHWbNHhjFoS+TZQTU6nPSaQ4ny3G6kxjfoAgAAg14D//8zeAIAAUvsA///BSoCAAHIJAP//zNCA
Date: Tue, 11 Aug 2020 00:24:19 +0000
Message-ID: <36AE6887-6F0A-4FB3-9CEB-15F07147474C@cisco.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> <E384A4B4-2823-445D-A89A-94409A1D3F5E@cisco.com> <24B5482E-16AC-44B4-8028-079BFBE331C0@juniper.net>
In-Reply-To: <24B5482E-16AC-44B4-8028-079BFBE331C0@juniper.net>
Accept-Language: en-US
Content-Language: en-US
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;
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; 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: b4e40ca3-3d24-4ef6-e4af-08d83d8ce390
x-ms-traffictypediagnostic: BY5PR11MB4483:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BY5PR11MB44831B82C9ED6065A2750CC6C2450@BY5PR11MB4483.namprd11.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: KSJgp7bjiF0AWDz23Z3mx/4If9VQo4Wb36tr8sk1+ZvVjImXu6k3buA+FzLQ59u44/gUGV2tIRrqvr+8pCkYSzsybl4pLr305VN5sMjLPVMxXEjr7l2Kn2qCmRqf4ysb7a4OmLemO7W5v7kxB0perNICCs0irkESbYgqWXwuiVKBDTNFzGx+cn5num0SyZXx0n7gSB3PFg5h8bxIE+BWXrMr0GLP2YAHfD6m4VqFyePhhTlJZDiDdhBxWERqyFgIJzcZGeTA3aolt88E0GN6KTKTne00atl5WUTa12SJaUX8c5J+ae4NOBfdPrGOEUSJ0XNChAm/NRzW3KA0vyCk1YwKVUelg3VyWHSQeNPSoX6RM80ozleLR2JKNoLaKTgULkTcDGZEoikX1SFn1gLCAA==
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)(39860400002)(366004)(136003)(376002)(346002)(396003)(66556008)(66476007)(64756008)(66446008)(66946007)(33656002)(2616005)(6512007)(8936002)(110136005)(71200400001)(4326008)(478600001)(76116006)(5660300002)(26005)(36756003)(86362001)(316002)(83380400001)(2906002)(53546011)(8676002)(6506007)(6486002)(186003)(966005)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: UaxQJzy2BS6Ta00q8iqa9aHmycMMlK5sc50A20kr+opZ6IaxIVL5vZSI0HoBigEENFhQRBKonv1jXu+B3ahgKvQUpxtLUUVKZD10ykEbL1bJletgFYbBgBMMjoTN6lsQZiGjehINHiF2+5+rPQu1fQeX+/PvV5lyPgINn0rYa9+tS+Qnju7u4cFkdegKRcigz0t0irxpFzAy9TgiMvAFmWASrMSr08xht4pnq+N5JAqX1fnctC/52qStvVhlMdn2yuw1ranIlnjo5jYsLJVoobDyXlObEQPsBhrts0u49w/FIo90MsmHhdzomlZW2ZawvlFLyKwt3d2JFe4gUAVMzhCdUzdXPzPXX5qWRkH4MQjyuBj97ZtR+Nf34+QK0BIFPQMN2pZ82JK9kK+dO0tsuLIE4W6pblHbg0K7MZoXMnlseHJSv/oe6MbFnQD2iU4/LZHlPpsnw+tef4sgldXakOPqTyTIyAw9ffASHtMUvhln8Ma3PH3L9QeQ+xm2ll34GMW6hKyEj50a07+WyMVzU0mvldYjKcq10qM/35qAi4PY1+pllX0AJ0HXy0si5MLn2La7dOA1R/d/vFVEJYheIVLNr4zomUBbqiKgoAouvOhzUG04HkwrknsAQw8FNXDDXreYPYocl7wrkhcCIYwV4g==
Content-Type: text/plain; charset="utf-8"
Content-ID: <27F2E86A28F3394BA6BB1ADD1F563356@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4e40ca3-3d24-4ef6-e4af-08d83d8ce390
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 00:24:19.3975 (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: F3E4hpU+ukpQLS/dlR6XhhBCNqpI7E4z5kvPMdG9ghgu+3YJiBSVH7JVSBaLndCJ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4483
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/IxwxyvU883bwunpQiYsExIO-T1o>
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 00:24:28 -0000

Hi Tarek, 

On 8/10/20, 7:27 PM, "Tarek Saad" <tsaad@juniper.net> wrote:

    Hi Acee,

    Are you checking https://tools.ietf.org/html/draft-ietf-mpls-base-yang-14?
    If so, Figure 2 shows the module is augmenting IPv4/IPv6 AFI with MPLS for paths - check the paths
    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop:

    You'll notice the MPLS augmentation above is applicable for all RIB types (including IPv4/IPv6 and the new AFI introduced by this module). The MPLS augmentation for IPv4/IPv6 RIBs are specific to IP prefixes that are MPLS enabled.

That is how I originally interpreted this augmentation. Precisely, what constitutes a route with MPLS enabled? Is it any route for the which the MPLS augmentations are applicable or only routes on which they are present?  

    You'll also notice draft-ietf-mpls-base-yang is defining a new RIB address-family for MPLS as per section 3 in RFC8349 (search for "identity mpls" in YANG module).
    The new MPLS RIB address-family is meant for "non IP" MPLS routes (e.g. MPLS routes installed by RSVP on transit nodes, cross-connects, etc.).

Then what is missing is an augmentation for the destination-prefix that is specific to the MPLS AFI. You should not be overloading the local-label which applicable to all AFIs is also the destination-prefix for the MPLS AFI. 

     
     augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
       when "derived-from-or-self(../../rt:address-family, "
          + "'mpls:mpls')" {
         description
           "This augment is valid only for native MPLS routes.";
       }
       description
         "This leaf augments an native MPLS route.";
       leaf destination-prefix {
         type rt-types:mpls-label;
         description
           "MPLS destination prefix.";
       }
     }

    Given the above, can you take another look and let us know?

I think you must follow the AFI specific augmentations set forth in RFC 8349. It is not for the augmenting models to break these conventions

One more nit, why is label-block_state not label-block-state? 

Thanks,
Acee





    Regards,
    Tarek


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

        [External Email. Be cautious of content]


        Hi Tarek,

        In that case, there is more wrong than just the RPC since you haven't augmented ietf-routing.yang properly to define an MPLS-specific RIB. Furthermore, I don't think you should. We need the optional MPLS augmentations for the IPv4 and IPv6 address families as these are what one would need in for a IPv4 or IPv6 RIB for a device that supports MPLS.

        Your augmentation to the active-route RPC needs to just be removed.

        Acee

        On 8/10/20, 4:24 PM, "Tarek Saad" <tsaad@juniper.net> wrote:

            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".


                    >            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


        Juniper Business Use Only


    Juniper Business Use Only