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

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Jul 2013 11:35:28 -0400

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

---

From: Tony Li <[email-masked]>
Date: Thu, 25 Jul 2013 09:04:10 -0700

On Jul 25, 2013, at 8:35 AM, Alia Atlas <[email-masked]> wrote:

> 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.
> 
> 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.
> 

I'm interested in understanding what the authors would like to see from this.   It would be well outside of the IETF's charter to say that implementations must configure MTU in only one manner.

At best, I see this document as saying 'be consistent', which seems like spitting upwind.

Tony

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Jul 2013 12:19:14 -0400

Yes - my thought is perhaps a BCP??  It's clearly an interoperability
problem.  What is interesting is to discuss the issue and see what could be
done.

Alia

P.S.  Thanks for the quick reading and response!

On Thu, Jul 25, 2013 at 12:04 PM, Tony Li <[email-masked]> wrote:

> > 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.
> >
> I'm interested in understanding what the authors would like to see from
> this.   It would be well outside of the IETF's charter to say that
> implementations must configure MTU in only one manner.
>

---

From: brad dreisbach <[email-masked]>
Date: Thu, 25 Jul 2013 12:27:10 -0400

> problem.  What is interesting is to discuss the issue and see what could be

I think an informational rfc/draft outlining the differences in implentations 
would be more appropriate than a BCP.

> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 25 Jul 2013 17:54:25 +0000

Alia,

The fact that different vendors use different interpretations of "MTU" in a configuration interface (some L3, some L2 (with/without FCS)) is well known and accounted for while configuring. Many of those config interfaces show "hardware mtu", "protocol mtu", and other proxies for naming labels to imply which encaps included. There seems to be lots of publicly available documentation about this.

I was also wondering what the expected output or goal is. Would publishing an RFC achieve the goal stated in the I-D?

   for all vender to standardize the MTU configuration in IP
   network and MPLS network.

Or are existing RFCs + vendors' documentation + discussion lists archives enough?

Thanks,

-- Carlos.

On Jul 25, 2013, at 12:19 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Yes - my thought is perhaps a BCP??  It's clearly an interoperability problem.  What is interesting is to discuss the issue and see what could be done.

Alia

On Thu, Jul 25, 2013 at 12:04 PM, Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

Tony

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Jul 2013 14:24:39 -0400

Carlos,

I'm not surprised that there is lots of vendor documentation.  It's
something that has been around for a while.   The question is whether there
is anything that might benefit from documentation.   The size of label
stack, in particular,  might be interesting...

Point is to have the discussion.

Alia
On Jul 25, 2013 1:54 PM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

>  Alia,
>
>  The fact that different vendors use different interpretations of "MTU"
> in a configuration interface (some L3, some L2 (with/without FCS)) is well
> known and accounted for while configuring. Many of those config interfaces
> show "hardware mtu", "protocol mtu", and other proxies for naming labels to
> imply which encaps included. There seems to be lots of publicly available
> documentation about this.
>
>  I was also wondering what the expected output or goal is. Would
> publishing an RFC achieve the goal stated in the I-D?
>
>  On Jul 25, 2013, at 12:19 PM, Alia Atlas <[email-masked]> wrote:
>
>> > c) Different numbers of MPLS labels are assumed as the max, resulting
>> in fragmentation, and there are generally no controls for it.
>> >

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 25 Jul 2013 19:31:43 +0000

Alia,

Would be great to have documented how different vendors interpret MTU, btw most also have implemented different flavors of "ignore mtu" knobs for their IGPs.
Both informational or BCP would do.

Regards,
Jeff

On Jul 25, 2013, at 8:24 PM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

I'm not surprised that there is lots of vendor documentation.  It's something that has been around for a while.   The question is whether there is anything that might benefit from documentation.   The size of label stack, in particular,  might be interesting...

Alia

On Jul 25, 2013 1:54 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:
Alia,

Thanks,

-- Carlos.

Alia

Tony

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Jul 2013 00:58:27 +0000

Hi, Alia,

On Jul 25, 2013, at 2:24 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

I'm not surprised that there is lots of vendor documentation.  It's something that has been around for a while.   The question is whether there is anything that might benefit from documentation.

Yes, I agree. If the goal of the effort is to document existing inconsistencies, my initial reaction is that those are well documented already outside the RFC series, and generally well known. On the other hand, I do not think that an analysis of the issue will cause harm, of course, and can result in a reference of use. However, the excerpt I included below states a different goal, which I do not think is realistic, practical, or backwards-compatible :-)

If the document would aim at cataloging different ways of configuring MTU and warning users about what commands mean, I would also find more value in an analysis of MTU configuration requirements (1812/1122/ospf/isis) in addition to the mostly empiric approach.

   The size of label stack, in particular,  might be interesting...

I agree that the size of the label stack is interesting -- but I sense that this is a bit of a rathole and orthogonal to MTU configuration for an OSPF adjacency to come up. It does cause fragmentation potentially but not interoperability problems. I wonder if the size of the label stack is/should be included in draft-ietf-mpls-forwarding.

Exactly. This is my small contribution to it. :-)

Thanks!

-- Carlos.

Alia

Thanks,

-- Carlos.

Alia

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 27 Jul 2013 11:27:14 -0400

In message <[email-masked]>
Alia Atlas writes:
 
>  meeting.  It is discussing some general problems with MTU
>  configuration between vendors.  While it discusses this for ISIS,
>  some aspects also apply to OSPF.
>  

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

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 27 Jul 2013 16:38:18 +0000

Curtis,

In any known OSPF implementation if MTU on both sides doesn't match OSPF will get stuck in Exchange/Exstart. 

Regards,
Jeff

---

From: Acee Lindem <[email-masked]>
Date: Sat, 27 Jul 2013 19:36:59 +0000

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

---

From: LiuVic <[email-masked]>
Date: Sun, 28 Jul 2013 09:21:17 +0000

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-masked]
> To: [email-masked]
> 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-masked]
> 
> Curtis,
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 28 Jul 2013 10:20:37 +0000

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 <[email-masked]>
Date: Saturday, July 27, 2013 12:36 PM
To: Jeff  Tantsura <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>, "[email-masked]"
<[email-masked]>
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 
>
>>> In message 
>>><[email-masked]>
>>> Alia Atlas writes:
>>> 
>>>>in

---

From: Alia Atlas <[email-masked]>
Date: Sun, 28 Jul 2013 07:29:45 -0400

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