Subject: [rbridge] Hop Count processing

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 08 May 2009 15:30:06 -0700

I'd like to modify the hop count processing in section 3.6 (of draft 12) 
slightly. The advantages of this alignment are:
  - Make it possible to implement something like L2 traceroute
  - Align it with what is done in other protocols such as IP and MPLS 
for development and operational simplicity.
  - Not forward a frame that will be dropped by the next hop.

The existing text at the beginning of 3.6 is:

The Hop Count field is a 6-bit unsigned integer. Each RBridge that is
about to forward a TRILL data or ESADI frame MUST check this field
and discard the frame if this field is zero. If this field is greater
than or equal to 1, it MUST be decremented in the forwarded frame.

The suggested replacement is:

The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 
by each Rbridge that forwards a TRILL encapsulated frame. The frame is 
dropped if either the Hop Count in the received frame is 0 or the Hop 
Count is decremented to 0.

Comments ?

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Sat, 09 May 2009 07:48:11 -0700

>   - Make it possible to implement something like L2 traceroute

Bad idea. Keep in mind that this isn't L2 anything; it'd be *trill*.
Even then, it seems nonsensical to support on 802 networks.

>   - Not forward a frame that will be dropped by the next hop.

How do you know it won't be accepted by the next hop?

Joe

---

From: sgai <[email-masked]>
Date: Sat, 09 May 2009 08:17:49 -0700

We ABSOLUTELY need to be able to support a "TRILL traceroute".
Manageability and troubleshooting are mandatory requirements of any
deployable solution

-- Silvano

On 5/9/09 7:48 AM, "Joe Touch" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Dinesh G Dutt wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkoFl6oACgkQE5f5cImnZrukrwCfRzvaPMqyDEI3w4k8fq4SRhdd
> lyYAn2/CO4tY/6bazrTNaGRjnmSvTHcJ
> =+8Kg
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Sat, 09 May 2009 08:36:28 -0700

> Manageability and troubleshooting are mandatory requirements of any

No, they clearly are not, since 802 lacks them.

However, if you want a way to see all the trill components a message
passes through, you need a few things:

	a) define a signalling protocol, ala ICMP, in which to
	send the 'hopcount exceeded' message exceeded

	b) you need source/dest addrs that don't change hop
	by hop, or full bidirectional path state in the
	trill nodes

I reviewed the protocol doc (since things have changed a bit since I've
been tracking in detail - not always for the better, AFAICT), which
indicates that the outer addresses still change hop by hop. If all
routing protocols supported by TRILL (will it ever be more than IS-IS?)
have bidirectional tables, there *might* be a way home, but it's
distinctly not like either MPLS (hard bidirectional state on the path)
or like IP.

In particular, if the inner source address has a different egress than
ingress, then traceroute will not work. Traceroute will work, at best,
AFAICT, *only* from trill nodes, and not always unless ingress=egress is
enforced for inner addresses.

This isn't about what is "wanted" or even "needed", but about what is
possible.

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Sat, 09 May 2009 10:45:26 -0700

> No, they clearly are not, since 802 lacks them.
802 doesn't lack them. Check out 802.1ag. They're designed for a 
spanning tree like solution.

Dinesh

---

From: sgai <[email-masked]>
Date: Sat, 09 May 2009 13:08:37 -0700

I am not proposing that the current TRILL protocol definition should include
"TRILL traceroute".

I just think it is a good idea to have the appropriate hooks to be able to
develop it, to be competitive with IEEE 802.1ag.

The text that Dinesh proposed achieves this goal.

-- Silvano

---

From: James Carlson <[email-masked]>
Date: Mon, 11 May 2009 07:42:56 -0400

> Count is decremented to 0.

I think I need more information on this proposal.

I don't see how it helps with any sort of tracing work versus the
existing logic.  The existing logic looks something like this for
receiving TRILL packets:

	if we're the destination then
		decapsulate and forward via L2
		# note: ignore hop limit
	else if hop limit is zero then
		discard
		# note: this is where you'd implement tracing
	else
		decrement hop limit
		forward via nickname
	endif

