Hi All
Thanks for the recent reply and discussion. Meantime, I’m a newcomer to IETF,
Thanks to
everybody for your kind comment and help.
I think the current discussion can be
summarized as:
1, The purpose of the draft and point of
our discussion.
>>The
MTU configuration among multi-vendor networks is a problem that we found on
network operation and interoperability. So we want to use our observation to
arouse everyone’s attention on this issue. Meantime, we hope that we can reach
a common consensus on MTU configuration
by the discussion.
2, Excising analysis of MTU configuration document.
>>Thanks everybody put forward many constructive
comments. There are lots of vendor document on this issues. However, during our
network operation, it’s easy to cause interoperability problem by mismatch the
MTU
between two different vendor. Moreover, it’s easy to cause fragment by
misunderstanding and miscalculating of MTU configuration. I wonder it's not
easy to 'unified' the configration. But through our discussion, make this issue
more clear and output a multi-vendor operation guideline on MTU configuration
can be workable.
3, The size of label stack.
>>the
label stack in MPLS MTU do cause fragmentation, somehow it will cause
interoperability problems by mismatch MTU in OSPF.
Thanks
to everyone again for comments!
All the
Best!
Vic
> From: [email protected]
> To: [email protected]
> Subject: Re: please read and comment on the MTU problems in
> draft-liu-rtgwg-mtu-config-ps
> Date: Sat, 27 Jul 2013 16:38:18 +0000
> CC: [email protected]
>
> 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" <[email protected]>
> wrote:
>
> >
> > In message
> > <cag4d1rdzpgflw1z1xfrygh2j1tsys0vlbn4vmsqtlkz3-tv...@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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rtgwg
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
