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

[Eastlake III Donald-LDE008]

Sorry, my smiley was in connection with the "not yet specified"ness, not
to say that corruption isn't a serious problem when it occurs. At
transit Rbridges, TRILL data frames can normally be transmitted
unchanged from how they are received, including the FCS, or with only a
change in VLAN (or possibly priority) for which the FCS adjustment
shouldn't be too hard.

Donald 

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com] 
Sent: Monday, October 22, 2007 4:25 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:
> 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