Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06

[Joe Touch <[e-mail]>]

Here's a quick summary - it's not thorough enough to post as a TSVART
review, though.

Joe

------

This document describes a mechanism to discover the MTUs of what
transport considers a link layer, notably when its links can support
messages larger than the IPv4 and IPv6 minimums.

This document focuses on link MTUs. It considers fragmentation and
reassembly only for E-L1CS FS-LSP, which is effectively an application
layer protocol running directly over the link layer.

It isn't clear to me whether this doc is applying INT-area best
practices or terminology correctly, but this is a TSV review.

IMO, this doc should be more clear that it is determining a "link layer"
value, which is not necessarily related to the network layer MTU (which
is determined by the receiver's reassembly limit) or the transport MTU
(which depends on whether transport uses the network reassembly MTU,
link hop MTU, or some other transport reassembly limit).

IMO, the doc should also be more clear about what to do with this
information - i.e., that it updates the "link MTU", which may or may not
be propagated up the stack.

I'm a bit uncomfortable with "link MTU size SHOULD be tested, in Sec 2.1
- especially because that recommendation comes after showing a case
where the link MTU is calculated incorrectly. IMO, before a link
overrides the default MTU, it **MUST** be confirmed BEFORE changing it -
especially because network and transport mechanisms to track MTU often
assume that link MTUs do not change (for a given link) and that they are
reported correctly.

I.e., overall, I would suggest that the impact of this doc on MTU
discovery and use should be included.

Other issues:

- the term "port MTU" is introduced in 2.1 but never defined
- I don't agree with the security considerations conclusion; this
appears to create a new attack vector (report false MTUs to create black
holes).

Joe