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]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to