[rbridge] Hop Count processing

[Joe Touch]

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



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

There are different things here:

1) what hopcount does a packet have that successfully reaches its
destination?

	we can make that 0 (as with IPv4 and IPv6)

	we can make that 1

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

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

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

Agreed, though as I've shown:

a) we still need active participation by the source rbridge (this cannot
be initiated by a user's packet)
	- to set the hopcount
	- to repeatedly send the same packet

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

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

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.

>> (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'd be very useful.

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

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.

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

iEYEARECAAYFAkoj/0EACgkQE5f5cImnZrvdoQCfe4rIJvFOJbyzCBACZtF84CGc
7rQAoPN1wgGwhaTS/ai8q4Au5UeUmcaP
=M7Gf
-----END PGP SIGNATURE-----