Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS)

Martin Stiemerling <> Wed, 13 January 2016 09:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C8E41A21BC; Wed, 13 Jan 2016 01:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CcLeLQnzcbZA; Wed, 13 Jan 2016 01:39:58 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FA641A21B3; Wed, 13 Jan 2016 01:39:58 -0800 (PST)
Received: by with SMTP id f206so286130031wmf.0; Wed, 13 Jan 2016 01:39:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=CWP6Uua0V4+eE9tflkdlnzR1ScJbA1ci5Z6kRyIxD8s=; b=U1EAGuiBEGRf/v2EfTvvrzhNqlu7e0OSvzqLiOPiein+bSnkkoMfQySiWtQhDkhU0q H79QsPm96iN/JWqpwk8E8gSw8/PbFsnzZrP+nBCuTTCOy5x27tT182kgyHN9XTRuyWxq sIBfiUs8vrMmbXWhhd1uBE7L7Opy48fflm6Zggoq+8p37RQ3Y3yqWvoU8TcOH7ENxRX4 q3YS20PykzMa5+ajOwu/i+tLcb7QHu+2PQ7JKpnsklv7+dwqQbyhcEOBtuAcsQjAZ+61 VOAh633LteHHaJGz4LRXzQXsJ3lOgeLvaWkm+C8L/WLNc0HQTQIO1okqniCu+xsqy+A8 0z3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=CWP6Uua0V4+eE9tflkdlnzR1ScJbA1ci5Z6kRyIxD8s=; b=MkYFFZ6Wjo3kBU5dfdcOLwdPt2E4eD/jLJMPJpDxG5UkmfFQ9QtOym5xiDFtgDvriD Ppd9i+45gDvW1RgjGynHTcCL5zd9M2mt46kLm5VcHO7LRpm3XF03SoxQoqRPYoezxhmx vScCv/BN/1ibaQi2hose1nHP4cN0fpL9l6IlJQpCZ7uj//6P9PQ3AbUeEHWBD91rtpQi mM0lHD4Ihy4rQdkHful2FbrmkvCZpKFX+9p1BiR9TxxAYEE0Xj7XFL0gSSePn0G5Ewz4 +eDHd7/cu9WunJ7EJup7f51plj3AtUI/pARItnWaC0xbaJ+oeg+TtWmFYVwyrpZ6vS8j j+VA==
X-Gm-Message-State: ALoCoQnuD5q1Iz1gbJU4t9CUdtUgC4EFt6nNiduSneTco3cjxYL9W/CMi/c/f8Jef7lF9ZgN6pFAtBPDwsBjQlVocMXEHA8NbQ==
X-Received: by with SMTP id jp4mr108620154wjb.26.1452677996710; Wed, 13 Jan 2016 01:39:56 -0800 (PST)
Received: from ( []) by with ESMTPSA id w80sm21412944wme.17.2016. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 01:39:56 -0800 (PST)
To: Gmail <>
References: <> <>
From: Martin Stiemerling <>
Message-ID: <>
Date: Wed, 13 Jan 2016 10:39:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:,, The IESG <>,
Subject: Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS)
X-Mailman-Version: 2.1.15
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 Jan 2016 09:40:00 -0000

Hi Steward,

Am 06.01.16 um 18:10 schrieb Gmail:
> Martin
> It is  a fundamental tenet of MPLS is that the network is well
> managed with the operators paying significant attention to traffic
> planning, I therefore think that it is reasonable to assume that they
> would also pay adequate attention to their UDP management traffic.
> Loss is so light in these networks that the interval between loss
> measurements needs to be long to see any loss at all, thus I would
> normally expect us to be talking packets per minute or packets per
> hour rather than packets per second, and this would be on links with
> GB+ capacity. Similarly it makes little sense to make delay
> measurements very frequently.
> In both cases the amount of traffic will be minuscule compared to the
> IPFIX over UDP traffic that that many operators will already will
> running.
> I thus fear that you raise the congestion daemon without proper
> regard to the practicalities of this type of application.

I fully understand that this type of protocol is used usually in a fully 
managed network. But congestion can also happen there, and congestion is 
by the way not a daemon, but a natural consequence of a best effort 
network even if it is managed

And even in fully managed networks traffic can accumulate at one point 
causing congestion.

I do not see the need to work through all details of RFC 5405, but I 
want to see text that reflects about using an not congestion controlled 
protocol and possible consequences and guidances for operators using this.
One way to handle this, to make operators aware of the need to monitor 
the rate of UDP traffic and that any excess of this rate is worth noting 
to the network operator.

By the way, your argument above about the managed environment would also 
make Section 5 superfluous, isn't it?



> Stewart.
> Sent from my iPad
>> On 5 Jan 2016, at 21:47, Martin Stiemerling <>
>> wrote:
>> Martin Stiemerling has entered the following ballot position for
>> draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss
>> 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 am in favour of publishing this document, but I have two major points
>> that are not addressed in the document by now:
>> 1) It is not clear for anybody what the expected size and sending
>> frequency of such MPLS-PLDM over IP/UDP responses are. This will
>> influence any measures an operator has to take in order to assure
>> that there is no congestion caused by these messages. I can
>> understand that this cannot be foreseen, but a few words
>> considering this fact are excellent to have in the document.
>> 2) This leads to my second point: the lack of any reference to RFC
>> 5405 "Unicast UDP Usage Guidelines for Application Designers" and
>> the content out of this RFC that is applicable for this draft.
>> There is no discussion about this at all. Please note well that
>> this is BCP 145.
>> With regard to point 2): I can try to find some help from the
>> transport area, in case you need help.
>> _______________________________________________ mpls mailing list