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

[James Carlson]

Eastlake III Donald-LDE008 writes:
> 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.

It's not.  That's exactly why I said:

  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 guess I don't see any problem with putting in a sentence about
> this.

OK; thanks.

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

I know you have a smiley there, but the lingering concern is about
message integrity being compromised by inadvertent errors rather than
protection from some sort of active attack.  End-to-end preservation
of FCS does provide protection against simple blunders.  Regeneration
at each node does not.

I wouldn't have made as big a deal out of it if we hadn't had our own
frightening run-in with the problem.  We had a "switch" (bridge) that
enjoyed flipping bits every once in a while on large packets.  The
fact that it computed a new FCS on entry into the VLAN (addition of
802.1Q header) meant that the failure was hard to find and nasty in
character.

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