So, for this particular grouping the only action I’m going to take is to update
the description fields to address any confusion. It should be noted that the
RFC 8022 next-hop index has not semantic meaning other than referencing the
next-hop. The label-stack id has similar semantics.
ACEE-M-G2HR:conventions-features acee$ git diff ietf-routing-types.yang
diff --git a/ietf-routing-types.yang b/ietf-routing-types.yang
index b83699d..6e77ce0 100644
--- a/ietf-routing-types.yang
+++ b/ietf-routing-types.yang
@@ -607,7 +607,10 @@ module ietf-routing-types {
grouping mpls-label-stack {
description
- "A grouping that specifies an MPLS label stack.";
+ "A grouping that specifies an MPLS label stack. List
+ entries are ordered with the first entry being the
+ top of stack, the next entry being the next entry
+ on the stack, and so on.";
container mpls-label-stack {
description
"Container for a list of MPLS label stack entries.";
@@ -618,9 +621,11 @@ module ietf-routing-types {
leaf id {
type uint8;
description
- "Identifies the sequence of an MPLS label stack entries.
- An entry with smaller ID value is precedes an entry in
- the label stack with a smaller ID.";
+ "Identifies the entry in a sequence of an MPLS label
+ stack entries. An entry with smaller ID value is
+ precedes an entry in the label stack with a smaller
+ ID. The value of this id has no semantic meaning other
+ than ordering and referencing the entry.";
}
leaf label {
type rt-types:mpls-label;
Thanks,
Acee
From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
<[email protected]<mailto:[email protected]>>
Date: Monday, July 17, 2017 at 8:51 AM
To: Acee Lindem <[email protected]<mailto:[email protected]>>, "Tarek Saad (tsaad)"
<[email protected]<mailto:[email protected]>>, Jeff Haas
<[email protected]<mailto:[email protected]>>, Xufeng Liu
<[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
Routing WG <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: MPLS label and LSE data models
Hi,
Just as a point of reference, for VLAN tag stacks, the outermost VLAN tag is
always first in the list.
Regarding relax the ordering or not, I may not be answering exactly the same
question, but I would say that you want a have a canonical order (to allow for
easy and efficient comparison), and forcing everyone to have to sort the label
stack before using it would probably just be regarded as a wart.
Thanks,
Rob
On 14/07/2017 22:31, Acee Lindem (acee) wrote:
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).
Thanks,
Acee
From: "Tarek Saad (tsaad)" <[email protected]<mailto:[email protected]>>
Date: Thursday, July 13, 2017 at 1:12 PM
To: Jeff Haas <[email protected]<mailto:[email protected]>>, Xufeng Liu
<[email protected]<mailto:[email protected]>>
Cc: Greg Mirsky <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
Routing WG <[email protected]<mailto:[email protected]>>
Subject: Re: MPLS label and LSE data models
Resent-From: <[email protected]<mailto:[email protected]>>
Resent-To: <[email protected]<mailto:[email protected]>>, Yingzhen Qu
<[email protected]<mailto:[email protected]>>, Acee Lindem
<[email protected]<mailto:[email protected]>>, Christian Hopps
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>
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).
Regards,
Tarek
-----Original Message-----
From: Jeffrey Haas <[email protected]<mailto:[email protected]>>
Date: Thursday, July 13, 2017 at 12:51 PM
To: Xufeng Liu <[email protected]<mailto:[email protected]>>
Cc: Greg Mirsky <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: MPLS label and LSE data models
Resent-From: <[email protected]<mailto:[email protected]>>
Resent-To: Tarek Saad <[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>
Resent-Date: Thursday, July 13, 2017 at 12:42 PM
Xufeng,
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
_______________________________________________
rtgwg mailing list
[email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
