On 26-jul-2005, at 4:41, Mark Smith wrote:
I'd like to suggest a two phased development approach, based on
whether
layer 2 can be assumed to fully support the larger MTUs or not (I
think
the following is also probably a summary of the couple of threads of
discussion in the emails of the last couple of days) :
(1) Making the assumption that layer 2 can support larger, non-
standard
MTUs (as it has been engineered to by a network designer), develop
mechanisms that allow nodes to announce their non-standard, larger MTU
support. If a pair of nodes find they both support larger MTUs/MRUs,
then they'll take advantage of it for unicast traffic. If the unicast
communcations fails because layer 2 doesn't support the MTU/MRUs it is
supposed to, then layer 2 is broken and it is up to network admin to
fix it.
You mean: if I hook up two hosts that support 9k jumboframes to a
cheap unmanaged 10/100 switch (all out of the box) and it doesn't
work, I have to go in and reconfigure the hosts so it does work?
Sorry, but that's not acceptable.
And the case where I have to enable jumboframes on the hosts and then
everything fails because the switch can't handle it is barely usable.
It allows for jumbo and non-jumbo capable hosts to live on the same
subnet, which is an important advantage, but it's still extremely
fragile for no good reason.
What we need in addition to this would be (as outlined in my message
to Bob):
- a mechanism to distribute the MTU for the layer 2 network to jumbo-
capable systems
- validation that jumboframes indeed work to minimize the impact of
misconfiguration
In all other cases (eg. multicast, unicast without these
announcements),
the MTU used will be the either the link layer MTU standard or the
link
MTU value as announced in RAs
Right.
There is a corner case that needs to be
covered where a larger than standard MTU has been annnounced for a
technology that does have a fixed MTU e.g. 1500 byte ethernet, and a
sub-set of nodes only support the standard size).
If the nodes announce their MTU/MRU in neighbor advertisements this
isn't a problem: jumbo-capable hosts wouldn't send jumboframes to
neighbors that don't support them.
These mechasims only come into play if non-standard MTU support has
been
enabled
Yes, this is important.
(in some mechanism specific manner, which may be via a new RA
option,
Suboptimal because switches can't easily do this.
or even just configuring larger, non-standard MTUs on the
interfaces that are capable of larger frames).
Very suboptimal because it requires manual configuration of all nodes.
The out-of-the-box
plug-and-play IPv6 functionality that exists today will be
preserved if
these mechanisms aren't enabled,
Yes, and the destructive potential of nuclear bombs is mitigated if
you don't detonate them... This is 2005 and IPv6. Autoconf is the
word, is the word that you heard. It's got groove, it's got meaning.
Autoconf is the time, is the place is the motion. Autoconf is the way
we are feeling.
(2) Develop mechansisms that can dynamically discover MTU/MRU sizes,
limitations and variations over time, including within intermediary
layer 2 devices e.g., switches. It seems that some solutions have
already started to be developed in this area, including the email
discussion between Iljitsch and Perry,
:-)
We can certainly experiment with this while we roll out the more
conservative approach.
Matt Mathis in
draft-ietf-pmtud-method-04.txt and Fred Templin in
draft-templin-ipvlx-02.txt.
I don't really see how those apply.
If the above phased approach is followed, I think it would be
useful to
allow any ND or other options developed for phase 1 to be re-used
for a
phase 2 solution if they can.
Of course.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
