Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard
tom petch <ietfc@btconnect.com> Tue, 01 September 2020 16:03 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 7E7DA3A05DE; Tue, 1 Sep 2020 09:03:43 -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 IZf-mYk_kI_y; Tue, 1 Sep 2020 09:03:41 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2106.outbound.protection.outlook.com [40.107.21.106]) (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 A24173A05AC; Tue, 1 Sep 2020 09:03:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zl0BEk8dFSJizb/gEgrVsWnekZ/8HtueTTxIGmMmSnsnCaw9pqlUwP1o5gRX+OJ8NJr0oPVKetQ6Tkz225WBKdexOMXvzvBJ/bxOipL3eGdj1Wa+1XWXogiFaHyvRiNtqZgeu3h31dSvO5fiU/xLUsYCsryGgak1aaAEfCwqw+l+nTPJQIgO3W7XTs1OSYp4ItG7WThj2ZwqI13eaIUucld8kht78nBlCg8JM3kwKZJ35STPoBWqBjYRM/6+b6N765xRquAa/ExeHx9oUrmVdI1g5oL3VjAOHQW2G1byrvwi/fzYxU6oVDjaGQMxCDNyZCwgKmwHFWPdyCPI5R1YNg==
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=pfpc5gDHARc8VkmCsOfRwKCVadWacUv+YE251n2S15o=; b=dLfg3aMDSLGNRkEQWnXiepHqRXzldo+JM7TsVExaDuMFoms+Uqq/+3QCHHKJ7kuJGk/7eqGLtzjnN+MmVPhOByNWf3BiFGhIHs/xkIUEUijBg9tna5qX78biDvUqnJ/A+5pu4NnoFyZvoZy0tuQJvj/k1+XfUIZXd0EQv0Qxq4uNUuHPUxSqADEGQ+izs3MV9y/GuAddI5ouvfzPheAXJlMm2FxI515DJdnCxsU46RUB1nKXns1gwa7rP1FP0WsnysCTDhPuGYUFb/OySVRtr6OnPPWUWSJdRbFPK5CPJOALxNANSQ4INRK0liaEiTHdmU4Y2eyfVo0cuQm+0rqsPA==
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=pfpc5gDHARc8VkmCsOfRwKCVadWacUv+YE251n2S15o=; b=oxW/s8/bY8ow88KMWXHXV6+WGHsCUQQS4deoQpR8VBR8ig5k1xQV9cXZ58t8f+8MBo5FDR7PY5W+TMjoW9dve+sm7qZAm7RC0+sZiUHjztK8QNyjmKdUee9N5NpROeXPNAl26sNv1++KzWp5H/2IKgRk97ieegZVa1oc0iwwsug=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM5PR0701MB2450.eurprd07.prod.outlook.com (2603:10a6:203:10::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Tue, 1 Sep 2020 16:03:34 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::189c:ac35:ce23:d38a]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::189c:ac35:ce23:d38a%6]) with mapi id 15.20.3348.012; Tue, 1 Sep 2020 16:03:34 +0000
From: tom petch <ietfc@btconnect.com>
To: Tarek Saad <tsaad.net@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Thread-Topic: Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard
Thread-Index: AQHWdLUoAAsve0/gsk2miVdjbBmQ/qlCupkTgABYiQCABBEHloAItEuAgAQu1zw=
Date: Tue, 01 Sep 2020 16:03:34 +0000
Message-ID: <AM7PR07MB62480F7D3F18B1E59CC26800A02E0@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <159664704561.10058.12590600409549515735@ietfa.amsl.com> <5F2BBFAC.7060203@btconnect.com> <DM5PR1901MB2150AE0A6D7445416CD9ADFFFC5F0@DM5PR1901MB2150.namprd19.prod.outlook.com> <AM7PR07MB62488C19E98C6F76845E48A8A05B0@AM7PR07MB6248.eurprd07.prod.outlook.com> <DM5PR1901MB2150FFE9A5B9ACA9B923F3E6FC5B0@DM5PR1901MB2150.namprd19.prod.outlook.com> <AM7PR07MB624822843BD0C193BFA6B79EA0560@AM7PR07MB6248.eurprd07.prod.outlook.com>, <DM5PR1901MB2150F263CA845B78BECEA424FC500@DM5PR1901MB2150.namprd19.prod.outlook.com>
In-Reply-To: <DM5PR1901MB2150F263CA845B78BECEA424FC500@DM5PR1901MB2150.namprd19.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
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=btconnect.com;
x-originating-ip: [86.148.49.170]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bc1a89d5-f7e0-4946-4aaa-08d84e90945f
x-ms-traffictypediagnostic: AM5PR0701MB2450:
x-microsoft-antispam-prvs: <AM5PR0701MB245024E682C10A09AFB32206A02E0@AM5PR0701MB2450.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jmhqgORHbIDi3QsLihvqgscL6nE8DuaBGuWJGqPxonPeFrQhvmffIiJ7qU96jfklYg9mp5GP1V58ojXyB+O9FNF9uhApb/D4NrMx3KeVCK4x6q6pQdCLs9Yqd1kwojQ1UxXM5yzT0Afdevnbvf0ZpOKY9NnO6VlrLAmqlKGimAtrwzdOFBt1UiACyfb8k+V0CtuCfK+/woZKJ+rnNfv1i6bSXTznL1GPuD/0b7zIdXLhO9YJs2mm0WTE8yglCq0AXXYN8oudcINeDXI01rqeCxwJlTuOkYwBmFuQpUpKTLMhBTd7OIKrubOC7Bdcd/i1CQafavT1xDdZZCqpjCTEWEHuXG4heISWJsG6vlEQkjE6KKGekxjcKv6F6u4pw95OmQVvZ1fcT5hWmmIiuGw4yQ==
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:(376002)(346002)(39860400002)(396003)(366004)(136003)(86362001)(71200400001)(66574015)(5660300002)(110136005)(54906003)(4326008)(7696005)(26005)(186003)(8936002)(55016002)(8676002)(53546011)(966005)(316002)(83380400001)(9686003)(6506007)(478600001)(33656002)(66946007)(66476007)(52536014)(64756008)(66446008)(76116006)(91956017)(2906002)(66556008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: /duIeQetNZigiKyc/Pl6kQqkVpTB1Kl1LCgZo8ewUyJ+V47+80+Y32fKL4rYVQ2SAPH8+Q9Eog7iaNcGTx2uBaNNrqdwFP2WEMOVA4VgAlRsSohsKLlb83o8ZaosheO19YOTZJB9oK0VwD6gZajc9TaotVXYduG/L3Yrvu+6UYDM+W7unrqcpO7m5jqSzDRRx1tY5kKF/1g4Pf3A4ix5GNejmdeOUoaldz9EBzZbfkiB1II/00a7fQBgfZAPz9Rkax/guu41iEELjIa4/6T4YHTstaX1ER2NfQLsNhYTPt6tudnPLLJf8f+W3a6SXtEbZNxRZ0AunTZZMyXU7oyRpuZN/CoeIem6CAtpcSXXr1fteJknOR3+Gd8EY3vQahFlGmVFHO5Z5jJCvCuROdQJ/cv2kvadYQYcy0Z9eRRmG3YgByHuqgiwZmi3Rdtc7lrP6ivy2dHBN1zYfXh6T7yAPA/4hBbDIOEeSpoOYFOHnySgbewI9lfPer3sg2+mOhz2loAD8bjghr4WpwK2ke76ezciYExtQtX2K5LkC8vYqXcU2oIMmUX3Xqwe7VUfvB4UUn/HCU6pR1CD9SnKfKKF++TcxzUI6zwTP1JlNzn/2faFTvKTkcPJTN4xPOeRk4nDFIoEHnOXe3Ju2/mwVXk35A==
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: bc1a89d5-f7e0-4946-4aaa-08d84e90945f
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 16:03:34.3848 (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: I9jd1N33X596NPkKIMbQGqCxbbRK6KgY3wxsV7Uhl1wyii2kWo0iVAv8sJfJEnKPSzBYy1pGuOX9xOg2mY9YCw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2450
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PmuV3uqkoFY6ZPbU5IJvFTQMf0o>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard
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: Tue, 01 Sep 2020 16:03:44 -0000
From: Tarek Saad <tsaad.net@gmail.com> Sent: 30 August 2020 01:03 Hi Tom, Thanks. See inline.. <tp2> Tarek I am not sure if we are on the same wavelength. I was looking at the next hop or input augments which go augment description [omitted by me last time] uses when so 'when' is a child of uses and makes that conditional whereas the description is not conditional and so will always be added and there is nothing else in the augment for these three cases AFAICT. I get the difference between the augment to all RIBs (strictly speaking this is conditional, on if-feature mpls) and the augment specific to AF mpls but still think it should be augment when description uses so 'when' is a child of augment and so nothing is added when the YANG 'when' evaluates to false. [TS]: we reviewed the code - and in the snippet below - we believe the uses of the grouping is subject to 'condition-foo' under it evaluating to 'true'. uses foo { when "condition-foo"; } So, if the description under the "uses" is somewhat misleading, we are propose the below change to the description. Let us know if this addresses your concern. OLD: uses rib-mpls-properties { /* MPLS AF aaugmentation to native MPLS RIB */ when "derived-from-or-self(../../rt:address-family, " + "'mpls:mpls')" { description "This augment is valid only for routes of native MPLS RIB."; } NEW: uses rib-mpls-properties { when "derived-from-or-self(../../rt:address-family, " + "'mpls:mpls')" { description "This grouping is added only for routes of native MPLS RIB."; } <tp3> Well, yes, it will work but I am slightly puzzled why you do not make the YANG 'when' a child of the YANG 'augment' so that the 'augment' is made conditional. That is what I see in RFC8349 with v6 unicast or v4 unicast and is what I am used to seeing in the many TEAS YANG modules such as teas-yang-te-topo Tom Petch On 8/24/20, 7:23 AM, "tom petch" <ietfc@btconnect.com> wrote: From: Tarek Saad <tsaad.net@gmail.com> Sent: 21 August 2020 22:01 Hi Tom, Thanks again. Please see responses inline.. On 8/21/20, 12:14 PM, "tom petch" <ietfc@btconnect.com> wrote: From: mpls <mpls-bounces@ietf.org> on behalf of Tarek Saad <tsaad.net@gmail.com> Sent: 17 August 2020 17:40 Thanks Acee and Tom. I'm merging the discussion on the other thread (titled: [mpls] [netmod] [Technical Errata) and providing the update. We have uploaded a new revision https://tools.ietf.org/html/draft-ietf-mpls-base-yang-15 that addresses the comments previously raised. Please let us know if there are further comments. <tp> Tarek I think that the YANG 'when' clauses are slightly misplaced. You have augment uses when which makes the 'augment' unconditional and the 'uses' conditioned. Look at RFC8349 and it has [TS]: Indeed, our intent is to make the 'augment' unconditional (applicable to all RIBs) and the specific grouping 'uses' conditional. For example in the below snippet below, the leafs 'mpls-enabled' and 'local-label' are unconditionally augmented to all RIBs, but ' destination-prefix' of 'rib-mpls-properties ' is only applicable to native MPLS RIB - address-family=mpls). <tp2> Tarek I am not sure if we are on the same wavelength. I was looking at the next hop or input augments which go augment description [omitted by me last time] uses when so 'when' is a child of uses and makes that conditional whereas the description is not conditional and so will always be added and there is nothing else in the augment for these three cases AFAICT. I get the difference between the augment to all RIBs (strictly speaking this is conditional, on if-feature mpls) and the augment specific to AF mpls but still think it should be augment when description uses so 'when' is a child of augment and so nothing is added when the YANG 'when' evaluates to false. Tom Petch. augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { if-feature "mpls"; description "This augmentation is applicable to all MPLS routes."; leaf mpls-enabled { type boolean; default "false"; description "Indicates whether MPLS is enabled for this route."; } leaf local-label { when "../mpls-enabled = 'true'"; type rt-types:mpls-label; description "MPLS local label associated with the route."; } uses rib-mpls-properties { /* MPLS AF aaugmentation to native MPLS RIB */ when "derived-from-or-self(../../rt:address-family, " + "'mpls:mpls')" { description "This augment is valid only for routes of native MPLS RIB."; } } } . augment when uses 'present in the AF RIB(s) in the MPLS Architecture' I do not understand. RFC3031 does not use 'RIB' nor 'AF' nor do I think the terms were in use then. RIB v routing table was a contentious point in the genesis of RFC8349 and I think we should only talk of RIBs when we use it in the RFC8349 sense. I think you are saying that all routes in all RIBS are augmented with the label information needed for MPLS forwarding but I do not see that in the words. [TS]: Yes, your reading is correct. I tried to clarify this in section 2.1 and illustrated it in section 2.3 (see below): >>>> 2.1. Model Overview This document models MPLS labeled routes as an augmentation of the generic routing RIB data model as defined in [RFC8349]. For example, IP prefix routes (e.g. routes stored in IPv4 or IPv6 RIBs) are augmented to carry additional data to enable it for MPLS forwarding. <<<< >>>> 2.3. Model Design .... +-----------------+ | MPLS base model | +-----------------+ ____/ | |_____ |________ / | \ \ / | \ \ o o o + +---------+ +---------+ +--------+ +-----------+ | RIB(v4) | | RIB(v6) | | RIB(x) | | RIB(mpls) | +---------+ +---------+ +--------+ +-----------+ +: created by the MPLS base model o: augmented by the MPLS base model Figure 2: Relationship between MPLS model and RIB instances As shown in Figure 2, the MPLS base YANG model augments defined instance(s) of AF RIB(s) with additional data that enables MPLS forwarding for destination prefix(es) store in such RIB(s). For example, an IPv4 prefix stored in RIB(v4) is augmented to carry a <<<< (!RFC8349}) RFC6991 needs adding to the Normative References [TS]: thanks, will be corrected. leaf start-label must '. >= ../end-label' "The start label must be less than or equal to end-label" umm augment .../route if-feature "mpls"; "This augmentation is applicable to all MPLS routes" true but incomplete IMHO "This augmentation is applicable to all routes in all RIBs on a device with the feature MPLS enabled" and I think this important in understanding what the YANG is trying to do, which I did not with -14 [TS]: ack, I can update this description accordingly. /aaugmentation/augmentation/ [TS]: thanks for reporting this. Regards, Tarek I am still digesting this I-D. I am not clear what the plans of the AD are right now in terms of timescale. In passing, I pointed out to the BFD WG that their YANG model stopped being compatible with the MPLS YANG model in 2018, when /config got removed from /mpls/interface. They are having a closer look. Tom Petch Regards, Tarek (for co-authors) On 8/6/20, 4:31 AM, "tom petch" <daedulus@btconnect.com> wrote: This I-D breaks a MUST in RFC8349 Routing Management) and, as such, will not interoperate with devices that implement RFC8349 correctly. RFC8349 provides a YANG action to return the active route for a destination address but omits the destination address, saying that modules using this must augment the input with a leaf destination-address. This I-D augments the input with a leaf local-label so implementations of RFC8349 that 'know' there will be a leaf destination-address will fail to interoperate with this I-D. The authors said, at WGLC, that RFC8349 is wrong, that MPLS has label not address and so the I-D must provide an augment with a label and RFC8349 should change. I disagree; I think that this is reading too many semantics into an identifier. Tom Petch On 05/08/2020 18:04, The IESG wrote: > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: - 'A YANG Data Model for MPLS Base' > <draft-ietf-mpls-base-yang-14.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-08-19. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document contains a specification of the MPLS base YANG model. > The MPLS base YANG model serves as a base framework for configuring > and managing an MPLS switching subsystem on an MPLS-enabled router. > It is expected that other MPLS YANG models (e.g. MPLS Label Switched > Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS > base YANG model. > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
- [mpls] Last Call: <draft-ietf-mpls-base-yang-14.t… The IESG
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… tom petch
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… Tarek Saad
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… Tarek Saad
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… tom petch
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… Tarek Saad
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… tom petch
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… Tarek Saad
- Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-… tom petch