The new logic you're proposing seems to be this:

	if hop limit is zero then
		discard
	else if we're the destination then
		decapsulate and forward via L2
	else
		decrement hop limit
		if hop limit is now zero then
			discard
		else
			forward via nickname
		endif
	endif

Besides being slightly more complex, I don't see how the proposed new
logic would do anything other than reduce the maximum radius of a
TRILL network by 1.  All that it appears to do is make zero an illegal
value on the wire, where it was once legal as long as no more
forwarding was needed (i.e., on the last hop).

At a guess, the rationale for this proposal seems to be centered on
the new check of the hop limit after the decrement in the forwarding
case, but how is that new check beneficial?

-- 
James Carlson, Solaris Networking              <[email-masked]>
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
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 11 May 2009 08:50:39 -0700

> 		decapsulate and forward via L2
This s the difference. How can I do anything like a traceroute if the 
frame is delivered when hop count is 0, but you've reached the 
destination ? BTW, this logic also complicates the processing of 
multi-destination frames when some Rbridges have access ports and 
inter-Rbridge links.

Dinesh

---

From: James Carlson <[email-masked]>
Date: Mon, 11 May 2009 12:05:43 -0400

Dinesh G Dutt writes:
> destination ?

Ah, I think I see the problem you're pointing out now.  It's in
providing visibility to the last hop, and _assuming_ that the probe
message sent isn't one that would trigger any response from the remote
system.

It'd be possible to define the tracing protocol such that it either
doesn't need the old hop-limit trick (by using something more like RFC
1393 to record the actual path of a single message), or defining it to
be a ping-like message that must elicit a reply that identifies the
target system.

If you assume that neither of those is done, and the decapsulating
host never sends anything back, then I agree that your change is
needed.

> BTW, this logic also complicates the processing of 

I'm not seeing it, but I'll take your word for it.

---

From: James Carlson <[email-masked]>
Date: Tue, 12 May 2009 16:05:57 -0400

Radia Perlman writes:
> I suspect nobody will care, so we can just go with Dinesh's wording.

With the detailed rationale for the change, I'm happy enough with his
wording and the extra check on entry.

---

From: Radia Perlman <[email-masked]>
Date: Tue, 12 May 2009 12:57:54 -0700

I don't think this should be a big deal either way, and it would be nice 
to not leave this as an open issue.
Dinesh's proposed wording change makes TRILL behave the same as IPv4 and 
IPv6, which seems reasonable.

His proposed replacement text is this:

"The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 
by each Rbridge that forwards a TRILL encapsulated frame. The frame is 
dropped if either the Hop Count in the received frame is 0 or the Hop 
Count is decremented to 0."

I'm not sure the "dropped if the Hop Count in the received frame is 0" 
is necessary, if anyone
is concerned about the extra cycle it would take to check the hop count 
both into and out of the
the RBridge, but it's probably a bit safer in case the previous RBridge 
forgot to drop the packet
after it decremented the TTL to 0.

So I think we should either just take Dinesh's wording, or if anyone is 
unhappy about checking TTL twice,
remove the "dropped if the Hop Count in the received frame is 0" clause. 
Or change it to a MAY, as in
"As an additional precaution, an RBridge MAY check the hop count in a 
received frame and drop
it if the hop count is 0".

Radia

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 May 2009 09:10:52 -0700

>> I suspect nobody will care, so we can just go with Dinesh's wording.

If the goal is to make this work like IP, the wording needs correction.

The original proposed wording is:

- ---

- ---

In IP, the following is true:

" A router MUST NOT discard a datagram just because it was received
   with TTL equal to zero or one; if it is to the router and otherwise
   valid, the router MUST attempt to receive it."

I.e., the packet is dropped if the TTL is zero or one on receipt only if
it is forwarded; if it is being 'accepted' (i.e., in this case, if the
destination is the trill node doing the processing), then a TTL of zero
is acceptable.

It seems like the wording needs to include this second case...

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 19 May 2009 20:07:25 -0400

I'm fine with changing hop count processing to make it the same as IPv4 and
IPv6 even it reduce the distance a TRILL encapsulated frame can go by 1 hop.

Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

