[rbridge] fragmentation for original ethernet frames

James Carlson carlsonj at workingcode.com
Tue Oct 12 13:37:30 PDT 2010


Joe Touch wrote:
> On 10/12/2010 11:11 AM, Vishwas Manral wrote:
>> Hi Joe,
>>
>> The issue in my view is if the forwarder is not able to accept packets
>> at the Ethernet layer above the MTU size and applications over
>> Ethernet assume at least a fixed MTU (check the size of Layer-2
>> control packets over Ethernet).
> 
> L3 checks the MTU advertised by the interface. If TRILL never changes 
> that, there's no new issue with TRILL.
> 
> If TRILL eats into the MTU (AFAICT, it does), then the interface would 
> never know.

I should know better than to jump into this discussion, as I no longer
have a horse in the race, but I think the above reflects a
misunderstanding of where TRILL is headed.

I had a discussion with Radia about this very issue some time back, and
the underlying assumption is that modern enough equipment will support
large enough oversized frames such that you should have no problem
supporting standard Ethernet MTUs plus the TRILL headers.

There are several cases to consider, but it boils down to whether you
have a traditional bridge or repeater separating two TRILL nodes in a
network, where that older device doesn't like frames that are fattened
up by TRILL.  That's what the whole MTU testing process in section 4.3.2
is about.  If you don't know for certain (based on external information)
that you've got a problem-free link to your TRILL neighbor, you can test
it, and if it fails, you can exclude it from the topology and (perhaps)
tell an administrator or human being that there's something wrong.

In other words, no, TRILL doesn't fragment, and doesn't rely on anyone
else to do so, and, yes, it does expect that all the links can support
large enough frames, and you probably shouldn't bother trying to
implement it if you can't manage at least that for your own interfaces.
 It has mechanisms (see section 4.3) that allow you to make sure that
you've got the same MTU everywhere.  In fact, it does so better than the
misbegotten FDDI/Ethernet bridges in the days of yore.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>


More information about the rbridge mailing list