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

[Alia Atlas <[e-mail]>]

I've added it to the RTGWG agenda.  Please continue to discuss and think
about what, if any, desired outcome there is...

Volunteers as well as opposed to merely commenting  would be helpful.

Alia


On Sun, Jul 28, 2013 at 6:20 AM, Jeff Tantsura
<[e-mail]>wrote:

> 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 <[e-mail]>
> Date: Saturday, July 27, 2013 12:36 PM
> To: Jeff  Tantsura <[e-mail]>
> Cc: "<[e-mail]>" <[e-mail]>, "[e-mail]"
> <[e-mail]>
> 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"
> >><[e-mail]> wrote:
> >>
> >>>
> >>> In message
> >>><[e-mail]>
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtgwg
> >> _______________________________________________
> >> rtgwg mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtgwg
> >
>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
>