Re: [netmod] Question regarding RFC 8344

Vladimir Vassilev <vladimir@transpacket.com> Sun, 14 July 2019 23:06 UTC

Return-Path: <vladimir@transpacket.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAC4120158; Sun, 14 Jul 2019 16:06:44 -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, 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 qf_Aq0qKGegr; Sun, 14 Jul 2019 16:06:42 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498D1120134; Sun, 14 Jul 2019 16:06:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6AD4F4801E76; Mon, 15 Jul 2019 01:06:36 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id MrN5xRXJ9MYm; Mon, 15 Jul 2019 01:06:36 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4320D4801E7C; Mon, 15 Jul 2019 01:06:36 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r7AUjD8BbAyq; Mon, 15 Jul 2019 01:06:36 +0200 (CEST)
Received: from [192.168.0.21] (cm-84.209.19.126.getinternet.no [84.209.19.126]) by mail.transpacket.com (Postfix) with ESMTPSA id 1B6774801E0B; Mon, 15 Jul 2019 01:06:36 +0200 (CEST)
To: Peter Schneider <Peter.Schneider@kontron.com>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-intf-ext-yang@ietf.org
References: <fa13ed97-bd27-7d8e-921b-567521f5e739@kontron.com>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <40226c76-0f5a-2680-fd92-0ebfbdd5a8b8@transpacket.com>
Date: Mon, 15 Jul 2019 01:06:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <fa13ed97-bd27-7d8e-921b-567521f5e739@kontron.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6XQW6H2LvVzPnjk5QyHJhqEevzk>
Subject: Re: [netmod] Question regarding RFC 8344
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jul 2019 23:06:45 -0000

On 7/11/19 7:04 PM, Peter Schneider wrote:
> Hi,
>
> I stumbled on an incompatibility between the IP Management YANG Module 
> and the real world:
> In the 'container ipv4', the leaf 'mtu' is declared as uint16 in the 
> range 68..max, which is effective the range 68..65535, as noted in rfc 
> 7950 <https://tools.ietf.org/html/rfc7950#section-9.2> .
> On the other side, the default MTU size of the loopback interface in 
> Linux is 65536 since several years.

I don't think there is a problem with RFC 8344 since the ipv4 protocol 
MTU can not exceed 65535 bytes (RFC 791). The maximum payload supported 
by an interface which is the case with the default value of the lo 
interface MTU on your Linux distribution (seems this can be configured 
to up to 2147483647 octets at least on mine) has to be greater then the 
MTUs of all protocols (ipv4,ipv6 etc.) supported on that interface but 
they do not need to be equal. It is indeed recommended that the maximum 
"length of the data field of a packet" is used as defined in RFC 894 
e.g. 1500 for ethernet but you can choose or be constrained (like in 
this case) to not do so.

Currently there is no IETF RFC module that has data definition for 
control of the interface MTU used as an upper limit for all protocol MTUs.

FYI there is a /interfaces/interface/l2-mtu leaf proposed in 
draft-ietf-netmod-intf-ext-yang-07 where an uint16 type should probably 
be changed to uint32.

IMO  "/interfaces/interface/mtu" leaf is needed that actually 
corresponds to the maximum length of the data field of a packet and 
already referred to in popular software like Linux as "interface MTU" 
(there is no standard this is based on just running software as far as I 
am aware) should be added in addition to the l2-mtu leaf. Then in your 
case this leaf would be configured to 65536 for the lo interface while 
the /interfaces/interface/ipv4/mtu can be less then that.

/ Vladimir

> Depending on the used netconf client, the client either reports 
> (correctly) an error when getting / configuring the loopback 
> interface, or silently reduces /raises the shown resp. configured 
> value for the mtu.
>
> Are there any statements available on this issue?
>
> Kind Regards,
>
> Peter Schneider
> -- 
> Email Signature of <a class="moz-txt-link-abbreviated" 
> href="mailto:peter.schneider@kontron.com">peter.schneider@kontron.com</a> 
> *Peter Schneider*
> Software Engineer R&D
> *Kontron*
> Heinrich-Barth-Strasse 1-1a | 66115 Saarbrücken | Germany
> P: +49 681 95916 206
> _peter.schneider@kontron.com_ <mailto:peter.schneider@kontron.com>
>
> Website <http://www.kontron.com/> | Blog <http://blog.kontron.com/> | 
> Twitter <https://twitter.com/Kontron> | LinkedIn 
> <https://www.linkedin.com/company/kontron> | YouTube 
> <https://www.youtube.com/channel/UCXkp_1gJbG0Um1vzdowlqww> | Facebook 
> <https://www.facebook.com/kontron>
>
> *Kontron Europe GmbH*
> Die gesetzlichen Pflichtangaben finden Sie hier 
> <http://www.kontron.de/additional/impressum>;.
> Please find our mandatory legal statements hier 
> <http://www.kontron.com/additional/disclaimer>;.
> Mit dem Öffnen dieses E-Mails stimmen Sie Kontrons Richtlinien zur 
> elektronischen Kommunikation 
> <http://www.kontron.de/additional/rechtliche-hinweise> zu.
> By opening this email you are agreeing to Kontron's Electronic 
> Communications Policy 
> <http://www.kontron.com/additional/legal-and-copyright-information>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod