Re: [pim] TTL for PORT

Toerless Eckert <eckert@cisco.com> Tue, 08 February 2011 13:50 UTC

Return-Path: <eckert@cisco.com>
X-Original-To: pim@core3.amsl.com
Delivered-To: pim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40F73A7135 for <pim@core3.amsl.com>; Tue, 8 Feb 2011 05:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1w8Pu4FlxGF for <pim@core3.amsl.com>; Tue, 8 Feb 2011 05:50:53 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C03B43A6D8A for <pim@ietf.org>; Tue, 8 Feb 2011 05:50:53 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 13:51:00 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18Dp0nW003264; Tue, 8 Feb 2011 13:51:00 GMT
Received: from mcast-linux1.cisco.com (mdt-linux4 [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id p18Doxrf032179; Tue, 8 Feb 2011 05:51:00 -0800
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18Dox5B032178; Tue, 8 Feb 2011 05:50:59 -0800
Date: Tue, 08 Feb 2011 05:50:59 -0800
From: Toerless Eckert <eckert@cisco.com>
To: Pekka Savola <pekkas@netcore.fi>
Message-ID: <20110208135059.GI22898@cisco.com>
References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <alpine.LRH.2.02.1102080814280.15008@netcore.fi> <20110208094958.GZ22898@cisco.com> <alpine.LRH.2.02.1102081204260.20119@netcore.fi> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <alpine.LRH.2.02.1102081359480.22186@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.02.1102081359480.22186@netcore.fi>
User-Agent: Mutt/1.4.2.2i
Cc: Yiqun Cai <ycai@cisco.com>, "pim@ietf.org" <pim@ietf.org>
Subject: Re: [pim] TTL for PORT
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pim>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 13:50:54 -0000

On Tue, Feb 08, 2011 at 02:06:58PM +0200, Pekka Savola wrote:
> With ping, you can also check the sender side TTL.  I've yet to see a 
> difference between a physical and loopback IP -- but maybe there 
> exists a device which actually assigns physical IPs on linecards and 
> not the central processor and acts differently with this regard.

Can't find a ttl option in ping *sigh*, but at least when trying a
telnet from a routers loopback interface you seem to be right, the ttl
is still 255. Which also answers my other question: 255 seems to also be
a good default now, even for telnet ;-)

> Just to make it clear, normally when a router originates a packet, it 
> does not decrement the TTL as it is not forwarding the packet.

I guess the question is always how you model a loopback interface.
If you want a packet to be routed then this routing should normally
decrement the TTL. Of course, in this case it's better to not do this,
but i am not sure there is any good definition what must happen when
you use loopback interfaces. Just maybe common practice.

> One thing that you did not comment on but which could be possible is 
> that both the loopback IP and physical IP are decremented (if the 
> control plane and forwarding plane are decoupled very strongly). I 
> haven't seen this either, though.

Well, what is very common are PSA modules that are really just
devices internally connected in routers to an internal ethernet. Any
packets from / such modules does of course get TTL decremented by
the router. But logically this is not different from a process
sending/receiving a loopback interface.

Or for example, in IOS we have an internal virtual interface where a feature
acts like a small packet-rewriter. YOu send packets out that
interface, it gets rewritten and then when it's sent back into the router
then of course the TTL gets decremented because it behaves like a real
interface.

The way it looks to me, processes using loopback interfaces just
behave differently and do not decrement the TTL. I really did never
bother in before about this detail. I just sounded like an illogical
expectation to me to rely on this.

> >Of course, you can work around that in routers, but IMHO it's a hack which
> >is why i was asking if other protocols, eg: BGP do this (eg: in iBGP or the
> >like).
> 
> Protocols such as BGP are burdened by their history. Their TTL 
> behaviour was designed before TTL=255 checking was invented and for 
> backward compatibility reasons cannot change the default behaviour. 
> When designing a new protocol, we should look at current models. 
> There may be more recent (TCP) protocols on the field that 
> successfully employ TTL=255.

Sure.

Cheers
    Toerless