[rbridge] Hop Count processing

[James Carlson]

Joe Touch writes:
> That's solved easily by referring to the former as forwarding the TRILL
> packet.
> 
> 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
point.

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

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.

Exactly.

(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
work.)

> 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
past there?

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