Hi Bob, Iljitsch, On Sat, 23 Jul 2005 17:17:25 -0700 Bob Hinden <[EMAIL PROTECTED]> wrote:
> Iljitsch, > > At 05:57 PM 07/22/2005, Iljitsch van Beijnum wrote: > >On 22-jul-2005, at 22:18, Bob Hinden wrote: > > > >>In my personal view, having devices on shared media with different > >>MTU's is just a bad idea. Trying to get it to work is complicated > >>and I think it will have lots of nasty failure cases. If one wants > >>to have mixed speeds (like the example above) then use the default > >>MTU (i.e., 1500) or replace the GbE-Switch with a Router. If one > >>wants Jumbo Frames, then make sure all of the nodes on the link > >>support 1000Base-T. > > > >Unfortunately 1000baseT (is that the correct designation?) doesn't > >equal jumboframe capability, so the problem remains. > > Right, I don't know what the correct designation is either. > > >Don't forget that management issues in layer 2 networks (= a single > >layer 3 subnet) are very different from those on the global internet: > >most layer 2 networks are managed by a single organization. Since we > >had the hubris to think we could do PMTUD for the global internet, I > >think we shouldn't shy away from doing the same thing for layer 2. As > >always, the operator community will decide wheter what we come up > >with is usable in practice. > > Fair point. As suggested on the list a new NA/NS option seems like a > reasonable approach except for the problems pointed out. Having to do > probes of different packet sizes is fairly messy if there is a device in > the middle with a smaller MTU. Would a NA/NS option solution solve enough > of the problem to make doing it worthwhile? > 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. 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 (i.e., along the lines that this MTU value has been announced because the link layer technology doesn't have a standard value e.g. token ring. 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). These mechasims only come into play if non-standard MTU support has been enabled (in some mechanism specific manner, which may be via a new RA option, or even just configuring larger, non-standard MTUs on the interfaces that are capable of larger frames). The out-of-the-box plug-and-play IPv6 functionality that exists today will be preserved if these mechanisms aren't enabled, by all nodes using the link standard MTU or RA announced MTU. I think this solution would be relatively quick and simple to develop, and is applicable to any networks that have been specifically designed to support larger, non-standard MTUs. (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, Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin in draft-templin-ipvlx-02.txt. 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. Any thoughts on this approach ? Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
