Re: [mpls] MPLS label and LSE data models

Xufeng Liu <Xufeng_Liu@jabil.com> Thu, 22 June 2017 15:44 UTC

Return-Path: <Xufeng_Liu@jabil.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 43EC5129A8D; Thu, 22 Jun 2017 08:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.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 kphwtDmFBKm3; Thu, 22 Jun 2017 08:44:32 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0130.outbound.protection.outlook.com [104.47.38.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1929F1200B9; Thu, 22 Jun 2017 08:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zALFvXUxIZvR6ZFLdNKuT4FQHqhn0rHIP/XK9MGKrvI=; b=hp3djZsSNFsxEyEmMdbUpiweWIzcGBDsNYksML5RhuqegbRjHa6O1HdLgcamPPyfgrFv8ywBA7xu4HiTsqqUqYXRMaDIW08quKrE2ACIAHEqw8tWKht4OdXNv24Us27TY+mXfxY1UIMZqle+Okpey+MIg1tM+tpXZ5Ae0WjUH2U=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0868.namprd02.prod.outlook.com (10.160.154.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Thu, 22 Jun 2017 15:44:29 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1178.023; Thu, 22 Jun 2017 15:44:29 +0000
From: Xufeng Liu <Xufeng_Liu@jabil.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: Greg Mirsky <gregimirsky@gmail.com>, "draft-ietf-mpls-static-yang@ietf.org" <draft-ietf-mpls-static-yang@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-rtgwg-routing-types@ietf.org" <draft-ietf-rtgwg-routing-types@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: MPLS label and LSE data models
Thread-Index: AQHS3ksFqqRkmLzX6Uy60rxp1VrMZKIW8faAgAANVICAAOdm8IAAScyAgAAHoPCAFhj3gIACyBDA
Date: Thu, 22 Jun 2017 15:44:28 +0000
Message-ID: <BN3PR0201MB0867B31271FFD40ED11B2B6EF1DB0@BN3PR0201MB0867.namprd02.prod.outlook.com>
References: <CA+RyBmVH=KCi3T8u2dB_WaKBOLheYwT4q0d+tpYdT-Z2iTZ+og@mail.gmail.com> <D55B6659.B21B8%acee@cisco.com> <CA+RyBmVyHKGhxitGgQ6RRMmHKwvs=b_GkKMq80rE=Ys8WetGaQ@mail.gmail.com> <BN3PR0201MB08676A90584EC7E8414244B3F1CB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <CA+RyBmWHvfXt_Vdhc5w70ugQTSS5qffTWbQ+Lb9D_6PpfP10QQ@mail.gmail.com> <BN3PR0201MB0867AA3D4476A1DD25B3FC88F1CB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <20170620205021.GG2289@pfrc.org>
In-Reply-To: <20170620205021.GG2289@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWFhZTgzYmVhLTU3NjEtMTFlNy05YzE3LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxhYWU4M2JlYi01NzYxLTExZTctOWMxNy0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjI0NTgiIHQ9IjEzMTQyNjE5ODY2NDM2MTkyMiIgaD0iZlVwaDR6VlkwRkppa3J5WncxRXlaVG50YkxrPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
authentication-results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=jabil.com;
x-originating-ip: [98.191.72.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0868; 7:aZWVdnVoTECwj6Btm3yhLg9ZWAKeLbNp1ehiv+GzuknDFkmuGVow+gaWprqbHY2AWK+ah4PpdGFVtDj5haB9HozeNWYrCaowd6jU2KX//zEyPg4hptm28VNwCB75TQjIqEUMAFUpmlv/s4Kpp5oX45uaegxsFBQ06cph7fWD4NB3s/WAdW2M7y1FZQDok/n39S/OVZ3Bi+hHnhUwu/Dqn+qi02mwD1i8ZUMuSnNIc5dlP3ojcpGlUjlgcmCrrRZNmgpHC3dLuC3An7MIbkRgF+5k88v53Z5yo5bHd6wllhv0mkkhFjLdKSIgXraQDCzxMVV/ILH0zhjQi3HdZO3Q9ypluHblo4d95g3OCS+ZqOnabFLeHeLoawFb3WzVZx8z2QAxQ4ErP/bIArbyDFP4ENADI00ZnbNWso6uIpyW3TFgcT3bL+ljCFXAt69DtYSR46YQSvHySbG6hzj1zAx5xW+FTQQt/AEEYRuXmmKqDiknuv6FjDi6PwgX4ut7b1W3uezE7CQTLFB4spK3gXtf72hPpfCOghgEOKSWMea+YBUiBNlyxw4pSHPppZAd5W5VWIju0Tq9hOrn0YD9ezBSmlV9gnrvNltAYk15O+KzisiksHoQMUWw8/ekA0jtv7OC8E6lNf8/McJXhHpGWlFfseDqCk499rfwW0sJ3VoIeUA4mUUXCEkFMxS8gCPoZzeBObcujz0VOBOPatB9qtP+L1kXUBZEYnNddrZmX1nDd0wMIWvevB5xVUrgifW1dhhRfJ2zutj/UYwwgaGEwKufldSpm6GnzQ6jj0t3kT5HTqY=
x-ms-office365-filtering-correlation-id: 5b236f7b-8368-4670-1e4c-08d4b98591be
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0201MB0868;
x-ms-traffictypediagnostic: BN3PR0201MB0868:
x-microsoft-antispam-prvs: <BN3PR0201MB08682935BC8C23E79B1FD408F1DB0@BN3PR0201MB0868.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21534305686606);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0868; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0868;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39850400002)(39450400003)(39840400002)(24454002)(13464003)(377454003)(5660300001)(110136004)(93886004)(25786009)(2906002)(7696004)(86362001)(3280700002)(189998001)(3660700001)(2900100001)(77096006)(74316002)(80792005)(14454004)(6436002)(66066001)(4326008)(55016002)(6506006)(53936002)(229853002)(72206003)(7736002)(50986999)(54356999)(122556002)(76176999)(305945005)(478600001)(39060400002)(2950100002)(99286003)(6916009)(38730400002)(9686003)(54906002)(53546010)(8676002)(81166006)(6116002)(102836003)(3846002)(6246003)(8936002)(33656002)(170073001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0868; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 15:44:29.0058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0868
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/pIz6awYFw13iWzOWYPtmm6SLO94>
Subject: Re: [mpls] MPLS label and LSE data models
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 22 Jun 2017 15:44:35 -0000

Hi Jeff,

> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> Sent: Tuesday, June 20, 2017 4:50 PM
> To: Xufeng Liu <Xufeng_Liu@jabil.com>
> Cc: Greg Mirsky <gregimirsky@gmail.com>; draft-ietf-mpls-static-yang@ietf.org;
> mpls@ietf.org; draft-ietf-rtgwg-routing-types@ietf.org; rtgwg@ietf.org
> Subject: Re: MPLS label and LSE data models
> 
> Xufeng,
> 
> On Tue, Jun 06, 2017 at 07:33:05PM +0000, Xufeng Liu wrote:
> > From: Greg Mirsky [mailto:gregimirsky@gmail.com]
> >   *   yes, grouping mpls-label-stack covers LSE though I cannot see why it needs
> id, sequence identifier. I'd expect the label stack already be properly ordered;
> > [Xufeng] There are two ways to achieve the ordering: 1) Explicit sequence id, 2)
> Implicit order of the list items. Personally I feel that the explicit way is more
> clear and easier to use, but have no strong objection to the implicit way.
> 
> While I found the semantics of mpls-label-stack[id] to be clear, it does have the
> peculiar property that the ids present in the list may have gaps.  E.g. 10,20,30
> instead of 1,2,3.  And also the ambiguity of whether people's implementations
> starting counting at 0 or 1.

[Xufeng] I understand the peculiarity of the ID gaps, but I don't have a good way to eliminate it. It seems that YANG does not have a simple mechanism to specify an ordered list items allowing duplicated items, so we'd need to use the ID, but we cannot restrict the ID values to be consecutive easily. However, the implantation and the operator can ignore the gaps, and use the ID values only for the ordering purpose. Therefore, it would not matter whether the implementation starts counting at 0 or 1, or any other number.

> 
> I'm not conversant with common Yang tool suites, but it seems if the ordered-by
> user rather than the default of system, then the tooling might present the
> bottom of stack entry as the first or last node of the list rather than requiring the
> consumer to have to run a sort of the nodes based on the id number and then
> select the first node.

[Xufeng] Are you suggesting to use the position to order instead of the ID value? If so, what would be the semantics of the ID value? If we cannot get rid of the ID key, I don't know if using a separate ordering mechanism will make the usability better.

Thanks, Xufeng

> 
> -- Jeff