[rbridge] Hop Count processing

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



James Carlson wrote:
> 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?

Th difference is that you'll get a set of responses back, where you send
a packet from X->Y and you see:
	P
	Q
	R
	S
	T

And that's it. At that point, you have no idea if T is the same node as
Y, or whether T is just a dead end in the routing (a black hole, e.g.).

If your point is to know you reached the end, you basically need:

	failed - hopcount exceeded
	failed - hopcount exceeded
	succeeded

Another "failed - hopcount exceeded" won't cut it.

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

You only need to know whether the multiple MAC addresses are the same
rbridge when you are doing this sort of thing; for pings or anything
direct that you get "postitive feedback" on, you have no problem.

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

Because it *is* both an issue with only this sort of traceroute solution
and on the last hop, as noted above.

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

See above; you could easily get back an ID that is for the last hop, but
NOT the original destination.

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

Ping is a useful protocol regardless - it tells you the other end is up.
 We probably can use that for diagnostics anyway.

The "hack" here, if anything, is trying to infer a packet has arrived
when you get an error message from the place where the TTL goes to zero,
rather than by getting a "success" message.

> Note that _real_ traceroute doesn't use ping, but instead uses UDP
> datagrams sent to an arbitrary (unused) port. 

The first version of traceroute used PING. It was changed because PING
isn't required. We don't have ports, but we can require the PING be
implemented.

> ICMP Echo for
> traceroute is a Windowism.  ;-}

See above. Windows uses the original definition. Using ICMP pings
remains an option in most traceroute implementations.

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

This matters only for the destination; at the destination, you get a
different message - THAT is what makes it work, and that's not what
we're doing yet.

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

The definition you gave had it. I showed how all other definitions
proposed failed to give sensible results. What other sort of proof do
you need?

Or do you have another description of the processing that does not refer
to forwarding that you would like checked?

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

If you aren't going to define traceroute, then how can you argue what we
need in terms of hopcount to support it?

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

Again, show me a description that works.

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

Until someone has a description of traceroute, it's premature to use
traceroute as an argument for how to do hopcount processing.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkokGR8ACgkQE5f5cImnZrt+SACgtMO3CzGG2t6A0mIWdmkGVi6M
SGUAoN0qAg46izO7FN9dSTbCuCAJmRJL
=Na75
-----END PGP SIGNATURE-----