On Fri, May 15, 2009 at 12:10 PM, Joe Touch <[email-masked]> wrote:

> iEYEARECAAYFAkoNlAwACgkQE5f5cImnZrtOFgCg26uBmac6/MOCZUi6kujD95US
> SS0AoOMXl2d621TdpwgRIT5E2UHAhzur
> =kKG6

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 May 2009 07:41:57 -0700

Donald Eastlake wrote:
> I'm fine with changing hop count processing to make it the same as IPv4
> and IPv6 even it reduce the distance a TRILL encapsulated frame can go
> by 1 hop.

My point is that you're not making it the same as IPv4 and IPv6. We need
to recognize that TRILL ingress and egress devices are NOT forwarders --
they are "hosts"; they do NOT decrement the hopcount, and thus they do
NOT drop packets once received regardless of hopcount.

I.e., either we're going for IP behavior or not...

Joe

> On Fri, May 15, 2009 at 12:10 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> James Carlson wrote:
>> Radia Perlman writes:
> ---
> ---
_______________________________________________
rbridge mailing list
[email-masked] <mailto:[email-masked]>
http://mailman.postel.org/mailman/listinfo/rbridge

> ------------------------------------------------------------------------

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 20 May 2009 10:47:33 -0400

I agree. I was just stating my opinion and a relatively high level,
rather than saying anything about the detailed wording.

Donald

On Wed, May 20, 2009 at 10:41 AM, Joe Touch <[email-masked]> wrote:
> iEYEARECAAYFAkoUFrUACgkQE5f5cImnZrtobwCgvi9/4tP/EGSGjqXPOBmy2zY3
> VrQAoLQs8H0QUmnsTvKJNWxt1QUqAWDU
> =SlcP

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 May 2009 07:52:25 -0700

OK. My point is that the idea that this reduces the hops traversed by 1
is the result of assuming that ingress/egress also decrement, which they
should not. If they don't, then there is no reduction...

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 20 May 2009 09:42:28 -0700

Joe,

I don't understand what you're saying. Rbridges are like routers, more 
like MPLS than like IP in that the header is added/removed by the 
ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the 
same behavior that has been suggested which is no different from IPv6's 
wording.

Dinesh

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 May 2009 09:51:52 -0700

> same behavior that has been suggested which is no different from IPv6's

Rbridge transits are like routers.

Rbridge ingress/egresses are like hosts - just as are any tunnel
endpoints, or anything that adds/removes headers (not just "swaps" them).

IPv6 says (in RFC2460), about its hop limit:

			Decremented by 1 by
                        each node that forwards the packet. The packet
                        is discarded if Hop Limit is decremented to
                        zero.

Neither the ingress nor the egress *forward* the trill packet.

Joe

---

From: sgai <[email-masked]>
Date: Wed, 20 May 2009 11:22:36 -0700

Joe,

The wordind says: " [Hop Count] is decremented by 1 by each Rbridge that
forwards a TRILL encapsulated frame".
If the frame goes out of an Egress Rbridge it is not TRILL encapsulated.

So where is the issue?

-- Silvano

On 5/20/09 9:51 AM, "Joe Touch" <[email-masked]> wrote:

> iEYEARECAAYFAkoUNSgACgkQE5f5cImnZrtF4ACfXn5HNKLYf333Po+BqpgYEts9
> Gf8AoM4Cl4390MtoDD7tcDp9+8eu6SQH
> =HXvb

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 May 2009 20:07:22 -0700

The current wording (in 05) is:

" A 6-bit unsigned integer. Each RBridge that is about to forward a
   frame to another RBridge MUST check this field and discard the frame
   if this field is zero. If this field is non-zero, it MUST be
   decremented in the forwarded frame."

That is sufficient and correct.

If the frame comes in as zero and needs to be forwarded, it is dropped.

If the frame comes in as 1, it can be decremented and forwarded. If the
destination is the next rbridge, then the frame is NOT discarded.

There is no need to consider a "0 or 1" case, as was proposed. The "0 or
1" case would prevent a frame from reaching its destination if the
hopcount exactly matched the path length, and there's no reason to do this.

