Re: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 23 March 2021 09:48 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 5A74D3A011D for <v6ops@ietfa.amsl.com>; Tue, 23 Mar 2021 02:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 WpMna6ItvqsT for <v6ops@ietfa.amsl.com>; Tue, 23 Mar 2021 02:48:12 -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 EAABE3A0113 for <v6ops@ietf.org>; Tue, 23 Mar 2021 02:48:11 -0700 (PDT)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F4RJ82ss1z682Gm; Tue, 23 Mar 2021 17:43:20 +0800 (CST)
Received: from msceml706-chm.china.huawei.com (10.219.141.145) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Tue, 23 Mar 2021 10:48:03 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Mar 2021 12:48:03 +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; Tue, 23 Mar 2021 12:48:03 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
Thread-Index: AQHXH3+eR0cjcBj+Okmt9iksManO36qRTfrg
Date: Tue, 23 Mar 2021 09:48:03 +0000
Message-ID: <0c8fa84f22334932961238d715f9f031@huawei.com>
References: <161618441098.16707.1272808535936578483@ietfa.amsl.com> <067e2750-b212-4dc5-23b4-ada2060ca0d2@gmail.com>
In-Reply-To: <067e2750-b212-4dc5-23b4-ada2060ca0d2@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.202.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vEK7O4fud7JVljh4_LoliWBEdv0>
Subject: Re: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
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: Tue, 23 Mar 2021 09:48:15 -0000

Hi Brian,
Yes, it is better not to have the problem in the first place.
And if the network should have redesign for SRv6 anyway then why not increase MTU at the same time?
Very logical. Hence, the draft has started the solution section from this solution - the best one.
But it is not always possible (discussed in section 3.1):
- SRv6 is positioned for the case when upgrade could be slow enough (node-by-node), then some nodes would be just plain IPv6 in transit - no changes assumed for these nodes
- some links could be rented - no possibility to change MTU in principle
- DC-to-DC could generate 9k that is not possible to accommodate in principle
- middleboxes (security, load balancing) could be on the path event for the final design. Middleboxes have their own refreshment cycle (with the budget from different department)
- low-cost routing platforms may not be capable to share buffers between many packets (1 packet = 1 buffer) then 9kB buffer would be given for any 100B packet. MTU increase for such platforms effectively decrease buffer capacity in ms to make it negligible and not acceptable.
- link could be not Ethernet - it may not support 9k

The net result is activities like:
draft-zhu-idr-bgp-ls-path-mtu
draft-li-idr-sr-policy-path-mtu
draft-li-pce-pcep-pmtu
draft-hu-lsr-isis-path-mtu
to control the situation in the way that we call "frugal headers usage" in the draft.

Our assumption that is better to fix PMTUD. But it does not preclude other mechanisms development.
PLPMTUD is probably too much to ask from SRv6 tunnel end.
Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Tuesday, March 23, 2021 3:58 AM
To: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt

>    Initial SRv6 implementations that trespassed safe limit in 220B are
>    the reason for recent activities in MTU problem research.

I don't understand that motivation. Since SRV6 is explicitly limited to a specific domain, as stated in Section 2 of RFC8402, it is reasonable to expect that the domain is designed with a large enough MTU to allow the expected extra headers for SRV6, and that will include any tunnel end points within the domain knowing how to support packets longer than 1280 bytes if that is needed. An obvious design goal would be to make both PMTUD and PLPMTUD unnecessary within the domain.

Regards
   Brian Carpenter

On 20-Mar-21 09:06, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv6 Oversized Packets Analysis
>         Authors         : Eduard Vasilenko
>                           Xiao Xipeng
>                           Dmitriy Khaustov
> 	Filename        : draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> 	Pages           : 19
> 	Date            : 2021-03-19
> 
> Abstract:
>    The IETF has many new initiatives relying on IPv6 Enhanced Headers
>    added in transit: SRv6, SFC, BIERv6, iOAM. Additionally, some recent
>    developments are overlays (SRv6, VxLAN) over IPv6. It could create
>    oversized packets that need to be dealt with. This document analyzes
>    available standards for the resolution of oversized packet drops.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-
> analysis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-vasilenko-v6ops-ipv6-oversized-analy
> sis-00
> https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-overs
> ized-analysis-00
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops