Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I am not sure L2 MTU is common attribute applicable to all packet frame based interface, in most case, we are using L3 MTU. #23

Closed
rgwilton opened this issue Aug 22, 2019 · 1 comment

Comments

@rgwilton
Copy link
Contributor

WG Last Call: draft-ietf-netmod-intf-ext-yang-07, Qin reviiew issue 4)

I am not sure L2 MTU is common attribute applicable to all packet frame based interface, in most case, we are using L3 MTU.

From the definition of L2 MTU
" A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the maximum size of a layer 2 frame that may be transmitted or received on an interface. "
I am wondering this L2 MTU is related to Maximum Receive Unit defined in RFC4638. If the answer is YES, I would suggest to rename it, but it is still not clear whether it should be An common attribute part of ietf-interfaces-common.
If it is No, I am wondering why L2 MTU is not augmented from IP address management module which define common MTU attribute, also it is not clear to me if ietf-interfaces-common Is positioned as technology specific model? When we choose to use MTU defined in RFC8344 and when we should choose to use L2 MTU defined in draft-ietf-netmod-intf-ext-yang-07.
I think L3 MTU is common and widely deployed and supported by most of implementations. But go to L2 MTU:
"
The payload MTU available to higher layer protocols is either derived from the layer 2 MTU, taking into account the size of the layer 2 header, or is further restricted by explicit layer
3 or protocol specific MTU configuration."; "
You add a lot of flexibility or multiple options, therefore I think it is hard to implement it.

@rgwilton
Copy link
Contributor Author

rgwilton commented Nov 5, 2019

This is really a duplicate issue to #18 and can be tracked there.

@rgwilton rgwilton closed this as completed Nov 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant