Hi, Alia, On Jul 25, 2013, at 2: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. 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. Point is to have the discussion. Exactly. This is my small contribution to it. :-) Thanks! -- Carlos. 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
