[rbridge] Hop Count processing

[James Carlson]

Joe Touch writes:
> > Much better.  The "forwarding" part is the qualifier most likely to
> > confuse, and it doesn't actually change the meaning.
> 
> First, anyone who doesn't know what forwarding means is going to have a
> lot of problems implementing an rbridge.

There are at least two possible senses of "forwarding" here.  One
would be examining the TRILL header's destination nickname, finding
that it's not equal to the local system's nickname, and sending the
message on its merry way.  Another would be decapsulating the TRILL
header and then _forwarding_ the packet inside to the bridge links.

That's why I said it's likely to confuse.

And it doesn't change the meaning with respect to what Dinesh, Radia,
and I (among others) have been suggesting for TRILL.  That would be:

	- Check the Hop Count value on input, and drop the packet if
          0, *regardless* of the destination nickname.

	- When you find that the destination nickname is not your own,
          and that (due to IS-IS) you have a next hop and link for the
          destination nickname, decrement the Hop Count and forward
          the packet along without checking the new Hop Count value.

> Third, it not only changes the meaning, it changes the behavior. See the
> walkthrough in my previous mail.

The change is intentional.  The existing Hop Count behavior (as
pointed out by Dinesh) would not work if we wanted to trace the path
of packets through the network.  Altering it as suggested does support
that goal.

I agree that it's not at all like IPv4.  "Normal" hop count / TTL
processing involves ignoring the value completely at input time, and
checking it only when attempting to forward -- after determining that
the packet isn't intended for the local system.

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