Re: [mpls] MPLS label and LSE data models

Jeffrey Haas <jhaas@pfrc.org> Mon, 17 July 2017 08:33 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 320B0131AA9; Mon, 17 Jul 2017 01:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fxe721502qCD; Mon, 17 Jul 2017 01:33:24 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B608F131AD9; Mon, 17 Jul 2017 01:33:16 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id B82121E377; Mon, 17 Jul 2017 04:42:50 -0400 (EDT)
Date: Mon, 17 Jul 2017 04:42:50 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Tarek Saad (tsaad)" <tsaad@cisco.com>, Xufeng Liu <Xufeng_Liu@jabil.com>, 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>
Message-ID: <20170717084250.GA24942@pfrc.org>
References: <BN3PR0201MB08676A90584EC7E8414244B3F1CB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <CA+RyBmWHvfXt_Vdhc5w70ugQTSS5qffTWbQ+Lb9D_6PpfP10QQ@mail.gmail.com> <BN3PR0201MB0867AA3D4476A1DD25B3FC88F1CB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <20170620205021.GG2289@pfrc.org> <BN3PR0201MB0867B31271FFD40ED11B2B6EF1DB0@BN3PR0201MB0867.namprd02.prod.outlook.com> <20170710202101.GC12373@pfrc.org> <BN3PR0201MB08670C450E7800A07F116716F1AC0@BN3PR0201MB0867.namprd02.prod.outlook.com> <20170713165140.GI7180@pfrc.org> <48F70EFB-2DAE-4902-9D9D-AD26AC4D49E1@cisco.com> <D58E9EC8.B88E8%acee@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D58E9EC8.B88E8%acee@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/OzfvwCyv3r2L9Na1qCEtcMmzQXY>
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: Mon, 17 Jul 2017 08:33:26 -0000

Acee,

On Fri, Jul 14, 2017 at 08:31:25PM +0000, Acee Lindem (acee) wrote:
> Typically, YANG indices are added to YANG lists to simply imply ordering.
> I don’t believe there is absolutely any value in trying to enforce the
> semantics of a precise label position on this index. It is fairly obvious
> that the first label in the list is the first label in the stack, the
> second label in the list is the second label in the stack, and so on…
> Hopefully, the other YANG model authors will agree with me on this point
> and the “Index 0 as top” convention should be relaxed. Is there a YANG
> doctor in the house???
> 
> Now, we currently specify the top label as the first label in the list
> while Jeff has proposed that the bottom label be the first label.  Surely,
> there is an existing convention within MPLS RFCs and drafts and we should
> be consistent. I’d research myself but I have a ton of other things to do
> prior to leaving for Prague tomorrow. When someone refers to the first
> label, is the top or bottom label? I have always been referring to the
> first label as the top label (with all due respect to C stack
> implementations).

Generally, people view stacks from top to bottom.  I don't think there's any
argument about that.

As noted in the thread, the issue is that the indexes are there for ordering
and to remove ambiguity when the same value is present in the list twice.

But since the ordering is implied by indexes and gaps are permitted, a sort
operation is still required.  The question becomes whether there's any use
in letting a well known value, such as 0, can be an expected bottom or top
of stack element?  I believe the answer is yes, but have a mixed opinion
whether bottom or top would be better.  

I think the arguments for each are:
Bottom: This is the only label that has special semantics - it's the last
one and gets the bottom of stack bit.
Top: This is the label you forward on.

I'm ambivalent as to which is most useful, but do suggest we should use one
of the two.

-- Jeff