Re: [mpls] I-D Action: draft-zheng-mpls-lsp-ping-yang-cfg-06.txt

"Faisal Iqbal (faiqbal)" <> Tue, 14 November 2017 22:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2685E124319; Tue, 14 Nov 2017 14:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 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, 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 DVoAQLyKOxmY; Tue, 14 Nov 2017 14:27:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 086001289C3; Tue, 14 Nov 2017 14:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14483; q=dns/txt; s=iport; t=1510698428; x=1511908028; h=from:to:cc:subject:date:message-id:mime-version; bh=dkvIEPN4Ic64JOahdFl1yh709/O0C+MuM0+2QfTLHi4=; b=BUSgc08kVeX2IGcE2oJoRVrZJcfwcLFd38iBZjqhkAqf6Z+5YHFM5JVG kZwbNvM87cN6sJC1SW16/JmpQJ1h732YiGC/XUiTZh7JeddSAlKwCpQPJ 0v5gXhfPCk6VVUVGHm93r3tfsKgWKk1haP5sBvdiEI6EjaCJIZpyx0VWe g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.44,396,1505779200"; d="scan'208,217"; a="31491498"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2017 22:27:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vAEMR6C0016130 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2017 22:27:06 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 17:27:06 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 17:27:06 -0500
From: "Faisal Iqbal (faiqbal)" <>
To: "" <>
CC: "" <>
Thread-Topic: Re: I-D Action: draft-zheng-mpls-lsp-ping-yang-cfg-06.txt
Thread-Index: AdNdjyOxXWZY6vvjTLaJ2bdaZ6mivQ==
Date: Tue, 14 Nov 2017 22:27:05 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_005300d0a6d84a448fab94dfc6e9759fXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] I-D Action: draft-zheng-mpls-lsp-ping-yang-cfg-06.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2017 22:27:10 -0000

Dear Authors,
Thank you for initiating the work on Yang Model for LSP Ping and sharing your draft. I have gone through the document and find it very useful and important work item. Please see below for some comments on the document. I'm still a beginner in Yang modeling so I apologize if I'm missing something obvious or well-understood.

Sec 3.1 - I think the document aims to specify various existing MPLS OAM targets (including P2MP) through a combination of target-fec-type and target-fec structure. Is my understanding correct?

Sec 3.1 - I did not find a way to specify some important parameters in the container control-info that operators can use to control echo request path or other parameters. Specifically:

i.                 Operator should be allowed to specify RSVP interface by tunnel name as well. For some operators, name may be more meaningful than tunnel number.

ii.                A field to provide a destination address in 127/8 range.

iii.               An option to specify a range of destination addresses to test e.g. give destination start address and end address, system will initiate 8 echo requests correspondingly.

iv.               Given that TTL is a field in the container control-info, I feel that operator should be given an option to specify whether or not to use Downstream Detailed Mapping (DDMAP) TLV, or even the deprecated DSMAP TLV.

v.                Operator should also be allowed to specify DDMAP TLV sub-TLV fields such as the presence, type, and size of multipath TLV.

Sec 3.3 - I had following questions about the result-info structure.

i.                 If the echo reply contains a TLV (e.g. DDMAP TLV for request to a transit node), how will we communicate that information to the user? Operator may use LSP Ping to identify downstream path(s) from a particular downstream node.

ii.                What does probe-index refer to?

Sec 6 - For target-fec-type, is there a way for operator to specify a particular control plane or FEC (as defined in RFC-8029 e.g. LDP, Generic FEC etc.) to be used for echo request?

Does this document only tackle LSP Ping operation? Would other echo request operations such as LSP Traceroute for LSP path discovery be documented separately?

Some minor editorial comments below.
-"Model presented in [RFC4560];" instead of "Model presented in[RFC4560] ;" in Section 1.2
-Text in Section 3 should read "...and result information for multiple instances of LSP-Ping test." Instead of "...and result information for multi instances of LSP-Ping test."
- "IETF Multiprotocol" instead of ""IETF Multiprotocl" in Section 6.
-Description for enum success should read "The test probe is successful" instead "The test probe is successed"
-Description for leaf sum-of-squares in Section 6 should read "replies" instead of "replys"

Faisal Iqbal