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]> 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]> 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]> wrote: > >> >> On Jul 25, 2013, at 8:35 AM, Alia Atlas <[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] > https://www.ietf.org/mailman/listinfo/rtgwg > > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
