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

Tarek Saad <tsaad.net@gmail.com> Tue, 25 February 2020 14:58 UTC

Return-Path: <tsaad.net@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 986BA3A0E51; Tue, 25 Feb 2020 06:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 jdzfAoB_vLDW; Tue, 25 Feb 2020 06:58:25 -0800 (PST)
Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 82F3D3A0E62; Tue, 25 Feb 2020 06:58:24 -0800 (PST)
Received: by mail-yw1-xc34.google.com with SMTP id 192so8038669ywy.0; Tue, 25 Feb 2020 06:58:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 MN2PR19MB3167.namprd19.prod.outlook.com ([2603:1036:302:409e::5]) by smtp.gmail.com with ESMTPSA id l191sm1358632ywb.12.2020.02.25.06.58.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 06:58:22 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: tom petch <ietfc@btconnect.com>, Tarek Saad <tsaad@juniper.net>, Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
CC: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
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: <MN2PR19MB3167440FC2AE2F1920F84DECFCED0@MN2PR19MB3167.namprd19.prod.outlook.com>
References: <DB7PR07MB5657A0BC6BA671CB6D3B9029A0ED0@DB7PR07MB5657.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB5657A0BC6BA671CB6D3B9029A0ED0@DB7PR07MB5657.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/KI5tO-TTB4tHmnoLhcCgzcAmWy4>
Subject: Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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, 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.

Regards,
Tarek

On 2/25/20, 7:31 AM, "tom petch" <ietfc@btconnect.com> wrote:

    
    
    ________________________________________
    From: mpls <mpls-bounces@ietf.org> on behalf of tom petch <ietfc@btconnect.com>
    Sent: 21 February 2020 16:30
    To: Tarek Saad; Loa Andersson; mpls@ietf.org
    Cc: mpls-chairs@ietf.org; draft-ietf-mpls-base-yang@ietf.org
    Subject: Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang
    
    Tarek
    
    progressing ... <tp> inline
    
    ________________________________________
    From: Tarek Saad <tsaad@juniper.net>
    Sent: 19 February 2020 06:00
    
    Thanks much for your review and useful comments. We have posted a new revision -12 at https://tools.ietf.org/html/draft-ietf-mpls-base-yang-12 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" <ietfc@btconnect.com> wrote:
    
    Some more technical thoughts on this I-D
    
            Abstract
    
            LSP is not in the RFC Editor list of 'so well known ...'
    [TS]: it is listed at https://www.rfc-editor.org/materials/abbrev.expansion.txt
    
    <tp> as Acee points out, it lacks the asterisk that says that no expansion is needed :-(
    
            s.2.1
               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;
            description
              "This identity represents the MPLS address family.";
      }
            s.2.2
               interfaces-mpls:
                      A YANG grouping that describes the list of MPLS enabled interfaces
                      on a device.
    
               label-blocks:
                      A YANG grouping that describes the list of MPLS enabled interfaces
                      on a device.
    
            um?
    [TS]: we corrected the description. See below:
    NEW:
    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;
                      description
                       "'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
    </tp>
    
              grouping interfaces-mpls {    description "List of MPLS interfaces";
                    list interface {   key "name";  description "List of MPLS
            interfaces";
                      leaf name {   type if:interface-ref;
                            description   "The name of a configured MPLS interface";
    
            no conditional so every RIP or dial up X.25 e.g.is 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" {
                    description
                      "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.
    
    Regards,
    Tarek
    
            Tom Petch
    
    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls