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

"Tarek Saad (tsaad)" <> Sat, 18 June 2016 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77BBB12D7CB; Sat, 18 Jun 2016 10:30:24 -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 I3ic52nrKgCv; Sat, 18 Jun 2016 10:30:21 -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 6DC0512D7C6; Sat, 18 Jun 2016 10:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=32728; q=dns/txt; s=iport; t=1466271021; x=1467480621; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QILhOu79mZzXyjdKLWnnjWRc+Nzp9wAehm011yZDU5w=; b=G2uDljHa8fKhXf77rac2+hER+hlSCI/I/iWqPP8uC3ycVDhteek3Alim nmu7YqgW+yfIvD+GhBdth5YMTOnznc8ZPNNVAiv/+zdgThWzcHHI+kZls G2ee53kG7DM0SmPvWwraogYVz/mJYstxcsohw/f44hTbltTiMOGWQeoEi 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQCXhGVX/5BdJa1dgnBOVn0GrlqJc?= =?us-ascii?q?4IPgXqGFwIcgQM4FAEBAQEBAQFlJ4RLAQEBAwEjCkwQAgEIEQMBAiEKAgICHxE?= =?us-ascii?q?dCAEBBAENBYgWAw8Ir1eMKg2DXgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4F3g?= =?us-ascii?q?laCQ4FPEQE8gmErgi8Fk0iEejQBjC+BeoFphFKDLYU6iAqHbAEeNoNwbokTNn8?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.26,487,1459814400"; d="scan'208,217";a="287304087"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2016 17:30:20 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u5IHUJ9S000632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 18 Jun 2016 17:30:19 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 18 Jun 2016 13:30:18 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Sat, 18 Jun 2016 13:30:18 -0400
From: "Tarek Saad (tsaad)" <>
To: "Kamran Raza (skraza)" <>, "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: AdG3bLXTtn0B3RvFQBm5DUcAqBi2yQSGjCkA
Date: Sat, 18 Jun 2016 17:30:18 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.16.0.160506
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AF0EEC596D774C1B927E590501F1520Bciscocom_"
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: Sat, 18 Jun 2016 17:30:24 -0000

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.

·         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.

·         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)

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

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

>> 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?

>> 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.

>> You are defining several data-types as enums. You may want to consider identities for types you think may be extended by other modules.

>> oper-status-event-type
Is this specific to events? not applicable to state?

>> 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.

>> use of “presence” keyword to enable functions. From feedback, having explicit “enable” leaf was more favorable (avoids issues

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


From: Ross Callon <>
Date: Thursday, May 26, 2016 at 12:36 PM
To: "'Bert (IETF) Wijnen'" <>et>, Mach Chen <>om>, Tarek Saad <>om>, Minto Jeyananth <>
Cc: "" <>rg>, "Kamran Raza (skraza)" <>om>, "Reshad Rahman (rrahman)" <>om>, "Rajiv Asati (rajiva)" <>om>, "" <>om>, "" <>om>, "" <>om>, Santosh Esale <>et>, "" <>om>, Loa Andersson <>nu>, "" <>om>, "Bocci, Matthew (Matthew)" <>om>, "" <>om>, "Sowmya Krishnaswamy (sowkrish)" <>om>, "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)