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

[Eastlake III Donald-LDE008]

Well, it doesn't seem that different from the situation with 802.1Q
bridges inserting and deleting C and S tags or 802.1AE interfaces
inserting or removing security tags or whatever.

But I guess I don't see any problem with putting in a sentence about
this.

Thanks,
Donald

PS:  :-) I suppose people that are really worried about corruption or
tampering with data inside their Rbridges should use the as yet to be
specified security option of the as yet to be fully specified option
feature...

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com] 
Sent: Monday, October 22, 2007 3:26 PM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

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