[rbridge] Hop Count processing

[Joe Touch]

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

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

> On 5/9/09 7:48 AM, "Joe Touch" <touch at ISI.EDU> wrote:
> 
> 
> 
> Dinesh G Dutt wrote:
>>>> 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
> 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.
> 
>>>>   - 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.
> How do you know it won't be accepted by the next hop?
> 
> Joe