Re: [Isis-wg] [rbridge] Why is MTU discovery important?

[Donald Eastlake <d3e3e3 at gmail.com>]

My point was that if you are using a network heavily for some protocol
where an MTU of X is the most efficient, if there was, say, one link
with MTU Y, Y<X, it might be better to just exclude that link than to
invoke whatever mechanism the protocol has to deal with a
less-than-most-efficient MTU.

Donald

On Tue, Apr 7, 2009 at 7:22 PM, sgai <sgai at cisco.com> wrote:
> FCoE has its own MTU protection.
>
> -- Silvano
>
>
> On 4/7/09 3:01 PM, "Donald Eastlake" <d3e3e3 at gmail.com> wrote:
>
>> Keep in mind that all IS-IS messages are LSAP encoded so they are
>> limited to the classic Ethernet MTU, possibly plus VLAN and/or other
>> tags. So if, for example, you wanted to be sure you could correctly
>> handle Fiber Channel over Ethernet frames, which are bigger than that,
>> there is no way for padded Hellos to help, since they can't be padded
>> up to FCoE frame size.
>>
>> Donald
>>
>> On Tue, Apr 7, 2009 at 5:29 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>>> Radia,
>>>
>>> What I don't understand is how L3 IS-IS solves this problem. Consider a
>>> trivial topology where three routers are connected thus:
>>>             R1 --- R2 --- R3
>>>
>>> Let's say the link between R1 and R2 has an MTU, M1, and the link
>>> between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded Hellos,
>>> how is the problem of R1 sending an LSP that exceeds M2 (but not M1)
>>> handled ?
>>>
>>> Dinesh
>>> Radia Perlman wrote:
>>>> OK. It's clear we should NOT pad Hellos.
>>>>
>>>> It also seems like enough people would feel uncomfortable with not doing
>>>> MTU discovery that we should make
>>>> sure there is a mechanism for that also.
>>>>
>>>> So can we focus for a minute on the following question, "whether to make
>>>> MTU size a forever constant,
>>>> or configurable in a campus", as described below.
>>>>
>>>> The simplest option is to pick some minimum size, say 1450 bytes, put
>>>> that in the spec now, and forever
>>>> say that TRILL Hellos and LSPs cannot be bigger than that.
>>>> MTU discovery would be done to ensure that
>>>> every link can handle 1450 bytes, and not use (not report in LSPs) links
>>>> that can't handle that.
>>>>
>>>> However, my preference is to have an optional TLV in the LSP that says
>>>> "campus-wide MTU size". This TLV
>>>> would only be relevant if:
>>>> a) it is larger than 1450, and
>>>> b) it is in the LSP of the highest priority RBridge in the campus.
>>>>
>>>> If we put that in, then we would be enabling TRILL campuses that support
>>>> jumbo frames.
>>>>
>>>> The rule is that if the highest priority RBridge says MTU size should be
>>>> 10000 bytes, then all RBridges would adjust
>>>> their buffer sizes, and test their adjacencies to ensure they could
>>>> handle 10000 bytes, and if they don't
>>>> then stop reporting those links (just like they would with the simpler
>>>> proposal if the links
>>>> couldn't support 1450).
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>
>>> --
>>> We make our world significant by the courage of our questions and by
>>> the depth of our answers.                               - Carl Sagan
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>
>>
>
>



-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com