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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 30 January 2019 14:13 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92403128CF2 for <int-area@ietfa.amsl.com>; Wed, 30 Jan 2019 06:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lcz19B9hCTO for <int-area@ietfa.amsl.com>; Wed, 30 Jan 2019 06:13:57 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC25C123FFD for <int-area@ietf.org>; Wed, 30 Jan 2019 06:13:56 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id y185so15579687wmd.1 for <int-area@ietf.org>; Wed, 30 Jan 2019 06:13:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=yf7iYYtlX3SnrAAI8phTIKnLcOJSbbzEzbf2Ccj/Akg=; b=Rlr/eEmgnLBkbrJqZBChKpLpi5MmlX2Q5KFPfMQQBIF2/UNhdXrBauXzM7g4a/aLA4 QLcchnzTYLs6tNvVK/VLbjEnbU0V5kaWulA5Zujn66a2XWXL7/uLikzr5x9x6yjXGJG3 4qvzANDpt/dFrZJeqgIIpiXH52dzQoa7upHVrBabNf/5VQtZVe0NshQCjIxVNUmCE4Ft 06ORpbRb4sVEAdmusWkxhbpheRrsPdpRK4spsCejzd8X6YBTIkJg+lEKt+cYAnr0xpJb LnX6JXSVW17RNVQMZYxYZ0PFAw8DmToFF8JIsCGzEYqG1De96bpaapanWqaFWEKNYXsG /ogw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yf7iYYtlX3SnrAAI8phTIKnLcOJSbbzEzbf2Ccj/Akg=; b=FVf+ju1XwJmQntVc1w+BMbabMaC2MsxOV8m4WonYzGU0mVRbmF+jzpbTlDXErfJHHK 973Uvxrx7255bkiGkCB+tYN9nxJAu9qc7CX+CCd8Z5rpqTiN2QOO2GLUc351rG2z5DKm 5PK8mWvSlMECIlwb/7AsZu0jEperruNASp6FNbCU8EAzeOm59VQmacVdt4437Npig8U/ 0Lo5U1zZDX5jQtNzgN4B210B8mnkibuoETIMZGWkVtt0dPKJ22FsrsSIB8uWmgJ8dSwl dxiyygeD5WmzhIEo1ArS1KpOlq7KLDGb8iIEyXbR0M/0voFqw+cfzpDfjBlkJs53xKas l23Q==
X-Gm-Message-State: AJcUukf5+ISWeMDBLHg1LwN7AInpUyAMb8KGoaOB3l/x7OknutNYu19s FzoFcVw3YmzhSPbXqJVyKZH+0H0K
X-Google-Smtp-Source: ALg8bN7FramdCxDYkB28b/jNpf5Pp3yzK+X59JkwPNV7z5bpTa4Lsv8BE6APko/YZp1UB1F8CSDNVg==
X-Received: by 2002:a1c:a68f:: with SMTP id p137mr23716712wme.64.1548857634404; Wed, 30 Jan 2019 06:13:54 -0800 (PST)
Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b18sm1676293wrr.43.2019.01.30.06.13.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 06:13:53 -0800 (PST)
To: Fred Baker <fredbaker.ietf@gmail.com>, Tom Herbert <tom@herbertland.com>
Cc: int-area <int-area@ietf.org>
References: <CALx6S35kwvHL5iE4Ci10LQbPzun3k1C-T4m5B55yAyL+nP4sdQ@mail.gmail.com> <3B29EAA5-5989-4A8F-857B-3DEF63A7FEA7@gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <538a3580-dd3a-a778-dda0-bfc30f749bd9@gmail.com>
Date: Wed, 30 Jan 2019 14:13:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <3B29EAA5-5989-4A8F-857B-3DEF63A7FEA7@gmail.com>
Content-Type: multipart/alternative; boundary="------------79448537BCBE220B2702D65E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/2jgaeZ0l5e1qUphABG56Fbm9BZc>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2019 14:13:59 -0000

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
>> forwarding;
> 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
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> --------------------------------------------------------------------------------
> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area