The suggested replacement is incorrect:

This text incorrectly discards incoming frames that are 0 that are not
forwarded. I.e., the _original_ text was correct as it stood in v05.

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 20 May 2009 21:53:53 -0700

Joe,

I had requested the suggested text replacement to be:

"The Hop Count field is a 6-bit unsigned integer. It is decremented by 1
by each Rbridge that forwards a TRILL encapsulated frame. The frame is
dropped if the Hop Count is decremented to 0."

This is similar to MPLS and IPv6.

Dinesh
Joe Touch wrote:
> iEYEARECAAYFAkoUxWkACgkQE5f5cImnZruwQQCgnnQr9IP5bJlnPnKEyvVUCfcd
> jSEAni9tIDTL3VGISfSkiow7a+oW8vs7
> =VewP

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 May 2009 07:02:10 -0700

> dropped if the Hop Count is decremented to 0."

I copied your suggested text from your original post from 5/8.

Working with the above text, then the check needs to be:

"The Hop Count field is a 6-bit unsigned integer. It is decremented by 1
 by each Rbridge that forwards a TRILL encapsulated frame. The frame is
 dropped if the Hop Count is zero before or after it is decremented."

All you have succeeded in achieving is a more complex test at the
forwarder, and adding an ambiguity regarding packets with a hopcount of
0 and 1.

E.g., a packet with a hopcount of 0 or 1 would go from an ingress to an
egress just fine, and would arrive with the original hopcount.

A packet needs a hopcount of N+1 to traverse N intermediate forwarding
rbridges, i.e., hopcounts of [2..255] work. Packets that traverse
intermediate forwarders will always arrive with a hopcount of 1 or higher.

So packets can still arrive at egresses with hopcounts of [0..255]. The
egress knows something special about packets with hopcounts of 0 - i.e.,
that they could not have traversed an intermediate forwarder. Why is
that useful?

> This is similar to MPLS and IPv6.

What is the point of introducing this ambiguity? Just because IPv6 and
MPLS got it wrong, why should we follow?

Joe

---

From: Radia Perlman <[email-masked]>
Date: Thu, 28 May 2009 15:37:05 -0700

This was one issue I wasn't paying attention to, since it was not 
immediately obvious to me why
anyone would care. I think I now understand the issue, and so let me 
explain it.

Dinesh is arguing that in order to make something like traceroute work, 
you'd want something
that behaves EXACTLY like a data packet (in case there is some bug with 
processing data packets),
and can cause each hop to send an error report back. In order for that 
to work, TRILL has to do
something that seems somewhat confusing -- if there are only two 
RBridges; R1 and R2, and ingress
R1 is sending to egress R2, and wants the packet to be delivered to R2's 
endnode, R1 would have to
set the TTL to 2. If we do that, then R1 can do a traceroute setting the 
TTL to 1 in order to
get a "TTL expired" message from R2, and would have to set the TTL to 2 
in order to allow
the packet to actually be delivered to the endnodes.

This is admittedly very confusing, and not really "architecturally 
pure", since the TRILL header itself
only needs a TTL of 1 to reach the egress RBridge.

But now that I understand the issue, and as a pragmatist, I sympathize 
with Dinesh. I can't think
of any other way of making traceroute work, where ingress R1 can "ping" 
every hop along the path,
with a packet that behaves exactly like a data packet. For instance, it 
might even be more elegant
to have a special packet that travels along the path, and every RBridge 
that handles the packet sends
back a "received your probe and forwarded it to the next hop" message. 
That way only a single
management message gets all the RBridges along the path to send back 
messages. But the problem
is, that is not *exactly* a data message, and it's possible that 
RBridges might route or handle such
a packet differently from data packets, so it wouldn't be possible to 
find out what the issue is with
the data packets.

So I'm OK with doing what Dinesh wants, but the spec has to be really 
clear, because if I were implementing
it I'd probably assume that R1 (ingress) should set the TTL to be the 
diameter of the core, rather than one more.

Dinesh's suggested wording was:

