Subject: Re: MPLS label and LSE data models

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Jul 2017 16:21:02 -0400

Xufeng,

I see that draft-ietf-mpls-static-yang-04 was issued.  My comment is against
that version now.

On Thu, Jun 22, 2017 at 03:44:28PM +0000, Xufeng Liu wrote:
> > 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.

I see that you changed things to use a constrained index range with id 0
being special for top of stack.

So, if you have labels with indexes 0, 5, 10, 15, then 15 would be the
bottom of stack?

-- Jeff

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 13 Jul 2017 16:14:18 +0000

Hi Jeff,

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.

Best,
- Xufeng

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Monday, July 10, 2017 4:21 PM
> To: Xufeng Liu <[email-masked]>
> Cc: Greg Mirsky <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: MPLS label and LSE data models
> 
> Xufeng,
> 
> I see that draft-ietf-mpls-static-yang-04 was issued.  My comment is against that
> version now.
> 
> > > 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.
> 
> I see that you changed things to use a constrained index range with id 0 being
> special for top of stack.
> 
> So, if you have labels with indexes 0, 5, 10, 15, then 15 would be the bottom of
> stack?
> 
> -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jul 2017 12:51:40 -0400

Xufeng,

> 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

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 13 Jul 2017 17:12:39 +0000

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-masked]>

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

Cc: Greg Mirsky <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Resent-From: <[email-masked]>

Resent-To: Tarek Saad <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

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

    Xufeng,

    -- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 13 Jul 2017 18:44:50 +0000

Hi Tarek,

Can you provide a modified mols-label-stack grouping with your proposal?

Thanks,
Acee

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

Hi Jeff and Xufeng,

Regards,

Tarek

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

From: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>

To: Xufeng Liu <[email-masked]<mailto:[email-masked]>>

Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Resent-From: <[email-masked]<mailto:[email-masked]>>

Resent-To: Tarek Saad <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

    Xufeng,

    -- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 14 Jul 2017 20:31:25 +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).

Thanks,
Acee

Hi Jeff and Xufeng,

Regards,

Tarek

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

    Xufeng,

    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Jul 2017 04:42:50 -0400

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 17 Jul 2017 14:51:24 +0200

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???
>
> 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-masked] <mailto:[email-masked]>>
> To: Jeff Haas <[email-masked] <mailto:[email-masked]>>, Xufeng Liu 
> <[email-masked] <mailto:[email-masked]>>
> Cc: Greg Mirsky <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, Routing WG 
> <[email-masked] <mailto:[email-masked]>>
> Resent-From: <[email-masked] <mailto:[email-masked]>>
> Resent-To: <[email-masked] <mailto:[email-masked]>>, 
> Yingzhen Qu <[email-masked] <mailto:[email-masked]>>, 
> Acee Lindem <[email-masked] <mailto:[email-masked]>>, Christian Hopps 
> <[email-masked] <mailto:[email-masked]>>, <[email-masked] 
> <mailto:[email-masked]>>
>     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
>
>     From: Jeffrey Haas <[email-masked] <mailto:[email-masked]>>
>
>     To: Xufeng Liu <[email-masked] <mailto:[email-masked]>>
>
>     Cc: Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>
>     Resent-From: <[email-masked] <mailto:[email-masked]>>
>
>     Resent-To: Tarek Saad <[email-masked] <mailto:[email-masked]>>,
>     <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>
>
>         > 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.
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Jul 2017 16:47:06 +0000

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-masked]<mailto:[email-masked]>>
Date: Monday, July 17, 2017 at 8:51 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>, Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Thanks,
Acee

Hi Jeff and Xufeng,

Regards,

Tarek

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

    Xufeng,

    -- Jeff

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/rtgwg