Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang

Tarek Saad <> Tue, 25 February 2020 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 986BA3A0E51; Tue, 25 Feb 2020 06:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jdzfAoB_vLDW; Tue, 25 Feb 2020 06:58:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82F3D3A0E62; Tue, 25 Feb 2020 06:58:24 -0800 (PST)
Received: by with SMTP id 192so8038669ywy.0; Tue, 25 Feb 2020 06:58:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=H6qh0e1z13m2rSd332i4KZBWI4JpskFv9EZjRUGTAAE=; b=hLiyOSk9IO3W96UDvAPXHwMsfoMZDTPKOrJnenCi94NXKqiWjP3Hs/sPDOF9fKDpPh 0XhB3f1WQc8biwDjHSZUwp2J9HGlLlR0lQW93ORhDhyD8GIxx3sX7msMqC60EiTqnNhC tMSkXWiagU0SxqQ9KADlaaDAGwtRABhPpJBT47bFH03mIEL9BZro/28Q2qrGjb0N6Rby bwuJ+6u7gSPnRoj90kqojQSrvm1/JrWmv/buHCzE0UI86bP5XNlvfm1vF0FUr/CIcS1s WO4aEGDN8MrMu83PJl3UgBGwt7Re+3kPezPCCPzJkgz/Z+S4ytKey4hxV5Bvi4oTDJqZ 3HVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=H6qh0e1z13m2rSd332i4KZBWI4JpskFv9EZjRUGTAAE=; b=qsd+f4hRPAAoy3LIL/ljn3CuGJCxfF5SB6+w0CFOwLJg30T819nXZbJ5MGrJ7OYQYF HiFlczwOa7dm5zacWWVd2d4/dBjd50t5xROqiXDzYzI1iQTAcSXkDfiun2dnVy89VshT QTT+1ZO8C5up8EIPCzMtBKwX2pgCKd97HcvOBj6xTlQVsE2+CuAGG7p0m0kPvjhaBp2Q UFn/vYxESTOO35Y9gfbxAdFGJR+1Mr+35NNTxVHfqkPEluAjWWFmjzzaxewT5mEF3kQ9 5t2M/5F1JkJ+MwGRjMD0GCqrNyQVjno7vsdfCI9LCPe1Vp0J6l8eFRAm/CkPM5UEaFsX +PIw==
X-Gm-Message-State: APjAAAV54ALcTOX1TtZE1itO8So+IplWeX7MFHexLhgGTVB5t6iAkY01 jtvzks1mnjg6vGZS1T+Ij6g=
X-Google-Smtp-Source: APXvYqxdZZyhnanmZhnKYbkyKEeIPot8j6y3vlPMLnMZnmtbPUmg8sNwxW9zDNz9yCKxhlXH7pmPZA==
X-Received: by 2002:a81:8584:: with SMTP id v126mr45898309ywf.332.1582642703365; Tue, 25 Feb 2020 06:58:23 -0800 (PST)
Received: from ([2603:1036:302:409e::5]) by with ESMTPSA id l191sm1358632ywb.12.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 06:58:22 -0800 (PST)
From: Tarek Saad <>
To: tom petch <>, Tarek Saad <>, Loa Andersson <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [mpls] MPLS wglc draft-ietf-mpls-base-yang
Thread-Index: ATAwQ0M1CwmeoiXghZF60eDLJMtyKct3UYM+
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 25 Feb 2020 14:58:21 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2020 14:58:28 -0000

Hi Tom,

Thanks again for the feedback. We are looking into it and will respond on the thread soon.


On 2/25/20, 7:31 AM, "tom petch" <> wrote:

    From: mpls <> on behalf of tom petch <>
    Sent: 21 February 2020 16:30
    To: Tarek Saad; Loa Andersson;
    Subject: Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang
    progressing ... <tp> inline
    From: Tarek Saad <>
    Sent: 19 February 2020 06:00
    Thanks much for your review and useful comments. We have posted a new revision -12 at that addresses those. Let us know if you have further comments.
    Also, see inline for responses on closure.
    On 1/21/20, 7:38 AM, "tom petch" <> wrote:
    Some more technical thoughts on this I-D
            LSP is not in the RFC Editor list of 'so well known ...'
    [TS]: it is listed at
    <tp> as Acee points out, it lacks the asterisk that says that no expansion is needed :-(
               The other MPLS route(s) that are non-IP prefix routes are modelled by
               introducing a new "mpls" address-family RIB as per recommendation .
            Where is that?
    <tp> I was looking for a reference for the recommendation - is this the routing RFC, RFC8349 s.5.2?
    [TS]: Please refer to identity below defined in the model which has rt:address-family as base.
      identity mpls {
            base rt:address-family;
              "This identity represents the MPLS address family.";
                      A YANG grouping that describes the list of MPLS enabled interfaces
                      on a device.
                      A YANG grouping that describes the list of MPLS enabled interfaces
                      on a device.
    [TS]: we corrected the description. See below:
    A YANG grouping that describes the list of assigned MPLS label blocks and its properties.
            YANG Module
                     Copyright (c) 2018 IETF Trust
                    leaf loadshare {
            I  would  value a reference for this.
    [TS]: rfc3031 section 3.11 and  3.12.
    <TP>  well sort of; those sections talk about sharing across equal cost paths which seems somewhat simpler - I understand the YANG DESCRIPTION but would expect it to be described in an RFC somewhere.
              grouping interface-mpls-properties {
                      type boolean;
                       "'true' if mpls encapsulation is enabled on the interface.
                       'false' if mpls encapsulation is enabled  on the interface.";
    <tp> so true means enabled and false means ..  enabled ; clear but logical?
                    leaf mtu {  type uint32; description
                            "MPLS Maximum Transmission Unit (MTU) in bytes";
            um what is included in MTU here  c.f.draft-ietf-netmod-intf-ext-yang-07
            which  includes L2 header but not FCS in Layer 2 MTU;
            a reference might help
    [TS]: includes L2 MTU + maximum MPLS label stack size. rfc3032 section 3.2.
    <tp> well no; MTU does not appear in RFC3032 s.3.1; other terminology does and I want to map the terminology of this I-D - MTU- to the terminology of s.3.1
    That is all
    Tom Petch
              grouping interfaces-mpls {    description "List of MPLS interfaces";
                    list interface {   key "name";  description "List of MPLS
                      leaf name {   type if:interface-ref;
                            description   "The name of a configured MPLS interface";
            no conditional so every RIP or dial up X.25 going to get this:-( probably ok
              augment "/rt:routing" {
            ditto, although probably less significant
    [TS]: added feature mpls, and added if-feature check under the augmentations.
              augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
                            + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
                      "Augment 'simple-next-hop' case in IP unicast routes.";
            other I-D augment control plane/protocols/static-routes
    [TS]: the MPLS Static model is a separate model that is described in draft-ietf-mpls-static-yang.
            Tom Petch
    mpls mailing list