[rbridge] Trivial question about FCS in Figure 3 of current protocol draft

[James Carlson]

Eastlake III Donald-LDE008 writes:
> The FCS is commonly something that's buried in the port hardware and
> gets generated at the time of or just before frame transmission and
> checked at the time of or just after receipt and sometimes doesn't exist
> in the interior of a bridge/Rbridge.
> 
> Since Figures 3 and 7 say they are a frame as it appears on the wire,
> which is what IETF protocol descriptions are normally interested in, one
> and only one FCS should be shown.

I'm not sure that the question or the answer are 'trivial' here.

In a regular (non-VLAN) bridge, the FCS is normally preserved
end-to-end, so that it protects the frame in transit from molestation
by intermediate bridges.  This is why RFC 3518 (PPP Bridging) contains
a LAN Frame Checksum Preservation feature.

With VLANs, this is no longer true, and corruption introduced by an
intermediate malfunctioning bridge was in fact the cause of a
significant network outage at Sun several years ago -- so I think it's
not a trivial matter to commit to non-preservation of FCS.

All that said, I agree with the current plan: there's a single
medium-dependent FCS, checked and regenerated at hop, and thus no
protection of the frame contents while resident in system memory of
one of the intermediate bridges.  Adding an option (sigh!) for
end-to-end preservation would be nice, but may well be fighting an
uphill battle in terms of functionality and compexity.

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