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 protected]<mailto:[email protected]>> 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... Point is to have the discussion. Alia On Jul 25, 2013 1:54 PM, "Carlos Pignataro (cpignata)" <[email protected]<mailto:[email protected]>> 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? 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 protected]<mailto:[email protected]>> 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 P.S. Thanks for the quick reading and response! On Thu, Jul 25, 2013 at 12:04 PM, Tony Li <[email protected]<mailto:[email protected]>> wrote: On Jul 25, 2013, at 8:35 AM, Alia Atlas <[email protected]<mailto:[email protected]>> 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. > > 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/ 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 _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
