Hi,

draft-ietf-netmod-intf-ext-yang-07, in WGLC, defines just such an MTU config 
item (called l2-mtu).

This is currently defined as a uint16, but perhaps this could/should be defined 
as uint32 instead.

Thanks,
Rob


-----Original Message-----
From: Vladimir Vassilev <[email protected]> 
Sent: 15 July 2019 00:07
To: Peter Schneider <[email protected]>; [email protected]; 
[email protected]
Subject: Re: [netmod] Question regarding RFC 8344

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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to