"The Hop Count field is a 6-bit unsigned integer. It is decremented by 1
by each Rbridge that forwards a TRILL encapsulated frame. The frame is
dropped if the Hop Count is decremented to 0. "

That wording is confusing, because technically, the egress RBridge does not
forward the TRILL-encapsulated frame. It's no longer TRILL-encapsulated when
the egress guy forwards it to the endnodes. So no simple wording is going to
capture that.

How about:

"The Hop Count field is a 6-bit unsigned integer. It is decremented by 1
by each RBridge upon receipt, and the frame is dropped if the Hop Count is
decremented to 0. Note that this means that the ingress RBridge must set the
hop count to be at least one greater than the number of hops to the egress RBridge,
in order for the egress RBridge to decapsulate and forward the packet to the attached endnodes."

Note that this means that if R1 was sending a message to R2, and the only
nodes in the world were R1 and R2, R1 would still have to set the TTL to 2 in
order for R2 to process the packet. This could be thought of as R2 still being
the egress RBridge, and the processing part of R2 being an "attached endnode".

Radia

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 17:35:37 -0700

Hi, Radia,

Radia Perlman wrote:
> and can cause each hop to send an error report back. 

Right - the question is whether it behaves exactly like an IPv6 packet
or an IPv4 packet in this regard ;-)

> In order for that 
> set the TTL to 2. 

Right - whereas in IPv4 the TTL could be 0, since there are no
forwarding devices on the path.

> If we do that, then R1 can do a traceroute setting the 
> TTL to 1 in order to

Traceroute sends ping messages increases the TTL until it sees the
destination; it doesn't start with a concept of what the TTL should be.
It starts with TTL=1.

Traceroute using the rules I proposed would reach the egress with a
TTL=1, thus the first attempt (sending an ICMP ping ttl=1) would succeed
because it would be responded with a ping response.

> only needs a TTL of 1 to reach the egress RBridge.

Agreed. That's why I think that only forwarders should be checking the
TTL at all, and why they should drop if incoming packets have a TTL=0,
but should not drop if packets come in with TTL=1.

I.e.,

	ingress--egress		reachable with TTL=0
	ing--rb--egr		reachable with TTL=1
	ing--rb--rb--egr	reachable with TTL=2
	etc.

> with a packet that behaves exactly like a data packet.

The thing you're missing is only a ping facility. I'm guessing the goal
here is to avoid the need for a ping facility, but without that how do
you know you've reached the destination?

> For instance, it 

That, in IP, is "record route" (though it's recorded along the path).

> the egress guy forwards it to the endnodes.

Here's why Dinesh's wording is a problem

	ingress--egress TTL=0..63	-> packet accepted w/TTL=0..63
		i.e., TTL unchanged

	ingr--rb--egr TTL=0		-> packet accepted w/TTL=63
	0     63   63

	ingr--rb--egr TTL=1		-> packet dropped at rb
	
	ingr--rb--egr TTL=2..63		-> packet accepted w/TTL=1..62

This is confusing. There are two ways to end up with TTL=63 at the
destination, and one of them goes through an intervening rbridge.

> So no simple wording is going to capture that. 

Why do you want something to happen at the egress? In traceroute, when
you reach your destination (the egress here) you get a response from the
ICMP PING, you don't get a "time exceeded".

> in order for the egress RBridge to decapsulate and forward the packet to the attached endnodes."

What happens if you have the following?

	ingress--egress	TTL=0		-> packet accepted w/TTL=63
	0	63

	ingress--egress TTL=1		-> packet dropped
	1	0 (drop)

	ingress--egress TTL=2..63	-> packet accepted w/TTL=1..63

	ingr--rb--egr TTL=0		-> packet accepted w/TTL=62
	0     63  62

	ingr--rb--egr TTL=1		-> packet dropped
	1     0(drop)

	ingr--rb--egr TTL=2		-> packet dropped
	2     1   0(drop)

	ingr--rb--egr TTL=3..63		-> packet accepted w/TTL=1..61

I find this very confusing as well.

This is why I liked the idea of an IP-style count:

"The Hop Count field is a 6-bit unsigned integer. A forwarding rbridge
drops frames received with TTL=0, otherwise it decrements the TTL."

	ingr--rbridge TTL=0..63		-> packet accepted w/TTL=0..63

	ingr--rb--egr TTL=0		-> packet dropped
	0     (drop)

	ingr--rb--egr TTL=1..63		-> packet accepted w/TTL=0..62

This is quite simple and direct. The only thing that will never happen
is that the egress will not respond with an ICMP "TTL exceeded" - it
will (and should, IMO) respond with a ping response, which seems
appropriate to me.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2009 17:35:37 -0700

Hi, Radia,

I.e.,

	

Joe

---

From: Radia Perlman <[email-masked]>
Date: Fri, 29 May 2009 13:45:35 -0700

> drops frames received with TTL=0, otherwise it decrements the TTL."
Yup. I like that wording even better. And the behavior will give the 
ability to do what traceroute
does, and it also allows transmitting with TTL=number of hops to the 
egress RBridge, and
reach the egress RBridge.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Fri, 29 May 2009 14:24:19 -0700

Though, rereading that....I think it's even clearer if we remove the 
word "forwarding", so
it would instead be:

"The Hop Count field is a 6-bit unsigned integer. An Rbridge
drops frames received with TTL=0, otherwise it decrements the TTL."

---

From: James Carlson <[email-masked]>
Date: Fri, 29 May 2009 17:52:05 -0400

> drops frames received with TTL=0, otherwise it decrements the TTL."

Much better.  The "forwarding" part is the qualifier most likely to
confuse, and it doesn't actually change the meaning.

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 29 May 2009 15:41:13 -0700

I agree. This works for me,

Dinesh

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2009 16:55:13 -0700

> confuse, and it doesn't actually change the meaning.

First, anyone who doesn't know what forwarding means is going to have a
lot of problems implementing an rbridge. There are things it does with
packets that terminate, and things it does with packets that forward.
Forwarding is just a step that happens after you check whether a packet
matches the addresses of the rbridge (and fails that match).

Second, there are many more complex things than forwarding in the spec
as well.

Third, it not only changes the meaning, it changes the behavior. See the
walkthrough in my previous mail.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2009 16:53:12 -0700

> drops frames received with TTL=0, otherwise it decrements the TTL."

It is not any more or less clear; it just has a different behavior.

	ing-egr TTL=0		-> dropped at egr
	ing-egr TTL=1..63	-> arrive with TTL=0..62

	ing-rb-egr TTL=0	-> dropped at rb
	ing-rb-egr TTL=1	-> dropped at egr
	ing-rb-egr TTL=2..63	-> arive with TTL=0..61

Given the complexity of the rest of the system, I don't understand why
the concept of forwarding is considered difficult - it is needed to be
understood anyway (see the second algorithm below).

This wording only forces you to decrement the TTL of packets that have
already arrived; its only feature is to render packets with TTL=0
useless to emit.

Here's the algorithm:

	receive a packet
	if TTL=0
		send an "ICMP hopcount exceeded"
		drop the packet (even though it has already arrived)
	else
		if it matches an interface then
			decapsulate it
			emit it out the indicated interface
		else
			forward the packet

The only other thing this achieves is to have traceroute show you the
destination twice - once when the packet arrives and is dropped, and a
second time when the ICMP ping succeeds.

>>> drops frames received with TTL=0, otherwise it decrements the TTL."

Here's the algorithm -- note it has EXACTLY the same steps, just
reverses the order in which the conditions are checked:

	receive a packet
	if it matches an interface then
		decapsulate it
		emit it out the indicated interface
	else
		if TTL=0 then
			send an "ICMP hopcount exceeded"
			drop the packet
		else
			decrement the TTL
			forward the packet

IMO, this is clean.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2009 16:58:40 -0700

> walkthrough in my previous mail.

Oh, fourth (and really, wasn't this a goal?) - this would make the
rbridge hopcount completely different from both IPv4 and IPv6 - BOTH of
which define it exactly the way I did, FWIW - only *forwarders* check it
and decrement it.