Re: please read and comment on the MTU problems in draft-liu-rtgwg-mtu-config-ps

Hi Acee,

Which is exactly my point, folks who run OSPF would also benefit :)
Would be great to have a document similar to
draft-ietf-pwe3-vccv-impl-survey-results perhaps with vendor's names in it.

Cheers,
Jeff

-----Original Message-----
From: Acee Lindem Lindem III <acee.lindem@ericsson.com>
Date: Saturday, July 27, 2013 12:36 PM
To: Jeff  Tantsura <jeff.tantsura@ericsson.com>
Cc: "<curtis@ipv6.occnc.com>" <curtis@ipv6.occnc.com>, "rtgwg@ietf.org"
<rtgwg@ietf.org>
Subject: Re: please read and comment on the MTU problems
in	draft-liu-rtgwg-mtu-config-ps

>Hi Jeff - This is true. Most OSPF implementations provide an option to
>override the checking. However, I feel this is ill-advised as you can
>have adjacencies that are fine until there is a flap and the side with
>the larger MTU starts sending maximum size OSPF packets which the other
>side doesn't receive. The check was added due to all the MTU problems
>with ATM Emulated LANs where the ATM Forum chose different MTUs than the
>emulated LANs. 
>Acee 
>
>On Jul 27, 2013, at 12:38 PM, Jeff Tantsura wrote:
>
>> Curtis,
>> 
>> In any known OSPF implementation if MTU on both sides doesn't match
>>OSPF will get stuck in Exchange/Exstart.
>> 
>> Regards,
>> Jeff
>> 
>> On Jul 27, 2013, at 5:29 PM, "Curtis Villamizar"
>><curtis@ipv6.occnc.com> wrote:
>> 
>>> 
>>> In message 
>>><CAG4d1rdzpGFLw1Z1XFRYgh2J1TSYS0VLbN4VmsQTLKZ3-tVzpQ@mail.gmail.com>
>>> Alia Atlas writes:
>>> 
>>>> We are likely to add this draft to the list to be discussed in the
>>>> meeting.  It is discussing some general problems with MTU
>>>> configuration between vendors.  While it discusses this for ISIS,
>>>> some aspects also apply to OSPF.
>>>> 
>>>> Basically, there are three problems:
>>>> 
>>>> a) Some implementations use L2 MTU and others use the L3 MTU
>>>> b) Different implementations pad and check for different lengths.
>>>>  Consequences are that ISIS sessions do not make it to Up.
>>>> c) Different numbers of MPLS labels are assumed as the max, resulting
>>>>in
>>>>  fragmentation, and there are generally no controls for it.
>>>> 
>>>> http://datatracker.ietf.org/doc/draft-liu-rtgwg-mtu-config-ps/
>>>> 
>>>> Thanks,
>>>> Alia
>>> 
>>> 
>>> First of all, the IGP issue is unique to ISIS and should be fixed in
>>> ISIS.  ISIS pads the LSPDU fragment to the full MTU to verify that the
>>> full MTU is supported.  THis is a misfeature IMHO, but that is the way
>>> it is.  OSPF does not have this misfeature.
>>> 
>>> The reason that ISIS does this is that IP fragmentation at full line
>>> rate is considered hard to do for high line rates relative to IP
>>> forwarding.  Some **very** old routers did this in software and would
>>> crash if you gave them a full line rate load of packets to fragment.
>>> The ISIS practice of padding to full MTU predated the existance of
>>> MPLS and any use at all of VLAN by providers (who still rarely use
>>> VLAN and probably never in core).  Many routers today can fragment at
>>> full line rate or close to it for average packet sizes (not
>>> tinygrams).  Some can't, but if the rate is very low, they should be
>>> avoided.  Providers need to test for this.  In modern networks, if
>>> most packets are 1532 or smaller, whether the MTU is somewhat over 4K,
>>> somewhat over 8K, or closer to 9K makes no difference.
>>> 
>>> TCP has Path MTU Discovery (PMTU) which uses the IP "Do Not Fragment"
>>> bit and looks for the ICMP Would Fragment packets as a hint to lower
>>> the MTU.  ISIS could do the same.
>>> 
>>> Note: Using TCP PMTU has an issue with some (broken IMHO) firewalls
>>> blocking all ICMP, rather than just blocking forms of ICMP that might
>>> be in some way dangerous.  This problem can be avoided by sending only
>>> some packets with "Do Not Fragment" and using SACK to figure out that
>>> those are consistently getting lost (and not counting that as a drop
>>> but rather as an indication to lower the TCP MSS value).
>>> 
>>> Instead of trying to figure out the *right* value to configure, the
>>> ISIS protocol needs to get smarter about dealing with different values
>>> of MTU, including small variations created by encapsulation in MPLS.
>>> 
>>> IMHO this should be resubmited as a problem statement to the ISIS WG.
>>> 
>>> Most providers have already figured out what *they* need to configure
>>> as the MTU on their links and do so by using either program generated
>>> router configurations or using programs to check router configurations
>>> for some level of consistency.  BTW- the 4470 number dates back to POS
>>> wanting to have a larger MTU than FDDI.
>>> 
>>> As far as configuring a value of 4470 on all routers without ISIS
>>> changes, the provider must first read the vendor literature to find
>>> out what is counted in the MTU, layer-2 MTU or layer-3 MTU and figure
>>> out whether further encapsulation will impact the effective MTU.
>>> Looking at the default value provides a good hint.
>>> 
>>> If all the traffic coming into a network is at 1532 MTU (or something
>>> in that range) and the provider just wants headroom for PW and other
>>> labels, whether the MTU on some links is 4470 or 4484 (or 9180) makes
>>> no difference at all.  Therefore inconsistencies in values over about
>>> 1600 make no difference at all for such a provider.  A control packet
>>> here or there might get fragmented but everything (except ISIS) should
>>> work with minor inconsistencies in the configured MTU.
>>> 
>>> Curtis
>>> _______________________________________________
>>> rtgwg mailing list
>>> rtgwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>