[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



So why did James Carlson's implementation break when an 802.1ad Ethernet bridge (i.e. without .1Q extensions) was put between two RBridges?  Thats what started this whole discussion...

Fact again trumps theory.

Jonathan Sadler

________________________________________
From: isis-wg-bounces at ietf.org [isis-wg-bounces at ietf.org] On Behalf Of sgai [sgai at cisco.com]
Sent: Tuesday, April 07, 2009 10:00 AM
To: Les Ginsberg (ginsberg); Radia Perlman; isis-wg at ietf.org
Cc: TRILL/RBridge Working Group
Subject: Re: [Isis-wg] [rbridge]  Why is MTU discovery important?

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

_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================