Re: [mpls] MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03

"Kamran Raza (skraza)" <> Mon, 27 June 2016 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41CE812B031; Sun, 26 Jun 2016 17:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q6zl_9z9ZRqR; Sun, 26 Jun 2016 17:01:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF6F712B01C; Sun, 26 Jun 2016 17:01:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=44589; q=dns/txt; s=iport; t=1466985705; x=1468195305; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sqi4rqyyz6OTGPP1PupV+VE30qN6JZwiUyzh77rAViw=; b=PzZL60p1CEI72C4PDmz2D8FqjL4Zda0zUX2GXLZ8ernrU1ezehPpKfxr dZCsCsVNW9QD5UWSJJAXT35ss36VVNO+CkQKngASgn1p9AMLQ0EdGS8PS p4G9L0kWpDaoKuTAzWyaVjvIJhPVHqWD6yKlyI/Bwe0XiI8usZj4Co1fs 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.26,534,1459814400"; d="scan'208,217";a="288822618"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2016 00:01:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u5R01i9B023665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 00:01:44 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 26 Jun 2016 19:01:43 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sun, 26 Jun 2016 19:01:43 -0500
From: "Kamran Raza (skraza)" <>
To: "Tarek Saad (tsaad)" <>, "Reshad Rahman (rrahman)" <>, "Rajiv Asati (rajiva)" <>, "" <>, "" <>, "" <>, Santosh Esale <>, "" <>, Loa Andersson <>, "" <>, "Bocci, Matthew (Matthew)" <>, "" <>, "Sowmya Krishnaswamy (sowkrish)" <>, "Danial Johari (dajohari)" <>
Thread-Topic: MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03
Thread-Index: AdG3bLXTtn0B3RvFQBm5DUcAqBi2yQSGjCkAAaIjYwA=
Date: Mon, 27 Jun 2016 00:01:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D395E2EC121F84skrazaciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [mpls] MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2016 00:01:49 -0000

Hi Tarek,

Thanks for your comments. Please see inline [skraza]:

From: "Tarek Saad (tsaad)" <<>>
Date: Saturday, June 18, 2016 at 1:30 PM
To: Syed Kamran Raza <<>>, "Reshad Rahman (rrahman)" <<>>, "Rajiv Asati (rajiva)" <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>, Santosh Esale <<>>, "<>" <<>>, Loa Andersson <<>>, "<>" <<>>, "Bocci, Matthew (Matthew)" <<>>, "<>" <<>>, "Sowmya Krishnaswamy (sowkrish)" <<>>, "Danial Johari (dajohari)" <<>>
Cc: "<>" <<>>, "<>" <<>>, "Tarek Saad (tsaad)" <<>>
Subject: Re: MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03

Hi co-authors,

I have reviewed the version of draft “draft-raza-mpls-ldp-mldp-yang-03”. This draft is useful as it describes a data model that allows operating and managing widely deployed MPLS LDP and MLDP protocols. I think it is at a good starting point to be adopted by the WG.
My comments are below and can wait until the document is a working group document and the working group has the revision control.

General comments:

·         You use of if-feature checks in this model. One feedback from the operators was to possibly split a model into a “base” and “extended” parts- with the “base” part to contain mandatory data nodes that all vendors are expected to support and hence would not have any if-feature check. The “extended” model would contain additional features that can be if-feature checked. I’ll leave it up to you to consider this approach.

[skraza]: We discussed this in our weekly meeting and we will revisit this in later rev.

·         You are defining MLDP and LDP in same model. You may want to consider having MLDP model (either in a submodule that can included in the ldp module) or a separate module that imports LDP and augments it.

[skraza]: mLDP is tightly coupled with LDP and this decision (of having a joint model) was made in one of our earliest arch/design meetings. We had also sought WG direction on this during our 1st presentation and WG had also advised to have a common/combined model.

·         Since the model is hanging down from mpls, it is ok to drop the “mpls” from all leaf names (e.g. s/mpls-ldp/ldp)
[skraza]: Sure.

Section 3.1:
>>   o  Read-Write parameters for configuration (Discussed in Section 3.2)
[TS]: the model in I-D.openconfig-netmod-opstate suggests having read-only leaves for applied configuration items hanging down the same branch
[skraza]: Yes, we are waiting for open cfg opstate model/discussions to settle in netmod/rtg area and will align our model later accordingly.

Section 3.2:
>> augment /rt:routing/rt:routing-instance/mpls:mpls:
[TS]: the above path has changed in draft-ietf-netmod-routing-cfg-21 and rt:routing-instance is not longer there. You’ll need to make the necessary changes
[skraza]: Yes, we are aware and this is on our TODO list for next rev.

>> The "interfaces" is a container to configure parameters related to  VRF interfaces.
[TS]: you seem to be creating a separate “interfaces” container and list (and adding checks for example to ensure ipv4 is enabled). To ensure MPLS is enabled, you’d need to do the same. Or alternatively, you could augment the MPLS enabled interfaces listed in MPLS-BASE model?
[skraza]: Right, we had indicated in our Yokohama presentation that we will align with mpls-base. We missed it in our prev rev but will fix it in next. Thx.

>> typedef address-family
[TS]: rfc6991 defines “ip-version” data-type- which is similar to the type you’re defining. You may want to use that instead.
 [skraza]: We got the same comment from other reviewer and will address it.

>> You are defining several data-types as enums. You may want to consider identities for types you think may be extended by other modules.
 [skraza]: Ok, we will evaluate for later rev.

>> oper-status-event-type
Is this specific to events? not applicable to state?
[skraza]: Yes.

>> use of defaults (e.g. hello-interval, etc.) – unless dictated by standard may not be favorable.. You may want to consider leaving it flexible and allow vendor backend to apply their internal default.
[skraza]: Agree. The team had discussed the default a bit but we have not fully closed on all. Will update in later rev.

>> use of “presence” keyword to enable functions. From feedback, having explicit “enable” leaf was more favorable (avoids issues
[skraza]: Ok, will rework.

>>      +--ro label?                uint32
[TS]: please consider using mpls:mpls-label instead in similar occurrence
 [skraza]:  Sure.


From: Ross Callon <<>>
Date: Thursday, May 26, 2016 at 12:36 PM
To: "'Bert (IETF) Wijnen'" <<>>, Mach Chen <<>>, Tarek Saad <<>>, Minto Jeyananth <<>>
Cc: "<>" <<>>, "Kamran Raza (skraza)" <<>>, "Reshad Rahman (rrahman)" <<>>, "Rajiv Asati (rajiva)" <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>, Santosh Esale <<>>, "<>" <<>>, Loa Andersson <<>>, "<>" <<>>, "Bocci, Matthew (Matthew)" <<>>, "<>" <<>>, "Sowmya Krishnaswamy (sowkrish)" <<>>, "Danial Johari (dajohari)" <<>>
Subject: MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03

Bert, Mach, Tarek, Minto;

You have be selected as MPLS review team reviewers for draft-raza-mpls-ldp-mldp-yang-03.

Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own

Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational networks), and is
the document technically sound?  We are interested in knowing whether
the document is ready to be considered for WG adoption (ie, it doesn't
have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
needs to be resolved before adopting it as a working group document, and
what can wait until the document is a working group document and the
working group has the revision control.

Because of the size of the document we will increase the review time to three
weeks. Are you able to review this draft by Friday June 17, 2016? Please respond
in a timely fashion.

Thanks, Ross
(as MPLS WG chair)