Subject: [rbridge] A thought about TTLs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 6 Nov 2006 17:41:34 -0500

Joe,

	For the unicast case, it need not be.  Reasons why it should
be different in the flooded, broadcast and multicast case are - I
believe - fairly obvious, since these behaviors are ditinctly not
the same in these cases.

	Also, even in the IP case, there has been discussion in the
past about the advantages of TTL reduction for tunneled traffic.

--
Eric 

--> -----Original Message-----
--> From: Joe Touch [mailto:touch at ISI.EDU] 
--> Sent: Monday, November 06, 2006 5:36 PM
--> To: Gray, Eric
--> Cc: Eastlake III Donald-LDE008; rbridge at postel.org
--> Subject: Re: [rbridge] A thought about TTLs
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	The protocol specification cannot be silent on the setting of
--> > a value for TTL.  For one thing, any value less than the 
--> max, should
--> > be compared with the expected number of hops as a sanity 
--> check - one
--> > way or another (meaning if the boxes don't do it, the 
--> user will have
--> > to do it themselves).
--> > 
--> > 	For example, if an implementer decided that 16 hops was the 
--> > most they could realistically expect to see in an RBridge 
--> CRED, they
--> > might set it to 16.  If it subsequently turns out that a 
--> network is 
--> > larger than they expected, I sincerely hope that they made this a
--> > configurable value.  If there is going to be a need to configure a
--> > value for this in most implementations, then we might as 
--> well say so
--> > up front so that there is likely to be a standard MIB object that
--> > corresponds to this value.
--> > 
--> > 	Clearly the simplest thing to do, therefore, is to set TTL to
--> > the maximum possible value.  Simple, but probably not sane.
--> 
--> Why is/should it be different than in an IP network?
--> 
--> Joe
--> 
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Nov 2006 14:50:50 -0800

Gray, Eric wrote:
> Joe,
> 
> 	For the unicast case, it need not be. 

Agreed.

> Reasons why it should

Yes; they're used for scoping. I'm not clear on why scoping comes into
play here, though - there's never a time we want to do
multicast/broadcast that doesn't reach the edge, and no penalty
(excepting w.r.t. looping) for overreaching. I.e., it has no equivalent
case here.
> past about the advantages of TTL reduction for tunneled traffic.

Much of what I've heard of there has been used for "security" (heavy
emphasis on the quotes) for tunneled BGP traffic. Is there another case,
 or are you referring to that?

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061106/1d3a9a0e/signature.bin