Subject: [mpls] MPLS label and LSE data models

From: Greg Mirsky <[email-masked]>
Date: Mon, 5 Jun 2017 15:28:05 -0700

Dear Authors, et.al,
I've got a question, or several of them, about data models of MPLS label
and MPLS label stack element (LSE). I ahve not followed the discussions and
apologize if these already were considered, discussed.
In the Routing Types document I've found that only MPLS label being modeled
but not the MPLS LSE. As result, models that use rt-types:mpls-label, e.g.
YANG DAta Model for MPLS Static LSPs, defines outgoing labels not as array
of LSEs but as array (leaf-list) of MPLS labels. In the latter document I
don't see how TTL and Traffic Class (TC) are presented for each of labels
in the array. Hence my questions:

   - should there be data model of MPLS LSE in rt-types (it does have TTL
   and TC but separately);
   - should data model of Static MPLS LSP use MPLS LSE model rather than
   model of only 20 bit-long label.

Appreciate you comments.

Regards,
Greg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 5 Jun 2017 23:55:57 +0000

Greg, et al,

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 5, 2017 at 6:28 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: MPLS label and LSE data models
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Yingzhen Qu <[email-masked]<mailto:[email-masked]>>, <[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: Monday, June 5, 2017 at 6:28 PM

Dear Authors, et.al<http://et.al>,
I've got a question, or several of them, about data models of MPLS label and MPLS label stack element (LSE). I ahve not followed the discussions and apologize if these already were considered, discussed.
In the Routing Types document I've found that only MPLS label being modeled but not the MPLS LSE. As result, models that use rt-types:mpls-label, e.g. YANG DAta Model for MPLS Static LSPs, defines outgoing labels not as array of LSEs but as array (leaf-list) of MPLS labels. In the latter document I don't see how TTL and Traffic Class (TC) are presented for each of labels in the array. Hence my questions:

  *   should there be data model of MPLS LSE in rt-types (it does have TTL and TC but separately);

  *   should data model of Static MPLS LSP use MPLS LSE model rather than model of only 20 bit-long label.

Where else so you see  a requirement for a label stack with entries that don’t contain TC and TTL? This seems specific to static provisioning of static LSPs rather than a general requirement for ietf-routing-types.

Thanks,
Acee

Appreciate you comments.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 5 Jun 2017 17:43:39 -0700

Hi Acee,
I think rather of the contrary, Static MPLS LSP must include TC and TTL.
And Bottom-of-the-stack flag as well (I don't see it in grouping
mpls-label-stack
of the ietf-routing-types).

Regards,
Greg

On Mon, Jun 5, 2017 at 4:55 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Greg, et al,
>
> From: Greg Mirsky <[email-masked]>
> To: "[email-masked]" <draft-ietf-rtgwg-routing-
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: Routing WG <[email-masked]>, "[email-masked]" <[email-masked]>
> Resent-From: <[email-masked]>
> Resent-To: Yingzhen Qu <[email-masked]>, <[email-masked]>,
> Acee Lindem <[email-masked]>, Christian Hopps <[email-masked]>, <
> [email-masked]>
> In the Routing Types document I've found that only MPLS label being
> modeled but not the MPLS LSE. As result, models that use
> rt-types:mpls-label, e.g. YANG DAta Model for MPLS Static LSPs, defines
> outgoing labels not as array of LSEs but as array (leaf-list) of MPLS
> labels. In the latter document I don't see how TTL and Traffic Class (TC)
> are presented for each of labels in the array. Hence my questions:
>
> Where else so you see  a requirement for a label stack with entries that
> don’t contain TC and TTL? This seems specific to static provisioning of
> static LSPs rather than a general requirement for ietf-routing-types.
>
> Thanks,
> Acee
>
>
> Appreciate you comments.
>
> Regards,
> Greg
>
>

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 6 Jun 2017 15:05:57 +0000

Hi Greg,

  1.  As you mentioned, grouping mpls-label-stack is defined in routing-types, so MPLS LSE is covered, right?
  2.  Bottom-of-the-stack flag should not be needed in the model,  because the label stack is a list with sequence ID’s, which tell us the beginning and the end of the stack.
  3.  The discussion on static MPLS LSP has started, but not converged yet. There are still open issues w.r.t. how to model the label stack and stack operations. Any suggestions would be appreciated. Do you have a proposal?
Thanks,
- Xufeng

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, June 5, 2017 8:44 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: MPLS label and LSE data models

Hi Acee,
I think rather of the contrary, Static MPLS LSP must include TC and TTL. And Bottom-of-the-stack flag as well (I don't see it in grouping mpls-label-stack of the ietf-routing-types).

Regards,
Greg

On Mon, Jun 5, 2017 at 4:55 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Greg, et al,

Thanks,
Acee

Appreciate you comments.

Regards,
Greg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 6 Jun 2017 15:10:26 +0000

Hi Greg,

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 5, 2017 at 8:43 PM
To: Acee Lindem <[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 Acee,

I just looked at a couple implementations and they do not include per-label provisioning of the traffic class and TTL. One would certainly NOT want to provision bottom of stack. Even if you put it in the rightmost label, other routes which are already labeled could resolve over the static LSP.

As far as adding a separate leaf list for the mpls-label type, I don’t think this is necessary as adding a type just to abstract a YANG list just adds complexity.

Anyway, I’m deferring to the authors of the MPLS static model if they desire any additional types in ietf-routing-types.

Thanks,
Acee

Regards,
Greg

Thanks,
Acee

Appreciate you comments.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 6 Jun 2017 11:55:59 -0700

Hi Xufeng,
thank you for helping me with your insight. I have couple follow-up
questions:

   - 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;
   - if we agree that the mpls-label-stack is ordered list, then figuring
   out which LSE should have BoS set is indeed benign and may not require to
   be explicit;
   - as for Static MPLS LSP I propose:
      - no need to have outgoing_label and outgoing_labels as the former is
      special case of the latter;
      - consider whether to use rt-type:mpls-label-stack rather than
      rt-type:mpls-label. It gets tricky on transit nodes but we, it
seems to me,
      need operations on TTL and TC being explicit on ingress.

Regards,
Greg

On Tue, Jun 6, 2017 at 8:05 AM, Xufeng Liu <[email-masked]> wrote:

> Hi Greg,
>
>
>
>    1. As you mentioned, grouping mpls-label-stack is defined in
>    routing-types, so MPLS LSE is covered, right?
>    2. Bottom-of-the-stack flag should not be needed in the model,
>    because the label stack is a list with sequence ID’s, which tell us the
>    beginning and the end of the stack.
>    3. The discussion on static MPLS LSP has started, but not converged
>    yet. There are still open issues w.r.t. how to model the label stack and
>    stack operations. Any suggestions would be appreciated. Do you have a
>    proposal?
>
> Thanks,
>
> - Xufeng
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Monday, June 5, 2017 8:44 PM
> *To:* Acee Lindem (acee) <[email-masked]>
> *Cc:* [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: MPLS label and LSE data models
>
>
>
> Hi Acee,
>
> And Bottom-of-the-stack flag as well (I don't see it in grouping mpls-label-stack
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, June 5, 2017 at 6:28 PM
> *To: *"[email-masked]" <draft-ietf-rtgwg-routing-
> *Cc: *Routing WG <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *MPLS label and LSE data models
> *Resent-From: *<[email-masked]>
> *Resent-To: *Yingzhen Qu <[email-masked]>, <[email-masked]>,
> *Resent-Date: *Monday, June 5, 2017 at 6:28 PM
>
>
>
> Dear Authors, et.al,
>

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 6 Jun 2017 19:33:05 +0000

Hi Greg,

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, June 6, 2017 2:56 PM
To: Xufeng Liu <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: MPLS label and LSE data models

Hi Xufeng,
thank you for helping me with your insight. I have couple follow-up questions:

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

  *   if we agree that the mpls-label-stack is ordered list, then figuring out which LSE should have BoS set is indeed benign and may not require to be explicit;
  *   as for Static MPLS LSP I propose:

     *   no need to have outgoing_label and outgoing_labels as the former is special case of the latter;
     *   consider whether to use rt-type:mpls-label-stack rather than rt-type:mpls-label. It gets tricky on transit nodes but we, it seems to me, need operations on TTL and TC being explicit on ingress.
[Xufeng] Thanks for your suggestion. Will pass to the discussion.
Regards,
Greg

On Tue, Jun 6, 2017 at 8:05 AM, Xufeng Liu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 5, 2017 8:44 PM
To: Acee Lindem (acee) <[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]>
Subject: Re: MPLS label and LSE data models

Hi Acee,

Regards,
Greg

Thanks,
Acee

Appreciate you comments.

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 Jun 2017 16:50:21 -0400

Xufeng,

> [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…

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.

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.

-- Jeff

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 22 Jun 2017 15:44:28 +0000

Hi Jeff,

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2017 4:50 PM
> Cc: Greg Mirsky <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> >   *   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