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 <xufeng_...@jabil.com> 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:gregimir...@gmail.com]
> *Sent:* Monday, June 5, 2017 8:44 PM
> *To:* Acee Lindem (acee) <a...@cisco.com>
> *Cc:* draft-ietf-rtgwg-routing-ty...@ietf.org;
> draft-ietf-mpls-static-y...@ietf.org; rtgwg@ietf.org; m...@ietf.org
> *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) <a...@cisco.com> wrote:
>
> Greg, et al,
>
>
>
> *From: *Greg Mirsky <gregimir...@gmail.com>
> *Date: *Monday, June 5, 2017 at 6:28 PM
> *To: *"draft-ietf-rtgwg-routing-ty...@ietf.org" <draft-ietf-rtgwg-routing-
> ty...@ietf.org>, "draft-ietf-mpls-static-y...@ietf.org" <
> draft-ietf-mpls-static-y...@ietf.org>
> *Cc: *Routing WG <rtgwg@ietf.org>, "m...@ietf.org" <m...@ietf.org>
> *Subject: *MPLS label and LSE data models
> *Resent-From: *<alias-boun...@ietf.org>
> *Resent-To: *Yingzhen Qu <yingzhen...@huawei.com>, <xufeng_...@jabil.com>,
> Acee Lindem <a...@cisco.com>, Christian Hopps <cho...@chopps.org>, <
> lber...@labn.net>
> *Resent-Date: *Monday, June 5, 2017 at 6:28 PM
>
>
>
> 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.
>
> 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
>
>
>
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to