Re: [mpls] Tsvart last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05

Joerg Ott <> Fri, 21 December 2018 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC3C12426A; Fri, 21 Dec 2018 05:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LEx6O6XlDAR5; Fri, 21 Dec 2018 05:35:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5709A123FFD; Fri, 21 Dec 2018 05:35:45 -0800 (PST)
Received: by (Postfix, from userid 107) id 472271C04B3; Fri, 21 Dec 2018 14:35:42 +0100 (CET)
Received: (Authenticated sender: ott) by (Postfix) with ESMTPSA id 1B0E41C04B0; Fri, 21 Dec 2018 14:35:39 +0100 (CET) (Extended-Queue-bit
To: Mach Chen <>, Joerg Ott <>, "" <>
Cc: "" <>, "" <>, "" <>
References: <> <>
From: Joerg Ott <>
Message-ID: <>
Date: Fri, 21 Dec 2018 14:35:39 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [mpls] Tsvart last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05
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: Fri, 21 Dec 2018 13:35:51 -0000

Hi Mach,

thanks for the quick response, inline.

>> 1. With the potentially substantial stacking of TLVs, I am wondering how large
>>     packets can get, especially if numerous links might constitute a LAG and all
>>     of those are extensively described.  It may be useful to provide the reader
>>     with some intuition.   There are many useful examples in the document,
>> but
>>     they all refer to individual fields.  A complete packet could be helpful.
> This document is an extension to RFC8029, where (Section 3 of RFC8029) a complete packet of LSP Ping is defined. The extensions defined in this document are major made to DDMAP TLV. Section 4.2 of this document gives an example of a DDMAP TLV with the extensions defined in this document.
> Do you suggest to use a complete packet to replace the DDMAP TLV in the example?

Maybe this would go indeed a bit far but I am wondering if the full
structure including size hints would be use.

>> 2. I assume the MPLS LSP Ping mechanism specifies a packet pacing
>>     rules.  Would those need refinement for multipath probing as all echo
>>     request packets may traverse a common path as a burst on their way
>>     to a load balancing router.  The same would hold for returning the
>>     responses.
> 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.


> How about we add some sentences in the Security Consideration section to say so? For example:
> "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."

Not sure I would put this into security considerations since this is
primarily an issue of rate control.  Can you think of another place?

>> Irrespective of this transport review, the beginning of section 2 points to RFC
>> 8029 section 3.3, which is a pointer to a deprecated Annex. Even if just
>> informal, the reader should probably not be expected to know the details of
>> deprecated technologies.
> I am fine to remove the reference to Section 3.3.
>> Editorial:
>> p9, 2nd para "A LAG member may also..." should probably be MAY.
>> p11, section 5, 1st line: "to constructs" -> "to construct"
>> p13, 1st line: additional logics -> additional logic
> OK.