Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

"Templin (US), Fred L" <> Wed, 30 January 2019 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0BBF130E85 for <>; Wed, 30 Jan 2019 08:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RLlFLkWlmTQb for <>; Wed, 30 Jan 2019 08:55:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B620130E74 for <>; Wed, 30 Jan 2019 08:55:39 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x0UGtaIx001062; Wed, 30 Jan 2019 11:55:37 -0500
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x0UGtRup032186 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 30 Jan 2019 11:55:27 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Wed, 30 Jan 2019 08:55:25 -0800
Received: from ([fe80::e065:4e77:ac47:d9a8]) by ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1591.012; Wed, 30 Jan 2019 08:55:25 -0800
From: "Templin (US), Fred L" <>
To: Stewart Bryant <>, Fred Baker <>, Tom Herbert <>
CC: int-area <>
Thread-Topic: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
Thread-Index: AQHUuCuxLuPn/vC+bky5xmwg6zRJFKXIYdIA//+kMiA=
Date: Wed, 30 Jan 2019 16:55:25 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: FAACDBE83E580A15EB8D35C53D8068F3BBC5DE1B64093B5FDD954E510F4834BA2000:8
Content-Type: multipart/alternative; boundary="_000_751bf1d2e6f94e98a5f9bafad3b27bf4boeingcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jan 2019 16:55:43 -0000

Hi Stewart,

>> It we really need to fragment a packet, it would be better to stick the fragments inside a common UDP/IP(no frag) shim.

I agree. Two different approaches for UDP fragmentation that avoid IP fragmentation
are currently under consideration:

Thanks - Fred

From: Int-area [] On Behalf Of Stewart Bryant
Sent: Wednesday, January 30, 2019 6:14 AM
To: Fred Baker <>om>; Tom Herbert <>
Cc: int-area <>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

On 29/01/2019 23:37, Fred Baker wrote:

Section 4.5:

"IP fragmentation causes problems for some routers that support Equal

Cost Multipath (ECMP). Many routers that support ECMP execute the

algorithm described in Section 4.4 in order to perform flow based


As far as I know, routers that hash fields in the IP header to select a en ECMP next hop do so because all packets in a flow will hash the same way (modulo the issues with the transport port number), not because they are doing per-flow forwarding. The do so explicitly to avoid having to maintain per-flow state and yet make all fragments of a message follow the same path.

I agree with Fred. ECMP is normally done to distribute the load over the available next hops on a best effort basis. Originally it was done per packet, but that gave problems with out of order packet delivery, so the routers moved to doing it based on the five tuple described in this draft. It is a stateless best effort ECMP process with no regard to specific flows and the path for any five tuple may move arbitrarily if routing changes its mind on the ECMP set.

Fragmented packets are really bad news in networks that need ECMP. There is not enough entropy in the SA/DA/Protocol triplet and anything else results in misorder. But if ECMP is not done this overloads the default path.

MPLS is also stateless but there are more options, although the most common is to look past BoS to the five tuple, however some "features" make mistakes and look at a non-existent five tuple despite hints in the packet that thus is a bad idea.

therefore, the exhibit they same problematic behaviors

described in Section 4.4. In IPv6, the flow label may alternatively

used as input to the algorithm as opposed to parsing the transport

layer of packets to discern port numbers. The flow label should be

consistently set for a packets of flow including fragments, such that

a device does not need to parse packets beyond the IP header for the

purposes of ECMP."

Add to section 7.3:

"Routers SHOULD use IPv6 flow label for ECMP routing as described in [RFC6438]."

If we want to migrate to the FL then we really need to state that the FL MUST be set by the sender. Without, that we are never going to wean routers off looking at the five tuple, if indeed we ever succeed in doing that.

It we really need to fragment a packet, it would be better to stick the fragments inside a common UDP/IP(no frag) shim. Then the forwarders could carry on just as they are. We would never get misorder and we would not be faced with the impossible problem of changing the Internet core forwarding behaviour to a single consistent model.

- Stewart


Int-area mailing list<>


Victorious warriors win first and then go to war,

Defeated warriors go to war first and then seek to win.

     Sun Tzu


Int-area mailing list<>