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

Tarek Saad <tsaad@juniper.net> Fri, 14 August 2020 16:25 UTC

Return-Path: <tsaad@juniper.net>
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 D6D643A0F1B; Fri, 14 Aug 2020 09:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=CIlvut/o; dkim=pass (1024-bit key) header.d=juniper.net header.b=CS0vsJz4
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 3bRCsOFRl4EZ; Fri, 14 Aug 2020 09:24:59 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 116CA3A0F2C; Fri, 14 Aug 2020 09:24:58 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07EGND9M031573; Fri, 14 Aug 2020 09:24:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=fekbp0DUMeH5JaoE8L4lHd5xitnlkFUP7rOxY62/Uek=; b=CIlvut/oYb72/pvFXcwtt60rZe4s56UHGoiQBY078d7xUyRcqgjjDt7+JSephd+4GVEg qaqsRIeS5FnGigyi5CjGjvw4FU6ZBwizQlGB8H/P9nbKf//67WeRdVkc9pnLf9CUctHw PUb5aNK2YB849uWemW4cLYBVrrXHqzZ6oa1YAwaZpt0ZjtfUuTF3qfe9iHyuFsZ3mXVT vZ4NPoHTWkAerhcZYFVeVx3vFjNd4OSq566LROJ2tW+0oqHgam0vM0LoD/yYUemrWQMo +SBbTXKmLBzpbULvgj0gnHhcim+9tsFOfS8+KOwFVK65/4sDCjNSJhY2vS6kxhCR5Rw7 /w==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2104.outbound.protection.outlook.com [104.47.55.104]) by mx0b-00273201.pphosted.com with ESMTP id 32vrr13aq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 09:24:41 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vb3ijSO3hKo7Mrj+B1568J1HkwpkxmbAn9d/aytDqmZrOt1rD3xpT1WnRqInL0QMoj9TDuvS0cE0Iiz/doMbt264tIBmG3KOcU4uCuWy5hWMFNfMz+ybYNstSC1MKIB8LMSkDGa8kijZj41vVkyE0rvlXOckTtPVhVR+Y1uoPFrqL8u2HobB+7ulEWhGZ55CFRTP6kNFq3p2Q1jRXLza3r8Ud59JMmsZTIRZ+pkU/Dnaa6WyAFa1CB+aeDxvxDrIozSK2Mhjt9X9+s11kZpHApMcyesc3xTU1ki2wg+3jjH8Yar7w7nq73NZexVkpbfYPiO2k4UJfm6rXX37eF1mlQ==
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=fekbp0DUMeH5JaoE8L4lHd5xitnlkFUP7rOxY62/Uek=; b=Tnupo7RRr51ju62yoAeHUv3PYyh5dUU2wC52B9AkoM6MEsax7qS505spqIugpxkDTjaLJ+4JkhCkUOP49EmAgtGZgNOl358fpkVMuJlN9ZWVg7O6tfzhIMfNGS08G/QA9ymjjljDkMwEYvQMqZFS2mRAADN16bfHlreZSNOnTBzhfmgLsaDWdjLUR3l1+Q4cx3lrhhtr3BfJhjKTM/NIxZ54dJSfP0wszYZ/1Fe4sY7bT1JHtdGWoJhyisDvXOUhorq/uBzPtqhxiqIcqo1Z46ekm41kXXv7x2X84fiOnSWHPSb6c4VnzIjdgKblQEd8M1QT/tN76hDyCJH/Ko8T2Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fekbp0DUMeH5JaoE8L4lHd5xitnlkFUP7rOxY62/Uek=; b=CS0vsJz4vYbo1mFtGud+1u2p2ErsfPqegOGVpnKKQRoOI5LyIb0VT8j+/BACkA1sdI75IiEQWbxYwgTza63Z+mgp8poGlOgTiwVUSYswO706JVboakl34h3T9oLdo3rLoG2BcB2Zz7aM0rnuVejOzjj5cgdIUqZPcY6M5wEC6cA=
Received: from BYAPR05MB4136.namprd05.prod.outlook.com (2603:10b6:a02:85::18) by BYAPR05MB6118.namprd05.prod.outlook.com (2603:10b6:a03:ae::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.5; Fri, 14 Aug 2020 16:24:37 +0000
Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::380d:349c:196f:a61d]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::380d:349c:196f:a61d%4]) with mapi id 15.20.3283.014; Fri, 14 Aug 2020 16:24:35 +0000
From: Tarek Saad <tsaad@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, tom petch <ietfc@btconnect.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>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC8349 (6251)
Thread-Index: AQHWbNHUXD7iYiyo6Ey57883AGo+lqkxjfoAgAAg2ICAAA/wAP//zNmAgAEV/oCAAA2mAIAABjeAgAAx9ACABKquAA==
Date: Fri, 14 Aug 2020 16:24:34 +0000
Message-ID: <37DAF157-AC7E-4110-BA8A-EF048821A083@juniper.net>
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> <AM7PR07MB6248984045BBA46199BE751CA0450@AM7PR07MB6248.eurprd07.prod.outlook.com> <24CD45FE-939A-4B51-9149-BE8487D5E026@cisco.com> <AM7PR07MB624856FF14ED726D2B86E8DEA0450@AM7PR07MB6248.eurprd07.prod.outlook.com> <BAA01EBB-9CB9-4C62-9C96-B42AB6ABB2D9@cisco.com>
In-Reply-To: <BAA01EBB-9CB9-4C62-9C96-B42AB6ABB2D9@cisco.com>
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: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 66b046cc-d87d-4d55-823c-08d8406e885c
x-ms-traffictypediagnostic: BYAPR05MB6118:
x-microsoft-antispam-prvs: <BYAPR05MB61184FE86DEE45D5BC5E8C51B7400@BYAPR05MB6118.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CYPN+Y8Z2LkJrsVag/t0Fr0eT9/UrOwZqAIMIcLlmKnQBO8FSG+DYxpduS3ZO3rI0QlL26TvEXqpFgNXPn7qqDSsY760bSsWmorTMuL++LVYJOkYZ00bn/QTWGmZsNFnSJQRJ2/vpKCItfgWbW1mP+DDOrrXvvLUPmVpKBzyZKmZ8Qqf9l0I49ZIwKkQPUTOOwPRsZgDe9ccMQroMYg43QozYUat1bc0YtnsoIyGIRtcIOqP6Uhyl2YQZ4DVqLsD9hNgDmi8uFD815dRpZIUkNdVtZxES6E0OCq8FN3ssu6SonGcp6qqFTJOMnw5tQV15idmCFeSALK1lS9Qtadha4CeJdH2g0wfyldPZm0HCmoVwjy+92h9KUthxJ9Iqj6AJ/lLDWKA16vOaR50J7P0Ew==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(8676002)(66476007)(66446008)(86362001)(966005)(76116006)(66946007)(64756008)(36756003)(71200400001)(6486002)(7416002)(66556008)(33656002)(6512007)(110136005)(316002)(478600001)(5660300002)(2906002)(83380400001)(186003)(2616005)(26005)(4326008)(53546011)(8936002)(6506007)(54906003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: toqnNCSjstWL3MqeybSYIztcerLkvc8Qc0hMmaysOkmGNM/vNdYG98t4pUbDTicNaHmnQm3FLJhNW64MSS24eD7t5aUqyUSq8tcAuI7a9o/bnaXBovYL5YQKu4w+gKwfiNRA4VXHtkiC0BMrax3nAaBN+YYE0tvzSfWcGLsvk8KZCEMOgCNjiZY+mlA1YYmBE3jFUBDVk7aOFYURAT1H+FzBX7z2fVSU/v17WlFpTYASpjGJ0d+jqlw4z4yRNZ6W4zmxb4qmoYnLR3nDW0X4sL440gLcS/8KnD8c1rnPBdmIkF34cEyIn8szX8G4X9Ga4aT7FkJMYiPTgE5V5uhOmseiXQt/RM+XAIRJtYX4P6ioMIJ0X4B1kq1Vjdr3JLawv3aw26DS9WyVTL5ZEQiGt6B98SXv2fos32QhbmY99Xrrg3JIpqNldmnOPT+UDFCNu6DgB2msu5FP2iGooNn3V4aSBLVotgck1yVs+ACcKqAt6uXNm9NPTsZZgP8vrZkllA8oFTb4t5bqtAgM1bmyQvhW9eptMZVf9Rdm7j6ZDlAW69MbI4B8Gpz8tut0E8jSwHrcrn3ySeLZqYHND68Ldc68DZDJYOtEn5H3tXhBeufv5JmpgywmWHZSSsuCS6YJd7FwrqE05kgS8w8vG+xmwg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <B675D4A9E1165149B149B8973E53C5CF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 66b046cc-d87d-4d55-823c-08d8406e885c
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 16:24:34.9370 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yQNypv/Y10O3uQyOY1rdunCYQlCdG7x/TP6r1LP4e9PoBehTxIJvotaIElDxfUkdnzH5Q7HL8kr2Vv04JMySmQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6118
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-14_10:2020-08-14, 2020-08-14 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 clxscore=1011 mlxlogscore=999 phishscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008140122
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Trt5DgsD7Nt6QLL_bCPqPSeCBJA>
X-Mailman-Approved-At: Mon, 17 Aug 2020 08:30:45 -0700
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: Fri, 14 Aug 2020 16:25:02 -0000

Hi Acee and Tom,

The authors of ID: draft-ietf-mpls-base-yang met and we discussed the points below.
We understand that RFC8349 defines an AF-agnostic model for RIBs. RFC8349 defined only two types of RIBs (IPv4 and IPv6 RIBs), but we envision other types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in addition to MPLS RIB -- and we hope all such RIBs indeed leverage the generic RIB model introduced in RFC8349.

We revisited Acee's suggestion and made a small modification (on top of it) that makes IP routes, MPLS routes (and possibly L2 or MCAST routes in future) - all have similar MPLS augmentation (in terms of local-label) while still adhering with RFC8349 to augment with leaf destination-prefix.

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 a native MPLS route.";
  leaf destination-prefix {
    type leafref {
      path "../local-label";
    }
    description
      "MPLS destination prefix.";
  }
}

We follow same approach for the active route RPC and continue to use a leaf "destination-address" as input (that points to a local-label leaf).
If this is acceptable, we believe the errata 6251 can be rejected and we'll proceed with the change in the MPLS RIB model.

Regards,
Tarek (for authors)

On 8/11/20, 9:08 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

    [External Email. Be cautious of content]


    Hi Tom, Draft Authors,

    The draft could easily be fixed. You just need to:

      1. Expand on the single sentence in section 2.1 on the need for non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't apparent to most of the reviewers.
      2. Add an MPLS AF only augmentation (enforced via a when statement) to each route for the MPLS AF specific destination-prefix or destination-address.
      3. Limit the current local-label augmentation to non-MPLS AFs.
      4. Limit the active-route augmentation to AF MPLS and change the input to destination-address.

    Thanks,
    Acee

    On 8/11/20, 6:10 AM, "tom petch" <ietfc@btconnect.com> wrote:

        From: Acee Lindem (acee) <acee@cisco.com>
        Sent: 11 August 2020 10:47

        Hi Tom,
        I fully understood your original comment. There are other problems with this model. See inline.

        On 8/11/20, 4:59 AM, "tom petch" <ietfc@btconnect.com> wrote:

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

        It is not reusable as is since the augmentation RPC augmentation must have a when statement restricting it to AF MPLS. Also, local-label is a leaf which is applicable to all address families. It cannot be the AF MPLS destination-prefix. This augmentation is missing.

        <tp>
        I am probably getting out of my depth here,  On 1may20 I raised the issue of why the 'MUST' in the description in RFC8349 was not enforced in the YANG and 5may20 Martin explained that there is a rule in the YANG ABNF of input-stmt that makes the obvious impossible:-(  You are raising more profound issues about the RIB that I had not perceived when I reviewed mpls-base-yang for which I, and I hope everyone else, will be grateful.

        If this mpls I-D is to proceed in the immediate future, it looks like the action may have to be deferred for future study.

        More generally, I think that the interaction of forward by address and forward by label is challenging.  When first I looked at the MPLS I-D I was surprised at the way RFC8349 was augmented.  I had not seen MPLS as an alternative to IPv4 or IPv6 or ... in the way in which the RFC is used although the RFC does state that it can be; rather, to me, labels are a different animal, but I assumed that everyone knew what they were doing.

        Tom Petch


        Thanks,
        Acee


            <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



    Juniper Business Use Only


Juniper Business Use Only