[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "RFC 2461bis" issue: MTU handling





Erik Nordmark wrote:

>>Such a capability would enhance a layer 3 neighbor MTU management 
>>capability, but it isn't required. Operators can simply have routers 
>>annouce an upper limit on the MTU that may be used on a subnet. This 
>>doesn't impede the best case scenario where all the switches support a 
>>good sized MTU. Since the number of switches per subnet is typically 
>>much smaller than the number of hosts per subnet, getting all switches 
>>to support jumboframes is significantly simpler than getting all hosts 
>>to do the same.
>>    
>>
>
>Ah - now I get where you are going with this. From my "host perspective"
>it is the switches lack of support which is the main problem - but you
>are right that the inverse problem also exists.
>
>So one approach would be something like having a router advertisement 
>option that asserts "trust us; the L2 can in fact support 9k" resulting
>in individual hosts deciding to send out an option with their NS/NA saying 
>"I can support receiving 9k".
>

Agree with the hosts sending ND messages saying:
"I can support receiving 9K" but not necessarily with the
rotuer saying "trust us; the L2 can in fact support 9k". The
router should be advertising the lowest-common-denominator
for all nodes on the link. This might be constrained by the link
with the smallest MTU, the node with the smallest receive
buffer, etc.

Nodes that can accept more than the lowest-common denominator
should negotiate a larger MTU with their neighbors - even if the
value they negotiate is larger than what is being sent in the MTU
option in RA's. (Similarly, nodes that prefer smaller than the LCD
should negotiate a smaller MTU - even though they still need to
support the LCD for broadcast/multicast.)

>Note that this is different than the default MTU being 9k - since not all
>hosts support the larger MTU everybody would still need to use the default
>1500 MTU for sending broadcast and multicast packets on the link.
>

Yes - this follows from the LCD discussion above.

>This still has the operational issue of what happens when
>I need extra ports in my office and I get a cheap 4-port hub; neither
>the IT department nor my hosts knows that this box is present and it
>might not support jumboframes. One way to cope with this particular topology,
>but no other topologies of varying frame size switches, would be
>for the host to exchange a 9k packet with the router before
>deciding that it should declare itself 9k capable.
>

You could use something like an IPv6 NS message that is artificially
inflated in size for this as we have discussed in the past. But, it's not
a once-and-done deal; if you're going to be probing the MTU you need
to do it periodically so that L2 path changes don't result in black holes.

General comment - it would be nice if folks would reveiw and comment
on my drafts:
 
  http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt
  http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt

Fred
ftemplin@iprg.nokia.com

>
>  Erik
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>  
>



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------