Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
References: <20160105214706.11111.8218.idtracker@ietfa.amsl.com>
In-Reply-To: <20160105214706.11111.8218.idtracker@ietfa.amsl.com>
Mime-Version: 1.0 (1.0)
Message-Id: <B81240CB-79D8-4629-8E8E-453D5721DFF7@gmail.com>
From: Gmail <stewart.bryant@gmail.com>
Date: Wed, 6 Jan 2016 17:10:40 +0000
To: Martin Stiemerling <mls.ietf@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/cXhqMt9YI6Tqhx5FFomca_AaeVU>
Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org,
 The IESG <iesg@ietf.org>, mpls-chairs@ietf.org
Subject: Re: [mpls] Martin Stiemerling's Discuss on
 draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS)
Precedence: list

Martin

It is  a fundamental tenet of MPLS is that the network is well managed with t=
he operators paying significant attention to traffic planning, I therefore t=
hink that it is reasonable to assume that they would also pay adequate atten=
tion to their UDP management traffic.

Loss is so light in these networks that the interval between loss measuremen=
ts needs to be long to see any loss at all, thus I would normally expect us t=
o be talking packets per minute or packets per hour rather than packets per s=
econd, and this would be on links with GB+ capacity. Similarly it makes litt=
le sense to make delay measurements very frequently.

In both cases the amount of traffic will be minuscule compared to the IPFIX o=
ver UDP traffic that that many operators will already will running.

I thus fear that you raise the congestion daemon without proper regard to th=
e practicalities of this type of application.

Stewart.=20

Sent from my iPad

> On 5 Jan 2016, at 21:47, Martin Stiemerling <mls.ietf@gmail.com> wrote:
>=20
> Martin Stiemerling has entered the following ballot position for
> draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss
>=20
> 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.)
>=20
>=20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> I am in favour of publishing this document, but I have two major points
> that are not addressed in the document by now:
>=20
> 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.=20
>=20
> 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.=20
>=20
> With regard to point 2): I can try to find some help from the transport
> area, in case you need help.
>=20
>=20
>=20
>=20
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls