[rbridge] TTL use - (was Use of 802.1ah Encaps)

[Gray, Eric]

Don,

	I believe the key reason why we've more or less locked on
to using TTL for loop mitigation of (at least) unicast frame
forwarding is that the formation of temporary loops is hard to
avoid using existing link state routing protocols.  We've agreed
- at least in principle - to adopt whatever comes out of the 
routing working group's efforts to avoid loop formation (micro-
loop formation in particular), but this does not appear to rid
us of that problem.

	Yes, other loop mitigation techniques have been discussed
previously but TTL is the one with which most of us have more
experience.

	There are also loop-prevention techniques such as may be
achieved using STP and/or one of various signaling approaches.
At present, we are not - on the whole - considering any of these
approaches for work by the TRILL working group.  Most exist now
but would require (potentially major) modification, or are in
progress elsewhere (for other - possibly incompatible - purposes).

--
Eric 

(part of your previous message is included below)
> 
> Ahh this is what you mean. TTL is one method for a number of things,
> Loop mitigation, tracing, fault monitoring etc. It has pluses and
> minuses. Personally speaking as an individual I like TTL.  Although 
> I am > also aware of many systems and I also built systems that are 
> operational without TTL. TTL has shortcommings as well even in IP.  
> It is not a bad tool for some applications.  I know this group values 
> it, I'm not suggesting you drop that goal or requirement.  But a 
> [requirement] for TTL alone does not mandate a licence to change 
> everything either IMHO. 
>