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

Greg Mirsky <> Wed, 29 November 2017 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 976D71267BB; Tue, 28 Nov 2017 18:07:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 lRgzu_nxW3sq; Tue, 28 Nov 2017 18:07:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3E93126E7A; Tue, 28 Nov 2017 18:07:41 -0800 (PST)
Received: by with SMTP id f20so2093775lfe.3; Tue, 28 Nov 2017 18:07:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tv6WGWQjIh4AMXni7hPw1bElfhVR51DXD9Q2ueNPEA0=; b=sohjFc2U6d3+CHOxQYtr54m0GoNTJvJ3fVnOJWTp+E1GEIwSNNCcsWgN5T4TEi/lTH QMtYO36NeitMhlHo4dZv4vfnOY8Aiq+iu/gat/tFTnMwot0XMiiXCaIZsByZYIMNhjnb Lvv1MX0BmO2xiZMOLBa/AjprwzD1BqCBqv2dm8Ba7A7RLyGtjxyKAcoKiZjC1BECfWhJ SvqIbYLBN7TBRddRoCpWR342hiWWSHjeyjFfvoH9N7VelHhbjl5Qb+yAh69Uws9w5byC kuELS6Qsg2HpBTh9Fko3qu2LZOlJLsgweXDT8GJVfsQF91iSRiiHRRh2MPrcvfLQvz0X oCMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tv6WGWQjIh4AMXni7hPw1bElfhVR51DXD9Q2ueNPEA0=; b=mAeJH97YtQovoZRSp4h93JLbb3tsNlvhgxQcsnzgrAG+W6jAetC4+3BLmcxqM1c0E1 jTTaQMblQ6cbl7uVt56gZnxD5m+E9CJf5pCfp4fyHPckgEWPZ2Gw1LNM+LgD+0VBzIKY 3kudCrn4fjqd6ju3kNQJ4HcUMO1GSUlx1UwqHqPACg7r8bT6Gln3sUHl8NmBU44nV3Ot qEvkrUnLBBol9nUdLd39LH+D0KFcucY9wsZjvr/6FPaZQ2Cmk8rAd/i2Hq1NgAmKGgYn LRT56jyG3YVmZhqgZEe7+jG/2otOM35zNdtOavZRn8QdCcoGsIEfVqT+JPcGUuwzlCUK Skhw==
X-Gm-Message-State: AJaThX7FUgR5kF+pnJ4udn/9lHpb67VquX/vk/CYVo3N2nB3MtbUvDl9 O9AT7F6k8QYl6yZ48GpE8NLZZuY8dy6LKZPWFYI=
X-Google-Smtp-Source: AGs4zMa7a+7/FOjF1NaUZywVRdDva8EZLc9tshijXD9yfvPuYFUkqvnlPSvmhz2+EKxl3GfoC0oHtpviVWShCKMZdNQ=
X-Received: by with SMTP id h29mr578992ljb.144.1511921259357; Tue, 28 Nov 2017 18:07:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Nov 2017 18:07:38 -0800 (PST)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Tue, 28 Nov 2017 18:07:38 -0800
Message-ID: <>
To: "Faisal Iqbal (faiqbal)" <>
Cc: "" <>, "" <>
Content-Type: multipart/alternative; boundary="94eb2c1ce7fa97aca7055f15993e"
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: Wed, 29 Nov 2017 02:07:43 -0000

Hi Faisal,
apologies for the delay to respond to your thorough review of the MPLS LSP
ping data model and great comments. Please find my answers and notes
in-line and tagged GIM>>.
I'm looking forward to be working with you as co-author on this draft. Hope
you'll agree.


On Tue, Nov 14, 2017 at 2:27 PM, Faisal Iqbal (faiqbal) <>

> 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?
GIM>> Yes, you're absolutely 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.
GIM>> I think we may use tunnel-ref and tunnel-p2mp-ref defined
in draft-ietf-teas-yang-te.
GIM>> And extending your suggestion, should it be for other FECs, for
example, static?

> 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.
GIM>> I like the idea to provide optional controls over entropy of LSP
Ping. These may be useful not only for LSP Ping but BFD over MPLS LSP.

> 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.
GIM>> Agree. And what the defaults could be?

> 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?
GIM>> Index of an LSP ping within a test session.

> 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?
GIM>> It must be extended, agreed. I think it is r/w. Not?

> Does this document only tackle LSP Ping operation? Would other echo
> request operations such as LSP Traceroute for LSP path discovery be
> documented separately?
GIM>> Great observation! Traceroute should be supported. Path discovery?

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”
GIM>> Thank you, Faisal. Will include in the next update.

> Regards,
> Faisal Iqbal