[rbridge] Hop Count processing
james.d.carlson at Sun.COM
Mon Jun 1 08:56:19 PDT 2009
Joe Touch writes:
> That's solved easily by referring to the former as forwarding the TRILL
> Further, bridges don't forward segments; they switch them (i.e.,
> forwarding is usually a L3 term), so the final step would be a
> "decapsulate and switch" operation, but as I noted, that is solved above.
Not per the standards. 802.1D calls this "forwarding" and "switching"
sounds like marketing to me ... but I guess I don't care to argue the
> By removing 'forwarding' from the language I proposed, Radia removed
> behavior that happens only at TRILL forwarding steps - which is what
> you've just described.
Yes; just explaining the idea.
> >> Third, it not only changes the meaning, it changes the behavior. See the
> >> walkthrough in my previous mail.
> > The change is intentional.
> Well, you said (and I disagreed) that:
> " The "forwarding" part is the qualifier most likely to
> confuse, and it doesn't actually change the meaning."
> My point is that it DOES change the meaning. It is clearly important to
If you include it, and if it does mean something, then it breaks the
proposal that Radia, Dinesh, and others are putting forward.
> > 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.
> Please explain that, and use an example that shows hopcounts for
> ingress-egress paths that include 0, 1, and 2 rbridges (as I have
For ingress sending directly to egress, you'd send with a Hop Count of
0, and the target would detect this as a drop condition on input and
reply. Higher hop counts would not return.
For ingress sending through one TRILL hop to the egress, you'd send
with Hop Count of 0, get a response from the hop node, then send with
1, and get a response from the destination (final) node as above.
For higher numbers, prove by induction.
> > 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.
> That second step is required anyway. Why is it important to consider
> hopcount for packets that have already been received? That seems to say
> "OK, we limit the hops in a network, but drop you if your hopcount is
> wrong even if you've made it to the destination".
Yes, that's exactly what Dinesh is proposing.
> Why is that useful for traceroute?
It allows us to capture a drop at the last hop.
(Dinesh insists that it's also how routers have "always" worked, but I
have my doubts about that.)
> (I'm guessing that one of you thinks that we can get away without a
> "ping" message, i.e., that we can trace regular packets.
(Of course, without an actual traceroute-for-TRILL proposal in front
of us, it's hard for me to argue that this is in fact how it should
> That won't
> work, however, if the egress rbridge has more than one egress address,
> as I discussed.)
I don't follow. A TRILL "traceroute" can't see anything past the
TRILL destination node, so who cares how L2 is forwarded^Wswitched
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
More information about the rbridge