Re: [mpls] MPLS label and LSE data models

"Acee Lindem (acee)" <> Fri, 14 July 2017 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2140412EB96; Fri, 14 Jul 2017 13:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p_kcDZYOTMvA; Fri, 14 Jul 2017 13:31:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C5C4130A92; Fri, 14 Jul 2017 13:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=23263; q=dns/txt; s=iport; t=1500064288; x=1501273888; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=toUbAFtTXICEArUn4VaazWZ02XV9g/xV+/B+HxElolg=; b=InGWHqP9yzi188TIpH20mTFpjqxKadeWudI2CIrPDH2fL2inxitDf0m2 R5ulmDaisYF1xlNnqyXVUtLk+Vv9D64enFJFlMHzTG3pA8QQK5vOvH9Mq 4jtFUPhN8buuS/I9sZt98eFxF5vnjBdrRWboPEIcBc6MXrSCrBIse8+pa I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.40,359,1496102400"; d="scan'208,217";a="268316169"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2017 20:31:27 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v6EKVQiZ032050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Jul 2017 20:31:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Jul 2017 16:31:26 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 14 Jul 2017 16:31:25 -0400
From: "Acee Lindem (acee)" <>
To: "Tarek Saad (tsaad)" <>, Jeffrey Haas <>, Xufeng Liu <>
CC: Greg Mirsky <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: MPLS label and LSE data models
Date: Fri, 14 Jul 2017 20:31:25 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D58E9EC8B88E8aceeciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] MPLS label and LSE data models
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jul 2017 20:31:31 -0000

Hi Tarek, Jeff,

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


From: "Tarek Saad (tsaad)" <<>>
Date: Thursday, July 13, 2017 at 1:12 PM
To: Jeff Haas <<>>, Xufeng Liu <<>>
Cc: Greg Mirsky <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>, Routing WG <<>>
Subject: Re: MPLS label and LSE data models
Resent-From: <<>>
Resent-To: <<>>, Yingzhen Qu <<>>, Acee Lindem <<>>, Christian Hopps <<>>, <<>>
Resent-Date: Thursday, July 13, 2017 at 1:12 PM

Hi Jeff and Xufeng,

Sorry, catching up on this thread. Yes, we've made a change for the MPLS label-stack from "leaf-list" to a "list with key index" to address having multiple labels of same value in the same stack.

We noted an assumption in the description that index 0 is the top of the stack followed by the remainder of the labels in the stack. However, you have a point about enforcing index (n-1) being present before accepting index n. There is some discussion on 'preceding-sibling' and 'following-sibling' with some recommendations in rfc6087.. I'll need to check if enforcing such "when" check is good idea in YANG.

Another idea (not so elegant) is relax this "index 0 as top" and just accept the lowest index of the list as the top followed by the remainder labels (as sorted in index increasing order).



-----Original Message-----

From: Jeffrey Haas <<>>

Date: Thursday, July 13, 2017 at 12:51 PM

To: Xufeng Liu <<>>

Cc: Greg Mirsky <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>

Subject: Re: MPLS label and LSE data models

Resent-From: <<>>

Resent-To: Tarek Saad <<>>, <<>>, <<>>, <<>>, <<>>, <<>>, <<>>, <<>>, <<>>, <<>>

Resent-Date: Thursday, July 13, 2017 at 12:42 PM


    On Thu, Jul 13, 2017 at 04:14:18PM +0000, Xufeng Liu wrote:

    > Thanks for looking at this. You are right, but we are still discussing various approaches for the static MPLS and the conclusion has not been reached yet.

    > We'd like to hear what you think and appreciate your comments.

    To offer a suggestion, order the stack from bottom (lowest number) to top

    (highest).  Require that bottom of stack be element index zero.

    My yang constraints are a bit weak but I believe you can construct an XPath

    that requires that a node of index 0 must be present.

    The above two suggestions don't help with the issues of needing to sort the

    list by index in order to generate the stack, but it does at least remove

    any possible ambiguity about the critical bottom of stack semantic.

    -- Jeff