[rbridge] Hop Count processing

[James Carlson]

Joe Touch writes:
> > You'd pick the MAC address of the interface over which you received
> > the frame.
> 
> What if there are multiple such addresses (i.e., MAC overloading)?

Who cares?

How is that any different from having potentially multiple addresses
on a link at _any_ point in the middle of the path with multiple TRILL
hops?

I would argue that -- if this is actually an issue for any real
implementation (I don't know that it is) -- then it's a generic
issue.  The TRILL implementation in that system would need to know how
to deal with multiple MAC addresses on each port, and the current
document does not deal with that.

It's not merely an issue with traceroute-like functionality, nor is a
special issue with the last hop.  Thus I don't understand why you're
bringing it up here.

> >> So how do you know you reached the last hop?
> > 
> > Because frames with higher Hop Count never return.
> 
> That could also mean:
> 
> 	- the return error message was lost
> 
> 	- routing had an incomplete path (never reaches the dest)

Sure.  The other way you know that your path is complete is that the
system that sends back the last message happens to have the ID of the
original TRILL destination.

> > If we do this as Dinesh has argued, then we'll always have the drop
> > information from that last hop. 
> 
> But you don't know it's the last hop, as per above.

You can.  See above.  :-/

> > If we don't, then we won't.  That
> > means that the method proposed provides additional information without
> > significant expense.
> 
> As in my other message, this doesn't correlate to user packet behavior
> anyway. We need to keep sending the same packet repeatedly with
> increasing hopcount, which is a separate function that needs to be
> implemented. That function has no benefit from using a user packet as
> payload, since the TRILL header hides that content anyway.

Correct; this would need to be initiated from a TRILL node.

> > I agree that a decent 'traceroute' feature should use a special packet
> > that allows us to send back "and here's what I'd do with that once
> > I've decapsulated" information from the last (destination) TRILL node.
> 
> That'd be "PING" ('echo request') (i.e., that's how traceroute works in
> IPv4/IPv6).

It could be *anything*.  We're designing a new protocol.  We're not
constrained to the hackery used in ping.  (E.g., having an undefined
payload format that is used by each node in proprietary ways.)

Note that _real_ traceroute doesn't use ping, but instead uses UDP
datagrams sent to an arbitrary (unused) port.  ICMP Echo for
traceroute is a Windowism.  ;-}

Joe Touch writes:
> Making it 1 has the effect of making a traceroute send a "hopcount
> exceeded" from the rbridge at the destination, but unfortunately there
> are ways in which that message might not be interpreted as "it got
> there" (i.e., it could be "this is the last rbridge I saw, but I have no
> idea where it got).

So far, that seems to be "good enough."  Plus, since we have a
database of IDs for the RBridges (the nickname database), it's easy to
figure out what you're looking at.

It's worth noting that IPv4 traceroute has the same ambiguity.  Not
all nodes bother responding to arbitrary packets, nor do they all
allow ICMP errors to get through.  The result is that some traceroute
attempts just trail off in a bunch of stars.  (Try tracerouting to
www.sun.com ...)

> 2) whether we need to refer to rbridge forwarding in the description of
> hopcount processing
> 
> 	we absolutely do.
> 
> I've seen three agreements that claim we don't, but I've demonstrated
> this is not possible.

I don't believe you have.

> We need to differentiate how we handle packets
> that have arrived at their destination (which are decapsulated and their
> payload is sent out an interface) from packets that are forwarded (which
> are sent out an interface themselves). I.e., we need to distinguish
> between receiving and forwarding *TRILL* frames. When we receive a TRILL
> frame, we forward (if you like that term) its payload, but not the TRILL
> frame.

Actually, I don't believe that's necessary.

I agree that it'd be nice to have a distinguished message for the
"last" hop, and to have important information sent back from all
hops.  Without a definition of how traceroute is supposed to function
in TRILL, we'll need to defer that.

> a) we still need active participation by the source rbridge (this cannot
> be initiated by a user's packet)

Yep; agreed.  I don't think anyone was suggesting otherwise.

> b) we still need to differentiate when a packet has reached its
> destination in how hopcounts are processed. you can't just say "remove
> the word forwarding" from hopcount processing; it needs to be there

Actually, it works without it.

> > (Dinesh insists that it's also how routers have "always" worked, but I
> > have my doubts about that.)
> 
> That may be how some routers incorrectly implement the requirements for
> IPv4 or IPv6, but it fails to explain the success of sending TTL=0
> between hosts on the same LAN.

At least for the proposal under discussion, that particular router bug
is immaterial.

> > 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?
> 
> I'm talking about an rbridge that has more than one egress address,
> e.g., via overloading on a single interface or with multiple interfaces.
> The problem is that your "hopcount exceeded" message won't know what
> address to use, and if it picks one that isn't the packet's destination
> then you will not know the difference between a packet that arrives and
> one that hits a black hole.

It must have had some way of receiving the message in the first place.

If it's unicast, then the original destination on the 'trace' message
should be the source for the reply.  If it's multicast (a frightening
concept), then the source should be whatever source MAC address is
usually used for TRILL messages from that node when sending over the
given link on which the original message was received.

Note, of course, that we're arguing about the number of angels on the
head of a pin at this point, as the traceroute protocol itself *HAS
NOT BEEN PROPOSED*.  How it might choose MAC addresses to use seems
quite well off-topic and doesn't particularly help illuminate the
issue.

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