Hi,
First, general observation on potential applications of this work:
1) host <-> host in a LAN setting
2) host <-> router in a LAN setting
3) router <-> router in interdomain scenario in a LAN setting (e.g.,
Ethernet IX); point-to-point scenario is trivial
4) router <-> router in intradomain cases (as Dino mentioned, IS-IS
already verifies jumbo-MTUs working in this context, manual
config is acceptable here)
4) is already problem with 80% solution so I don't think work is
needed here. 3) seems like the most important issue because it is the
actual bottleneck for in-the-network tunneling and fragmentation and
the only thing that needs to be solved for RRG's encap/decap to work
from MTU perspective. 2) and 1) seem like priority two from my
perspective at least.
That said, IMHO draft-van-beijnum-multi-mtu-02 is unnecessarily
complex. SLOWMTU and SAFEMTU provide only little benefit and are
largeley useless. RA message for scenario 2) with just MAXMTU could
be provided but even this is not required because nodes can probe up
and discover the limits even if no such thing existed.
The minimum spec would be "Jumbo-ND" and "Jumbo-ARP" where a node does
per-neighbor based probing with padded packets to discover whether
large packets work towards that neighbor (the same an on-link host or
router). If no RA used, this behaviour should probably be disabled by
default.
The generic problem with changing MTU based on dynamic information is
what happends when the state gets lost. This may result in PMTU
fluctuation, packet loss and unreliability. This needs special
attention in the design phase.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
