Re: [mpls] MPLS label and LSE data models

Greg Mirsky <gregimirsky@gmail.com> Tue, 06 June 2017 18:56 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A690C1252BA; Tue, 6 Jun 2017 11:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AevMIX3Osptv; Tue, 6 Jun 2017 11:56:01 -0700 (PDT)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E195129411; Tue, 6 Jun 2017 11:56:00 -0700 (PDT)
Received: by mail-ot0-x22d.google.com with SMTP id k4so20828321otd.0; Tue, 06 Jun 2017 11:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ajN28NSW2B8pk08KSStUur7frn1y1t68KZxIs65Ik98=; b=VLWrK+1rjrdWo5lgNwBrbIDOuHjkHXRSkT8O1a7BFX7j0JBq+1DtD0aDcV1J4wJCxx sgIw1OY5AVQpcKHrsMhhypzLbmzUXt833Dag5KIEv+xM+AaECK3yzRdfktJ21RUdlPks Wv0NJdU2vR869+E0CTHvE7MwkZHVxZ3tq56hrS0tDS8UIeuQMjLE6pP/5wzFd/SISdeP W0kAXHQ1mxYFDF3S1tyRhv1+J/cNyLv4TOdNmydqbXjpE6b+vhYJFxOVxcWSXssULDtX sCN382DAtoMQlXFRbzw+fAiYHngXw2rpm/VXnt0kl6+TMVN0Lr9u8YfuapxHkZxMJEY+ 0DSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ajN28NSW2B8pk08KSStUur7frn1y1t68KZxIs65Ik98=; b=MNuIM2wTFnCw9F7JnLbS4CTQ54Iy/waYc+PptjWN+WUOjaIC9QMVsubKoG7Koswo3B 5xy37yaAU138ZoPBjaKfHNO2f/qzZRsLlio2BRmRr27Pssfa/gdF0TQYLZj3XkhXfW3n n2NxMUoMhmzyz47zCb5n2p8CZafejHtd7lkkGfQTxpaJHsvzYgbgnL13UCumUUXxzUaA vMIf19q4PAPt6nIoLQINrLHXVdvNRkOqcwqjfHMgGLwiTN87hEB22BUXtDKnzSD78eWn 7RMuX0RSte0UVJPDMspzaUy2ej/2WFn2XDCDL6pnkWrzm0eKbY6wbmLM3wbltiQSmofS ylUQ==
X-Gm-Message-State: AODbwcA0B86XRyzcp008wKT2v25a/+Uw0mjfq3pVbcHZ3i8onUdiCzbz 2i6Fb2cLEpUmHisOw1NVceKJX/b9Wg==
X-Received: by 10.157.52.221 with SMTP id t29mr15682691otd.0.1496775359481; Tue, 06 Jun 2017 11:55:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.225 with HTTP; Tue, 6 Jun 2017 11:55:59 -0700 (PDT)
In-Reply-To: <BN3PR0201MB08676A90584EC7E8414244B3F1CB0@BN3PR0201MB0867.namprd02.prod.outlook.com>
References: <CA+RyBmVH=KCi3T8u2dB_WaKBOLheYwT4q0d+tpYdT-Z2iTZ+og@mail.gmail.com> <D55B6659.B21B8%acee@cisco.com> <CA+RyBmVyHKGhxitGgQ6RRMmHKwvs=b_GkKMq80rE=Ys8WetGaQ@mail.gmail.com> <BN3PR0201MB08676A90584EC7E8414244B3F1CB0@BN3PR0201MB0867.namprd02.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 06 Jun 2017 11:55:59 -0700
Message-ID: <CA+RyBmWHvfXt_Vdhc5w70ugQTSS5qffTWbQ+Lb9D_6PpfP10QQ@mail.gmail.com>
To: Xufeng Liu <Xufeng_Liu@jabil.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-rtgwg-routing-types@ietf.org" <draft-ietf-rtgwg-routing-types@ietf.org>, "draft-ietf-mpls-static-yang@ietf.org" <draft-ietf-mpls-static-yang@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114055529c4bd605514f2b8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/xXb29qIwTKFYyX5wO0UIMhoeRQ0>
Subject: Re: [mpls] MPLS label and LSE data models
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2017 18:56:11 -0000

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_Liu@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:gregimirsky@gmail.com]
> *Sent:* Monday, June 5, 2017 8:44 PM
> *To:* Acee Lindem (acee) <acee@cisco.com>
> *Cc:* draft-ietf-rtgwg-routing-types@ietf.org;
> draft-ietf-mpls-static-yang@ietf.org; rtgwg@ietf.org; mpls@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) <acee@cisco.com> wrote:
>
> Greg, et al,
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>
> *Date: *Monday, June 5, 2017 at 6:28 PM
> *To: *"draft-ietf-rtgwg-routing-types@ietf.org" <draft-ietf-rtgwg-routing-
> types@ietf.org>, "draft-ietf-mpls-static-yang@ietf.org" <
> draft-ietf-mpls-static-yang@ietf.org>
> *Cc: *Routing WG <rtgwg@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
> *Subject: *MPLS label and LSE data models
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *Yingzhen Qu <yingzhen.qu@huawei.com>, <xufeng_liu@jabil.com>,
> Acee Lindem <acee@cisco.com>, Christian Hopps <chopps@chopps.org>, <
> lberger@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
>
>
>