Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 14 August 2020 17:38 UTC
Return-Path: <rwilton@cisco.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 A23933A0F85; Fri, 14 Aug 2020 10:38:22 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UPtGq51P; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=c03bNFMi
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 It7JZC3gYexT; Fri, 14 Aug 2020 10:38:20 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5063A0F56; Fri, 14 Aug 2020 10:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25876; q=dns/txt; s=iport; t=1597426693; x=1598636293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FTgVZVb7924P87PqKVOwx9XWARiuETcYGu86bnGn2gs=; b=UPtGq51PPTtFSz4vySdd4G+Y6BAN03dSx/Y93zhX4sXyzywdhY9EIEEE lz8D81+673fmji3tZ7TQQwzZXwDnrCBJ8MzGWh4a0fdF2EloM3L7j6H8S J7UXrnpSoNBWCQDThWK7RIVDwKDljIGDI9d92A4m7OkG7T+dpkt1+qhwu c=;
IronPort-PHdr: 9a23:CvKGfxfTzIM/AZObbLySLEBalGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0jE
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQA8yzZf/5NdJa1eHQEBAQEJARIBBQUBQIE5BQELAYFRKSgHcFgvLAqELYNGA41UigiOX4FCgREDVQsBAQEMAQEYDQgCBAEBhAhEAheCMAIkNwYOAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBAEBEBERDAEBLAsBCwQCAQgOAwQBAQECAiYCAgIfBgsVCAgCBAENBQgTB4MFgksDLgEDC6gAAoE5iGF2gTKDAQEBBYUgDQuCDgmBDioBgnCDYII+hA4agUE/gRFDgk0+gQSBFkIBAQKBKAEMBgEHHIMVM4Itj2gQF4J0hweCeYgLMpAhUQqCYohjjD2FIIJ/gSOIOIgsixmSOIFsiFaCZY1phCwCBAIEBQIOAQEFgWkkZ3BwFRohgmkJRxcCDY4fDBeBAgEBCYJBhFk7hQkBNwF0AjUCBgEJAQEDCXyNYYE0AYEQAQE
X-IronPort-AV: E=Sophos;i="5.76,313,1592870400"; d="scan'208";a="801547484"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 17:38:11 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EHcB1b032697 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 17:38:11 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 12:38:11 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 13:38:10 -0400
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 12:38:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aU3oZul+opuzOXeTUtYibfUySMpWu5uKSLLu0iYpFOQV0HdjQUzi60mcsEuiSQDMtAu6S963rlBGiQt7AsTD8VAd8eQvu6BvulbRKNBjBauqNziBqMu2b40/kJ3TOMZdugmi9xAqosGFw2Q5yFiVmi0eF6OgoX6RiQWQW/xOboevLtc0+FW/Cocuyg9UA8stUp2Kj5QChfdo1AndrSnkZ8epIlpA4ShK8A9nsTGJslignQbCE4xfJTp5QkPjaowjRPkwqBttYAXl7cscmbAtJFk+ShcHVoLwyE2Qptrwalt+3XGtqcJZUe+ButOZBVl09pBviGyUnJsuOR6od4mdww==
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=FTgVZVb7924P87PqKVOwx9XWARiuETcYGu86bnGn2gs=; b=aepfzOkLUrO7N+8U10PhwdGU3YqVWUwx7yuSIF49bCxoQyGGHD6s8/ZVk8sGthitQWqsZVTcBXqt91IG0pzPUE/Z8TNx201CzkirDTBZStpQCbCLz7mc4Sg3IoymZzEZRxWMi5L6hubB35gFjIlUjgL9cxKnZfB3Ma1n3QbE+ZWSrJegpkdwXydtjAJciWmLNobzezukevXG4o7pFuvNkGB5hil0VGM+CUDrMsSYi3zACGWEak84KHxIr8f124Q8Vbh/ESCNxVqjQH4v68au7vnvBRsUFYMlzItnHt358fL9dYCN7Wsf7Y6oAronDu/9oVozCNIUf/t8wxNvs3rmtg==
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=FTgVZVb7924P87PqKVOwx9XWARiuETcYGu86bnGn2gs=; b=c03bNFMi8g2HKhQLhduh+t13OrcVDIWuhuSLl9156nqJlIR6xfrJt1x0uCZx7HmJHRQUOeldcyvPmNFcMJXV4RFt+IVJn0qA78qw/ZSSG6WwjOUopIZIg6pobEoNvfBMT5GrjvJkEoQVSBthI/R+1QFs94gWjEatjyrWo/qkKfg=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3250.namprd11.prod.outlook.com (2603:10b6:208:63::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 17:38:04 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3261.025; Fri, 14 Aug 2020 17:38:04 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Tarek Saad <tsaad.net@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Tarek Saad <tsaad@juniper.net>, 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: "mpls@ietf.org" <mpls@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Thread-Topic: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
Thread-Index: AQHWclgCPYxsuyrUxEGu5AtxD3hO8qk3y7kAgAASW+A=
Date: Fri, 14 Aug 2020 17:38:04 +0000
Message-ID: <MN2PR11MB436634C0D2745EB5ED6E00D5B5400@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <AABAB849-3792-41AE-928B-3D72F843DBF6@cisco.com> <DM5PR1901MB21506A86E97321388872F0A3FC400@DM5PR1901MB2150.namprd19.prod.outlook.com>
In-Reply-To: <DM5PR1901MB21506A86E97321388872F0A3FC400@DM5PR1901MB2150.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3b88cfe2-9e8c-4f1c-61bf-08d84078cc93
x-ms-traffictypediagnostic: BL0PR11MB3250:
x-microsoft-antispam-prvs: <BL0PR11MB325077978B42DA506853FEE8B5400@BL0PR11MB3250.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: 82JHleiekqOcunBJNy9kST/8lMXV6ZkDlbNy0XTBnp52OB+kjAC8IQj31n6THIcfmGU/kqAed8qexdbfMa5aSzSkblvLtbfy34tjOkGsRHg3jTz43h/lUCv1arDLmNb6/f8gNAFa8SYqADIYnB4Ha3sAdqeJSlEw8mxxUWpAetkqnQ+4BLNsBx924Vkk32UETb6k2GyBgNHZEw2fUZO+uPxe8KsmVzv2rWZjVRc5JBVXcXo0zNNOyBFJm/sS6FNS0/spvD2WVmJ6+ILusJ8LyN0W9+qDiT1w/jhPvbN7tDnZwWqW3mISjoQA239YbsdEElyYjqDFYFq6AEbJHEpNqG1zMecU2+53J/S6z+YPORhVo5Zr/adzYYmXrYDJl+wexcQnHP1gARJ5+OYnNf4NVg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(136003)(366004)(39860400002)(30864003)(7696005)(186003)(26005)(6506007)(52536014)(53546011)(966005)(2906002)(5660300002)(54906003)(86362001)(316002)(110136005)(7416002)(478600001)(71200400001)(83380400001)(8936002)(33656002)(76116006)(66556008)(66476007)(66946007)(4326008)(64756008)(66446008)(8676002)(9686003)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: oCyppd/4cakitIm42PDgCzAuh6vWE/k6Djtf2GFYMxN8FXIebT+Psajwf1zUM1HmmWIglFlUe5kfpR10ZP3e9UNhVcGL9Oew2bJCL95fDKxwubQmK1O4qVwwDsQncaAli6Lj92FRd3W2jkbkQAu2Yw53B17Crnedn1J7E6Who6Ppj9SEmxkVRdhnM2XkE8MGRJGiBzloAwnGL3sTzxoNDkc91UoUEvqUBh1nlFkRjY+rfkQEwUf1+FetZLP4eC877QholaS5MCYi5xcbSRcFNvB33BafSq73lA0rQHMijVXqXHHaov1sLUCpvsCpekSZz7/hR/EnNcH6EpyWE2eDUtHZqDeKusNMVQCwKzHU39KBX4R62aeSgBSpAaUnUgDRWW4u+DJ8PqIqMypv/zP6wIerUbms5App7OSRWDT752PGNUqeBfsaCgt92WqjRTUb83m1l5Tp4Uty24Za+ltI1GuccNTr+DVCmrIYVtnjNFgBEcDrmlZoZhLWRkq/2wg5Da6SVAGbsRlaJz+MsX/+VUJE9wChejwfLoT9f+rWyGuAvf4xuc9eLVMui83RyVv8kNQ1M7Zgu5yKai8fHhFGY/YOuVMahxiEWtoyA4upAUax8UfZKHgvfV2CKUtLFGAqpWrw2CAGsOTzKA7pv6bcMw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b88cfe2-9e8c-4f1c-61bf-08d84078cc93
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 17:38:04.3890 (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: mn51vdJgupZrIclorxSkjtPpfa4RZ3S5FxOOqdt9KQNcer2i0lmdV+Gjt/ia3K42s/RjMzKrWaKFELTUzByxTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3250
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/gAVk1YxZJcT4i7q0MKSSO0MTaZs>
Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 14 Aug 2020 17:38:23 -0000
Hi Acee, Tarek, Tom, Thank for all for your time and help in resolving this issue. I will reject the erratum. Regards, Rob > -----Original Message----- > From: Tarek Saad <tsaad.net@gmail.com> > Sent: 14 August 2020 17:30 > To: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; Tarek Saad > <tsaad@juniper.net>; tom petch <ietfc@btconnect.com>; Rob Wilton (rwilton) > <rwilton@cisco.com>; RFC Errata System <rfc-editor@rfc-editor.org>; > lhotka@nic.cz; yingzhen.qu@huawei.com; warren@kumari.net > Cc: mpls@ietf.org; netconf-chairs@ietf.org; netmod@ietf.org; draft-ietf- > mpls-base-yang@ietf.org > Subject: Re: [mpls] [netmod] [Technical Errata Reported] RFC8349 (6251) > > Thanks Acee. Yes, will do in the next rev we'll push soon. > > Regards, > Tarek > > On 8/14/20, 12:29 PM, "mpls on behalf of Acee Lindem (acee)" <mpls- > bounces@ietf.org on behalf of acee=40cisco.com@dmarc.ietf.org> wrote: > > Hi Tarek, > Can you also add the description of the native MPLS RIB to the text? > Thanks, > Acee > > On 8/14/20, 12:27 PM, "mpls on behalf of Acee Lindem (acee)" <mpls- > bounces@ietf.org on behalf of acee=40cisco.com@dmarc.ietf.org> wrote: > > Hi Tarek, > This works for me. > Thanks, > Acee > > On 8/14/20, 12:25 PM, "Tarek Saad" <tsaad@juniper.net> wrote: > > 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>; lhotka@nic.cz; Acee > > Lindem (acee) <acee@cisco.com>; > yingzhen.qu@huawei.com; warren@kumari.net; > > Rob Wilton (rwilton) > <rwilton@cisco.com>; 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
- Re: [mpls] [netmod] [Technical Errata Reported] R… Acee Lindem (acee)
- Re: [mpls] [netmod] [Technical Errata Reported] R… Tarek Saad
- Re: [mpls] [netmod] [Technical Errata Reported] R… Acee Lindem (acee)
- Re: [mpls] [netmod] [Technical Errata Reported] R… tom petch
- Re: [mpls] [netmod] [Technical Errata Reported] R… Acee Lindem (acee)
- Re: [mpls] [netmod] [Technical Errata Reported] R… tom petch
- Re: [mpls] [netmod] [Technical Errata Reported] R… Acee Lindem (acee)
- Re: [mpls] [netmod] [Technical Errata Reported] R… Tarek Saad
- Re: [mpls] [netmod] [Technical Errata Reported] R… Acee Lindem (acee)
- Re: [mpls] [netmod] [Technical Errata Reported] R… Tarek Saad
- Re: [mpls] [netmod] [Technical Errata Reported] R… tom petch
- Re: [mpls] [netmod] [Technical Errata Reported] R… Rob Wilton (rwilton)
- Re: [mpls] [netmod] [Technical Errata Reported] R… Yingzhen Qu
- Re: [mpls] [netmod] [Technical Errata Reported] R… Yingzhen Qu
- Re: [mpls] [netmod] [Technical Errata Reported] R… tom petch
- Re: [mpls] [netmod] [Technical Errata Reported] R… tom petch
- Re: [mpls] [netmod] [Technical Errata Reported] R… Acee Lindem (acee)
- Re: [mpls] [netmod] [Technical Errata Reported] R… Tarek Saad
- Re: [mpls] [netmod] [Technical Errata Reported] R… tom petch
- Re: [mpls] [netmod] [Technical Errata Reported] R… Kent Watsen