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

[sgai <sgai at cisco.com>]

Let me remind you that the current charter of TRILL is only Ethernet and not
other media. In Ethernet a payload of 1500 bytes is guaranteed.

If we want to be paranoiac and consider old broken devices, let put a limit
at 1400 bytes.

-- Silvano


On 4/7/09 2:13 AM, "Les Ginsberg (ginsberg)" <ginsberg at cisco.com> wrote:

> Radia -
> 
> The point of hello padding is not just to "discover the MTU" but to not
> form adjacencies with neighbors who are incapable of receiving/flooding
> the max size LSP any router in the area/domain might generate.
> 
> I haven't caught up on the details of Jim's testing, but if the padded
> hellos can't get through then similar sized LSPs won't either - and
> routing is broken - so sending smaller hellos isn't going to help - and
> in fact is likely to obfuscate things because routing may work at first,
> but as additional information is added to an LSP it will become too
> large to be flooded everywhere and things will break w/o any clear
> indication of why.
> 
>     Les
> 
>> -----Original Message-----
>> From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On
> Behalf
>> Of Radia Perlman
>> Sent: Monday, April 06, 2009 3:44 PM
>> To: isis-wg at ietf.org
>> Subject: [Isis-wg] Why is MTU discovery important?
>> 
>> For those of you not monitoring the TRILL mailing list:
>> 
>> Jim Carlson, in testing his TRILL implementation, noticed that the
>> padded Hellos caused RBridges not to discover each other.
>> That's real bad in TRILL, though it's OK in layer 3 IS-IS.
>> 
>> So, we'd like to just say in TRILL "don't pad Hellos".
>> 
>> But that eliminates IS-IS's MTU discovery mechanism. We had a proposal
>> for doing that, but some people said
>> "why bother"?
>> 
>> The reasoning is that it's not clear what an RBridge would do if the
> MTU
>> isn't what it would expect, and that
>> it seems like you'd need a campus-wide agreed-upon MTU size in order
> to
>> make sure LSPs would get through on
>> every link. The solutions being proposed involved agreeing upon a
>> campus-wide MTU size, testing MTU size on
>> each adjacency through some as-yet-to-be-defined protocol, and not
>> reporting links that don't meet
>> that MTU size.
>> 
>> Obviously ignoring the MTU issue, and just making sure Hellos get
>> through by not padding Hellos, is a nice simple proposal.
>> 
>> What would we be giving up if we ignored MTU discovery entirely?
>> 
>> Radia
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg at ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge