Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

Mirja Kuehlewind <> Wed, 13 March 2019 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 340DB130EDC; Wed, 13 Mar 2019 02:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3_lPH1Mryn2K; Wed, 13 Mar 2019 02:51:27 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92B4B130EDB; Wed, 13 Mar 2019 02:51:27 -0700 (PDT)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h40Xj-0002uM-7d; Wed, 13 Mar 2019 10:51:23 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Wed, 13 Mar 2019 10:51:22 +0100
Cc: Mirja Kühlewind via Datatracker <>, The IESG <>, "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mach Chen <>
X-Mailer: Apple Mail (2.3445.101.1)
X-HE-SMSGID: 1h40Xj-0002uM-7d
Archived-At: <>
Subject: Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Mar 2019 09:51:30 -0000

Hi Mach,

Please see below

> On 13. Mar 2019, at 10:15, Mach Chen <> wrote:
> Hi Mirja,
> Thanks for your comments!
>> -----Original Message-----
>> From: Mirja Kühlewind via Datatracker []
>> Sent: Wednesday, March 13, 2019 12:00 AM
>> To: The IESG <>
>> Cc:;;
>> Subject: Mirja Kühlewind's No Objection on draft-ietf-mpls-lsp-ping-lag-
>> multipath-06: (with COMMENT)
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-mpls-lsp-ping-lag-multipath-06: No Objection
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> I wanted to comment on the same sentence/normative requirement as
>> Alvaro did in his point (2). Given Alvaro's additional information that there is
>> actually even a technical conflict with this requirement, I think this should be
>> address before publication and might even be discuss-worthy. However, I'm
>> really not an expert on MPLS and therefore leave the decision to state a
>> discuss ballot position to potentially other, more knowledgable ADs.
>> Thanks for addressing the TSV-ART review comments (and thanks Jörg for
>> the review)! I support adding another sentence with a pointer to rate-limit
>> requirements in other docs. Thanks for proposing this change. Looking
>> forward this see this in the doc!
> Are you suggesting to add a reference, do you have any specific docs suggestion?

In your reply to Joerg’s tsv-art review (on Dec 14 already), you proposed to add the following statement:

"For an LSP path, it may be over several LAGs. For each LAG, there will be many member links. To exercise all the links, many Echo Request/Reply messages will be sent in a short period. It's possible that those messages may traverse a common path as a burst. Under some circumstances this might cause congestion at the common path. To avoid potential congestion, it is RECOMMENDED that implementations to randomly delay the Echo Request and Reply messages at the Initiating LSRs and Responder LSRs.”

You also said:
"RFC8029 (Security Consideration) does recommend the implementation to regulate the ping traffic to the control plane, it  applies to this document as well. 

At the same time, RFC 6425 (P2MP LSP Ping, section 2.2) introduces some ways to limit the message rate. The way of random delay messages would apply to this document as well.”

So adding pointer to these two documents/sections would be good as well maybe.


> Best regards,
> Mach