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

[sgai <sgai at cisco.com>]

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
>> 
> 
>