Re: [v6ops] draft-ietf-intarea-tunnels concerns

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 25 March 2021 16:21 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CF83A26C9; Thu, 25 Mar 2021 09:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 U5Ni0lk5wniz; Thu, 25 Mar 2021 09:21:43 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114733A26C5; Thu, 25 Mar 2021 09:21:43 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F5qxJ02V9z682l0; Fri, 26 Mar 2021 00:16:52 +0800 (CST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 25 Mar 2021 17:21:38 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 25 Mar 2021 19:21:37 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2106.013; Thu, 25 Mar 2021 19:21:37 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, int-area <int-area@ietf.org>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: draft-ietf-intarea-tunnels concerns
Thread-Index: AdchXcgc+BNv8UaCSiCbTZn958h4xAAJ6/RgAALUf0A=
Date: Thu, 25 Mar 2021 16:21:37 +0000
Message-ID: <ae907b57fc2e4445a40bac6cd299f8e8@huawei.com>
References: <67a4aeb99dc6464c913516d744aa27bd@huawei.com> <71137841287d4e37a564fc06b15ac54c@boeing.com>
In-Reply-To: <71137841287d4e37a564fc06b15ac54c@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.145]
Content-Type: multipart/alternative; boundary="_000_ae907b57fc2e4445a40bac6cd299f8e8huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LFGvCPRjrhQp_5TZ4IvMeYCtkUg>
Subject: Re: [v6ops] draft-ietf-intarea-tunnels concerns
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 16:21:48 -0000

Hi Fred,
As I remember, you do not try to invalidate all other tunneling solutions.
draft-ietf-intarea-tunnels is doing exactly this.

IMHO: If some hardware achievement would not give us reassembly almost for free
Then the general solution should not assume reassembly because it is still very expensive for hardware at tunnel end points.
Overlay/Underlay is very popular our days – we would see more and more tunneling. SRv6 is the best example based on RFC 2473.

But it could be fine for your environment because overall performance would not go many Tbps per 1 gateway.
It is still possible to rely on something like Network Processor.
You would do some tradeoff between cost and flexibility. A little more cost for your environment should not be the problem.
Eduard
From: Templin (US), Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Thursday, March 25, 2021 6:12 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; int-area <int-area@ietf.org>
Cc: v6ops@ietf.org; 6man@ietf.org
Subject: RE: draft-ietf-intarea-tunnels concerns

Eduard, I did a quick pass through the intarea discussions and I see points raised that
have been repeated many times since Y2K and even since much longer before that.
Thankfully, there is now a solution called the “OMNI Adaptation Layer (OAL)”:

https://datatracker.ietf.org/doc/draft-templin-6man-omni/

Some might say that it is the “second-coming of AAL5”, and it is true there are
many similarities. Like IP over ATM, the OMNI interface has an MTU/MRU visible
to the IP layer and set to 9180 bytes since that is the maximum size that can be
well protected by CRC32. Like AAL5, within the OMNI interface the OAL has a
“cell size” that determines the size of each fragment that will be produced by
the adaptation layer below IP.

Unlike AAL5 where the cell size is fixed at 48 octets, however, the OAL sets
both a minimum cell size (termed “minimum Maximum Payload Size (MPS)”)
and a possibly larger per-path MPS discovered using probes if necessary. The
minimum/path MPS is the maximum-sized RFC2473 fragment that the OAL
can sneak through the path and be assured it won’t be dropped (silently or
otherwise) due to a size restriction. Without any probing, the minimum MPS
that can be assumed is 576 minus encapsulation overhead (i.e., the IPv4
minimum EMTU_R). But unlike AAL5, the OAL can always strive to find a
larger per-path MPS.

There is more to be said about the OAL, but I will leave it at that for now.
We can talk about PTB “hard” and “soft” errors later if there is interest.

Fred