[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] [rbridge] Why is MTU discovery important?
James,
The point that I was making in my last email, was to have a uniform MTU
size on all Ethernet links in the network (both TRILL & c-bridged net)
in order to avoid fiddling with is-is hello/mtu discovery procedures and
the two options are:
A) require bridges (both Rbridges and c-bridges) to support
maxEnvelopeFrameSize of 2000 as in 802.3 spec.
B) lower the default MTU size originatingLxLSPBufferSize to accommodate
for the 24 bytes of TRILL overhead
The advantage of option (A) is that, it works for both control & data;
however, its disadvantage is that it requires all gears to support this
max MTU size which is easier said than done as you rightly pointed out.
The advantage of option (B) is that it works with existing deployed
gears but it only works for is-is control messages and not data, right?
If the objective is to use TRILL control protocol to enable a single
designated forwarder per VLAN on the multi-homed c-bridged network and
only send/receive .1Q frames to/from c-bridged network (e.g., w/o TRILL
encap), then option (B) should be sufficient.
Cheers,
Ali
> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at Sun.COM]
> Sent: Thursday, April 16, 2009 5:15 AM
> To: Ali Sajassi (sajassi)
> Cc: Les Ginsberg (ginsberg); Sadler, Jonathan B.;
> TRILL/RBridge Working Group; Silvano Gai (sgai); Radia
> Perlman; isis-wg at ietf.org
> Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?
>
> Ali Sajassi (sajassi) writes:
> > So, a simple fix to this problem is to put a simple text in
> the TRILL
> > spec mandating that all Ethernet links to support 802.3as
> > maxEnvelopeFrameSize. This way, you don't need to do any
> fiddling with
> > IS-IS protocol.
>
> That simple fix assumes that every equipment vendor of every
> box located _between_ the RBridges is somehow compelled to
> comply with the new specification.
>
> That's perhaps fine as a matter of specification, but in the
> real world, it doesn't work like that. Writing a new
> requirement on paper doesn't cause the firmware or hardware
> in those boxes to get updated, which means that it *is*
> necessary to detect and cope with failures.
>
> > Furthermore, as Les mentioned, if the link can send some
> small sized
> > frames but not some other larger frames, then besides control plane
> > issues, you will have dropped frames in customer data which is not
> > acceptable - e.g., a service that can work for some frame
> size but not
> > some other ones !!
>
> Yes, that's why MTU discovery is itself also important.
> Detecting and avoiding loops is *MORE* important, but as you
> rightly note, it's not sufficient.
>
> > So to have a simple solution with a consistent and deterministic
> > behavior, we should expect that all Ethernet links behave the same
> > (e.g., they all support 802.3as).
>
> I can't build a deployable system like that. The first
> obvious question for any user or design reviewer is, "so,
> what happens if your expectation is not met?" The answer
> can't possibly be that the target network goes down in a hail
> of replicated packets.
>
> We're building systems, not just specifications.
>
> --
> James Carlson, Solaris Networking
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive 71.232W Vox +1
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1
> 781 442 1677
>