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

[James Carlson]

Eastlake III Donald-LDE008 writes:
> Another strategy is to keep the FCS on admitting a frame and whenever
> you delete, insert, or change anything in the frame during processing to
> do a compensating adjustment to the FCS, then transmit this modified FCS
> with the frame.

That's a tall order with insert or delete, though there seem to be
(encumbered) mechanisms available.  I suspect that most
implementations will simply recompute unless a suitable adjustment
algorithm is suggested as part of the final document.

> This alternative to generating it from scratch when the
> frame leaves the bridge/Rbridge would have a reasonable chance of
> detecting something like memory corruption within the device.

Sure.  I doubt that we'll see this in practice, though, and I think we
need to be aware that what we are really endorsing here is breaking
the end-to-end CRC argument for Ethernet subnetworks.  That's not
necessarily a horrible thing, in as much as most VLAN-capable bridges
already do this today, but still a knowing choice.

> But I don't think we should say anything about which strategy Rbridge
> implementations use other than requiring them to send frames with
> correct FCS values and discard received frames with bad FCS values. 

In as much as it affects the correctness of the bits on the wire, I
think mentioning the risks of the regeneration issue is in scope for
this document.  It's as much in-scope as it was to create an option to
_avoid_ the very same problem in RFC 3518.

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