[rbridge] Hop Count processing

[Radia Perlman]

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

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

Radia




James Carlson wrote:
> Dinesh G Dutt writes:
>   
>> James Carlson wrote:
>>     
>>> 	if we're the destination then
>>> 		decapsulate and forward via L2
>>> 		# note: ignore hop limit
>>>   
>>>       
>> 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 ?
>>     
>
> 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 
>> multi-destination frames when some Rbridges have access ports and 
>> inter-Rbridge links.
>>     
>
> I'm not seeing it, but I'll take your word for it.
>
>