[rbridge] Hop Count processing

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:

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

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




sgai wrote:
> 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" <touch at ISI.EDU> wrote:
> 
> 
> 
> Dinesh G Dutt wrote:
>>>> 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.
> 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
> 
> 
> 
>>>> 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 <touch at isi.edu
>>>>>>> <mailto:touch at isi.edu>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> James Carlson wrote:
>>>>>>>    
>>>>>>>> Radia Perlman writes:
>>>>>>>>      
>>>>>>>>> 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:
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> 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
>>>>>>>     
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org <mailto:rbridge at postel.org>
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>  
>>>>>>> ------------------------------------------------------------------------
>>>>>>>     
>>>>  
>>>>>>> _______________________________________________
>>>>>>> rbridge mailing list
>>>>>>> rbridge at postel.org
>>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>>     
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoUxWkACgkQE5f5cImnZruwQQCgnnQr9IP5bJlnPnKEyvVUCfcd
jSEAni9tIDTL3VGISfSkiow7a+oW8vs7
=VewP
-----END PGP SIGNATURE-----