[rbridge] Hop Count processing
Radia.Perlman at sun.com
Tue May 12 12:57:54 PDT 2009
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.
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
> 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
>> 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.
More information about the rbridge