From stig@venaas.com Tue Feb 1 11:24:22 2011 Return-Path: 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 2A1733A6CDB for ; Tue, 1 Feb 2011 11:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 DiZ3ZtFbEHis for ; Tue, 1 Feb 2011 11:24:20 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 735DF3A6F86 for ; Tue, 1 Feb 2011 11:24:20 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:6d71:d8d3:6654:757a] (unknown [IPv6:2001:420:4:ea0c:6d71:d8d3:6654:757a]) by ufisa.uninett.no (Postfix) with ESMTPSA id 041597FF1; Tue, 1 Feb 2011 20:27:36 +0100 (CET) Message-ID: <4D485EA7.2010203@venaas.com> Date: Tue, 01 Feb 2011 11:27:35 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bharat Joshi References: <31D55C4D55BEED48A4459EB64567589A108114957C@BLRKECMBX02.ad.infosys.com>, <4D0913E1.1080603@venaas.com> <31D55C4D55BEED48A4459EB64567589A108114957F@BLRKECMBX02.ad.infosys.com>, <4D0A5DAB.1010204@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149580@BLRKECMBX02.ad.infosys.com>, <4D0BF567.6030206@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:24:22 -0000 Hi Bharat I think the main remaining point we need to discuss is whether you can switch back and forth between datagram and PORT mode. The below should summarize my thoughts... I'm curious what others think too. Assume that we do datagrams until the PORT connection is established. Once it is established we need to ignore datagram J/Ps. This is needed in case a datagram J/P was sent by one peer before connection got established, and received by the other right after. Else you might get a PORT (S,G)-join and a delayed datagram (S,G)-prune removing the (S,G) state and never recover. It might also make an attack like sending a single spoofed (S,G)-prune efficient... Assume now that we have routers A and B with a TCP connection between them. Assume that B send an (S,G)-join to A at some point, but that now only A sends joins to B. If the TCP packets are dropped between A and B, then A will eventually realize the connection is down (because it does enough retries), while B will not (unless it uses TCP keep-alive) because it does not try to send. Then A will revert to datagrams and send J/Ps that B will ignore. Also, the (S,G)-join state on A will expire because it does not receive any joins from B. B does not send datagram joins since it thinks the connection is up. Using keep-alives would certainly help here. However, if the connection goes down, I think it is better to try to reestablish it, than to immediately switch to datagram mode. It's bad to send a lot of datagrams J/Ps if the connection is coming up almost right after, and then have to send all the J/P state again. If the TCP connection fails repeatedly, why not instead have the router stop sending Hello's with the PORT option? What do you think? Stig From stig@venaas.com Wed Feb 2 10:06:22 2011 Return-Path: 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 1A9873A6D87 for ; Wed, 2 Feb 2011 10:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 g421H5W5wyuS for ; Wed, 2 Feb 2011 10:06:17 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 3DA063A6C01 for ; Wed, 2 Feb 2011 10:06:17 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:40b2:25d6:4472:40d8] (unknown [IPv6:2001:420:4:ea0c:40b2:25d6:4472:40d8]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2A2777FA8; Wed, 2 Feb 2011 19:09:34 +0100 (CET) Message-ID: <4D499DD8.7020009@venaas.com> Date: Wed, 02 Feb 2011 10:09:28 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Thomas Morin References: <20101025214502.2721F3A68D3@core3.amsl.com> <4CC5FD84.6040609@venaas.com> <47951CBFA6409B4C8916514FCB05BFBE0B34B4BA@xmb-sjc-219.amer.cisco.com> <4D05DEE0.3090902@orange-ftgroup.com> In-Reply-To: <4D05DEE0.3090902@orange-ftgroup.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: pim@ietf.org Subject: Re: [pim] draft-ietf-pim-port-04 wglc X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:06:22 -0000 Thanks Thomas, I'm finally updating the document now. Some comments below. On 12/13/2010 12:52 AM, Thomas Morin wrote: > Hi folks, > > I've spotted a typo in the text added in this revision : section 4 has > "on the link on the link". > (The typo is actually mine, and was in my suggestion of additional state > ;-) Ouch. I did actually read your text first, and thought it was good. > Section 6 has new text on Explicit Tracking has updated text. > I have a few comments > - uses the term "native join/prune messages" => what about "non-PORT > datagram PIM Join/Prune messages" instead ? I prever the shorter name, and it is defined earlier in the document. > - "When a non-ET neighbor sends a Prune, there is generally a small > delay to see if another non-ET neighbor sends a Join to override the > Prune. If there is no override, one should note that no non-ETP neighbor > is interested. " => this is a bit vague, why not say instead something > like "When a non-ET neighbor sends a Prune, as specified in RFC4601, if > no Join is sent to override this Prune before the expiration of the > Override Timer, the upstream routers concludes that no non-ETP neighbor > is interested." ? Yes, better, fixing. > - "non-ETP" => shouldn't that be "non ET" ? sure > - "When a PORT neighbor sends a prune, there can be no Prune Override, > since the Prune is not visible to other neighbors." => possibly unneeded > given the text added in section 4 yes, but think I'll keep it. > - "(S,G,R)" would better match RFC4601 by being written as "(S,G,Rpt)" Right, I should have made sure it was in sync. > Apart from these editorial comments, it seems to me that the document is > ready for IESG. Thanks. I will however go on and make some larger changes based on Bharat's comments. Stig > Thanks, > > -Thomas > > > Mike McBride (mmcbride) a écrit : >> Today begins another wglc for the pim-port draft. It will be two weeks. >> The draft has been updated with comments from previous wglc. Please >> review the draft and respond with support or not. >> >> http://www.ietf.org/id/draft-ietf-pim-port-04.txt >> >> Thanks, >> mike >> >>> -----Original Message----- >>> From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of >>> Stig Venaas >>> Sent: Monday, October 25, 2010 2:58 PM >>> To: pim@ietf.org >>> Subject: Re: [pim] I-D Action:draft-ietf-pim-port-04.txt >>> >>> I believe this version includes all the changes requested by Thomas >> and >>> Yakov, as well as most of the changes requested by Dimitri as part of >>> the wglc and the following discussion. >>> >>> Comments welcome, >>> >>> Stig >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From manav.bhatia@alcatel-lucent.com Fri Feb 4 17:44:24 2011 Return-Path: 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 BC8D13A68FF for ; Fri, 4 Feb 2011 17:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wQmwMN7zjqOl for ; Fri, 4 Feb 2011 17:44:23 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B93E73A68FD for ; Fri, 4 Feb 2011 17:44:23 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p151lkMC018052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Feb 2011 19:47:49 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p151lkxa003495 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 5 Feb 2011 07:17:46 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 5 Feb 2011 07:17:46 +0530 From: "Bhatia, Manav (Manav)" To: "pim@ietf.org" Date: Sat, 5 Feb 2011 07:17:44 +0530 Thread-Topic: Security Considerations in PORT Thread-Index: AcvE1q6g6SQgONcoTyWEvdOKwEQ5cg== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EADB@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: [pim] Security Considerations in PORT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 01:44:24 -0000 Hi, The draft says the following: "Transport connections can be authenticated using HMACs MD5 and SHA-1 simil= ar to use in BGP [RFC4271] and MSDP [RFC3618]." Both RFC 4271 and 3618 use TCP MD5 [RFC2328] which has been recently obsole= ted by a new TCP Authentication Option (TCP-AO) [RFC 5925]. RFC 5925 speci= fies the use of stronger Message Authentication Codes (MACs), protects agai= nst replays even for long-lived TCP connections, and provides more details = than TCP-MD5 on the association of security with TCP connections. It allow= s rekeying during a TCP connection, assuming that an out-of-band protocol o= r manual mechanism provides the new keys. Note that TCP MD5 does not precl= ude rekeying during a connection, but does not require its support either. = Further, TCP-AO supports key changes with zero segment loss, whereas key c= hanges in TCP MD5 can lose segments in transit during the changeover or req= uire trying multiple keys on each received segment during key use overlap b= ecause TCP MD5 lacks an explicit Key ID. Although TCP recovers lost segmen= ts through retransmission, loss can have a substantial impact on performanc= e. It would thus be prudent to rewrite the Security Considerations section and= suggest using TCP-AO to protect the transport connections. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Fri Feb 4 18:01:33 2011 Return-Path: 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 A61F73A6875 for ; Fri, 4 Feb 2011 18:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eeeVvGjv9Ynr for ; Fri, 4 Feb 2011 18:01:33 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E2D4F3A659C for ; Fri, 4 Feb 2011 18:01:31 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p1524tNn011672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Feb 2011 20:04:57 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1524ssv010806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 5 Feb 2011 07:34:54 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 5 Feb 2011 07:34:54 +0530 From: "Bhatia, Manav (Manav)" To: "pim@ietf.org" Date: Sat, 5 Feb 2011 07:34:56 +0530 Thread-Topic: TTL for PORT Thread-Index: AcvE2RYTA2AGgkWcQhyUxFTZ2+IXrQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: [pim] TTL for PORT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 02:01:33 -0000 Hi, Since the PIM routers are adjacent the draft should must also mention that = all PIM routers MUST send all TCP packets with TTL=3D255 and the receivers = MUST only accept them if the TTL=3D254. This provides an added security whe= re PIM routers will only accept TCP packets from legitimate routers. Since = TTL spoofing is considered nearly impossible, a mechanism based on an expec= ted TTL value can provide a simple and reasonably robust defense from infra= structure attacks based on forged protocol packets from outside the network= . Cheers, Manav= From ycai@cisco.com Fri Feb 4 20:24:16 2011 Return-Path: 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 3FCFB3A6407 for ; Fri, 4 Feb 2011 20:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 qCwtwEKeKmZM for ; Fri, 4 Feb 2011 20:24:15 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 89CCF3A63EC for ; Fri, 4 Feb 2011 20:24:15 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABdhTE2rRN+K/2dsb2JhbAClMXOeK5sIhVoEhHqGbYMz Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 Feb 2011 04:27:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p154ROHm015233; Sat, 5 Feb 2011 04:27:24 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 20:27:24 -0800 Received: from 10.21.121.238 ([10.21.121.238]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Sat, 5 Feb 2011 04:27:23 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Fri, 04 Feb 2011 20:27:22 -0800 From: Yiqun Cai To: "Bhatia, Manav (Manav)" , "pim@ietf.org" Message-ID: Thread-Topic: [pim] TTL for PORT Thread-Index: AcvE2RYTA2AGgkWcQhyUxFTZ2+IXrQAE+Vfs In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Feb 2011 04:27:24.0113 (UTC) FILETIME=[FCB35C10:01CBC4EC] Subject: Re: [pim] TTL for PORT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 04:24:16 -0000 Well, we might want to extend PORT to support tunnels or unidirectional links. Enforcing TTL=254 on the receiving end will make it more complicated. On 2/4/11 6:04 PM, "Bhatia, Manav (Manav)" wrote: > Hi, > > Since the PIM routers are adjacent the draft should must also mention that all > PIM routers MUST send all TCP packets with TTL=255 and the receivers MUST only > accept them if the TTL=254. This provides an added security where PIM routers > will only accept TCP packets from legitimate routers. Since TTL spoofing is > considered nearly impossible, a mechanism based on an expected TTL value can > provide a simple and reasonably robust defense from infrastructure attacks > based on forged protocol packets from outside the network. > > Cheers, Manav > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- Yiqun From manav.bhatia@alcatel-lucent.com Fri Feb 4 21:44:00 2011 Return-Path: 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 D3FF33A6A08 for ; Fri, 4 Feb 2011 21:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pHtSaHUTzS1Y for ; Fri, 4 Feb 2011 21:44:00 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E88EA3A6A02 for ; Fri, 4 Feb 2011 21:43:59 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p155kfMT029065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Feb 2011 23:46:44 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p155ke58016710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 5 Feb 2011 11:16:40 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 5 Feb 2011 11:16:40 +0530 From: "Bhatia, Manav (Manav)" To: Yiqun Cai , "pim@ietf.org" Date: Sat, 5 Feb 2011 11:16:37 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvE2RYTA2AGgkWcQhyUxFTZ2+IXrQAE+VfsAAK53EA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: Re: [pim] TTL for PORT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 05:44:00 -0000 If it's the MPLS tunnels that you are alluding to then it would still make = sense to have the TTL=3D254 as it'll still be just one hop away for the PIM= packet. It's the MPLS TTL that'll get decremented. Cheers, Manav=20 > -----Original Message----- > From: Yiqun Cai [mailto:ycai@cisco.com]=20 > Sent: Saturday, February 05, 2011 9.57 AM > To: Bhatia, Manav (Manav); pim@ietf.org > Subject: Re: [pim] TTL for PORT >=20 > Well, we might want to extend PORT to support tunnels or=20 > unidirectional > links. Enforcing TTL=3D254 on the receiving end will make it more > complicated. >=20 >=20 > On 2/4/11 6:04 PM, "Bhatia, Manav (Manav)"=20 > > wrote: >=20 > > Hi, > >=20 > > Since the PIM routers are adjacent the draft should must=20 > also mention that all > > PIM routers MUST send all TCP packets with TTL=3D255 and the=20 > receivers MUST only > > accept them if the TTL=3D254. This provides an added security=20 > where PIM routers > > will only accept TCP packets from legitimate routers. Since=20 > TTL spoofing is > > considered nearly impossible, a mechanism based on an=20 > expected TTL value can > > provide a simple and reasonably robust defense from=20 > infrastructure attacks > > based on forged protocol packets from outside the network. > >=20 > > Cheers, Manav > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 >=20 > --=20 > Yiqun >=20 > = From eckert@cisco.com Sat Feb 5 01:13:04 2011 Return-Path: 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 67DBE3A68DF for ; Sat, 5 Feb 2011 01:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.789 X-Spam-Level: X-Spam-Status: No, score=-8.789 tagged_above=-999 required=5 tests=[AWL=1.810, 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 IHz9m-w3c4mu for ; Sat, 5 Feb 2011 01:13:03 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6EEF73A6892 for ; Sat, 5 Feb 2011 01:13:03 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 05 Feb 2011 09:16:30 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p159GU12019870; Sat, 5 Feb 2011 09:16:30 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 p159GU6c017994; Sat, 5 Feb 2011 01:16:30 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p159GUCr017993; Sat, 5 Feb 2011 01:16:30 -0800 Date: Sat, 5 Feb 2011 01:16:30 -0800 From: Toerless Eckert To: "Bhatia, Manav (Manav)" Message-ID: <20110205091629.GT27034@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 09:13:04 -0000 In general, i like the TTL scheme, but i am a bit concerned about raising a requirement against a piece of the software (TCP/IP stack), that may have platform accelerations and not always expose a property like TTL easily. It would be easier to decide whether PORT should use this scheme if there was some widely deployed unicast protocol (over TCP) that has made the evaluation of all the implications. Especially a protocol that would be similar to PORT wrt to scalability/security/performance requirements, router-platform integration and the need for supporting a mode with and without TTL checking. What comes to mind in this respect is of course BGP. Aka: TTL checking for eBGP (which supposedly is usually one-hop), and no TTL checking for iBGP. Is this required by any IETF spec for BGP ? Cheers Toerless On Sat, Feb 05, 2011 at 11:16:37AM +0530, Bhatia, Manav (Manav) wrote: > If it's the MPLS tunnels that you are alluding to then it would still make sense to have the TTL=254 as it'll still be just one hop away for the PIM packet. It's the MPLS TTL that'll get decremented. > > Cheers, Manav > > > -----Original Message----- > > From: Yiqun Cai [mailto:ycai@cisco.com] > > Sent: Saturday, February 05, 2011 9.57 AM > > To: Bhatia, Manav (Manav); pim@ietf.org > > Subject: Re: [pim] TTL for PORT > > > > Well, we might want to extend PORT to support tunnels or > > unidirectional > > links. Enforcing TTL=254 on the receiving end will make it more > > complicated. > > > > > > On 2/4/11 6:04 PM, "Bhatia, Manav (Manav)" > > > > wrote: > > > > > Hi, > > > > > > Since the PIM routers are adjacent the draft should must > > also mention that all > > > PIM routers MUST send all TCP packets with TTL=255 and the > > receivers MUST only > > > accept them if the TTL=254. This provides an added security > > where PIM routers > > > will only accept TCP packets from legitimate routers. Since > > TTL spoofing is > > > considered nearly impossible, a mechanism based on an > > expected TTL value can > > > provide a simple and reasonably robust defense from > > infrastructure attacks > > > based on forged protocol packets from outside the network. > > > > > > Cheers, Manav > > > _______________________________________________ > > > pim mailing list > > > pim@ietf.org > > > https://www.ietf.org/mailman/listinfo/pim > > > > > > -- > > Yiqun > > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture Network Agnostic: Applications that work best on cheap, stupid networks. Suicide: Devaluating the intelligent network with network agnostic apps. From manav.bhatia@alcatel-lucent.com Sat Feb 5 01:55:20 2011 Return-Path: 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 E5B273A6890 for ; Sat, 5 Feb 2011 01:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ksQxxSlKeFR4 for ; Sat, 5 Feb 2011 01:55:20 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DD1BE3A688D for ; Sat, 5 Feb 2011 01:55:19 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p159weSk007385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 5 Feb 2011 03:58:42 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p159wd5j019258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 5 Feb 2011 15:28:39 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 5 Feb 2011 15:28:39 +0530 From: "Bhatia, Manav (Manav)" To: Toerless Eckert Date: Sat, 5 Feb 2011 15:28:41 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvFFWPTy4oO16w9Q3qKkCGDI0EIAAAA4s2A Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> In-Reply-To: <20110205091629.GT27034@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 09:55:21 -0000 RFC 4274 briefly discusses the GTSM [RFC 5082, which supersedes RFC 3682] t= echnique that's commonly used by BGP for its EBGP peers. I think such prote= ction schemes become important as soon as you start moving things over TCP = unicast as such packets can be launched from peers located far away from th= e network. This is especially true when we expect the packets to traverse o= nly one L3 hop (which is the case here). If you are concerned about the MUST that I had suggested in the original te= xt then you can replace this with a milder MAY and a recommendation that GT= SM techniques should be applied here. Cheers, Manav=20 > -----Original Message----- > From: Toerless Eckert [mailto:eckert@cisco.com]=20 > Sent: Saturday, February 05, 2011 2.47 PM > To: Bhatia, Manav (Manav) > Cc: Yiqun Cai; pim@ietf.org > Subject: Re: [pim] TTL for PORT >=20 >=20 > In general, i like the TTL scheme, but i am a bit concerned=20 > about raising > a requirement against a piece of the software (TCP/IP stack), that > may have platform accelerations and not always expose a property like > TTL easily. >=20 > It would be easier to decide whether PORT should use this=20 > scheme if there > was some widely deployed unicast protocol (over TCP) that has made the > evaluation of all the implications. Especially a protocol=20 > that would be > similar to PORT wrt to scalability/security/performance requirements, > router-platform integration and the need for supporting a mode > with and without TTL checking. >=20 > What comes to mind in this respect is of course BGP. Aka: TTL checking > for eBGP (which supposedly is usually one-hop), and no > TTL checking for iBGP. Is this required by any IETF spec for BGP ?=20 >=20 > Cheers > Toerless >=20 > On Sat, Feb 05, 2011 at 11:16:37AM +0530, Bhatia, Manav (Manav) wrote: > > If it's the MPLS tunnels that you are alluding to then it=20 > would still make sense to have the TTL=3D254 as it'll still be=20 > just one hop away for the PIM packet. It's the MPLS TTL=20 > that'll get decremented. > >=20 > > Cheers, Manav=20 > >=20 > > > -----Original Message----- > > > From: Yiqun Cai [mailto:ycai@cisco.com]=20 > > > Sent: Saturday, February 05, 2011 9.57 AM > > > To: Bhatia, Manav (Manav); pim@ietf.org > > > Subject: Re: [pim] TTL for PORT > > >=20 > > > Well, we might want to extend PORT to support tunnels or=20 > > > unidirectional > > > links. Enforcing TTL=3D254 on the receiving end will make it more > > > complicated. > > >=20 > > >=20 > > > On 2/4/11 6:04 PM, "Bhatia, Manav (Manav)"=20 > > > > > > wrote: > > >=20 > > > > Hi, > > > >=20 > > > > Since the PIM routers are adjacent the draft should must=20 > > > also mention that all > > > > PIM routers MUST send all TCP packets with TTL=3D255 and the=20 > > > receivers MUST only > > > > accept them if the TTL=3D254. This provides an added security=20 > > > where PIM routers > > > > will only accept TCP packets from legitimate routers. Since=20 > > > TTL spoofing is > > > > considered nearly impossible, a mechanism based on an=20 > > > expected TTL value can > > > > provide a simple and reasonably robust defense from=20 > > > infrastructure attacks > > > > based on forged protocol packets from outside the network. > > > >=20 > > > > Cheers, Manav > > > > _______________________________________________ > > > > pim mailing list > > > > pim@ietf.org > > > > https://www.ietf.org/mailman/listinfo/pim > > >=20 > > >=20 > > > --=20 > > > Yiqun > > >=20 > > >=20 > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > Network Agnostic: Applications that work best on cheap,=20 > stupid networks. > Suicide: Devaluating the intelligent network with network=20 > agnostic apps. >=20 > = From bharat_joshi@infosys.com Sat Feb 5 20:46:47 2011 Return-Path: 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 9DFCE3A69E6 for ; Sat, 5 Feb 2011 20:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 0Py13ZVdy1OQ for ; Sat, 5 Feb 2011 20:46:46 -0800 (PST) Received: from KECGATE03.infosys.com (Kecgate03.infosysconsulting.com [122.98.10.31]) by core3.amsl.com (Postfix) with ESMTP id 0B7EE3A6AB6 for ; Sat, 5 Feb 2011 20:46:45 -0800 (PST) X-TM-IMSS-Message-ID: <0e7abcae0000af1f@infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 0e7abcae0000af1f ; Sun, 6 Feb 2011 10:11:36 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.26]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Sun, 6 Feb 2011 10:16:43 +0530 From: Bharat Joshi To: Stig Venaas Date: Sun, 6 Feb 2011 10:16:43 +0530 Thread-Topic: Some questions and suggestions on PIM-PORT draft Thread-Index: AcvCRhlyGMwuC9o6Tc+CyGTLZDCZ1QCM+aEm Message-ID: <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A108114957C@BLRKECMBX02.ad.infosys.com>, <4D0913E1.1080603@venaas.com> <31D55C4D55BEED48A4459EB64567589A108114957F@BLRKECMBX02.ad.infosys.com>, <4D0A5DAB.1010204@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149580@BLRKECMBX02.ad.infosys.com>, <4D0BF567.6030206@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com>, <4D485EA7.2010203@venaas.com> In-Reply-To: <4D485EA7.2010203@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 04:46:47 -0000 Hi=20Stig, =20=20=20=20=20Sorry=20for=20a=20delayed=20reply.=20Please=20see=20my=20r= esponse=20in=20line. Regards, Bharat >=20I=20think=20the=20main=20remaining=20point=20we=20need=20to=20discuss= =20is=20whether=20you=20can >=20switch=20back=20and=20forth=20between=20datagram=20and=20PORT=20mode. >=20 >=20The=20below=20should=20summarize=20my=20thoughts...=20I'm=20curious= =20what=20others >=20think=20too. >=20 >=20Assume=20that=20we=20do=20datagrams=20until=20the=20PORT=20connection= =20is=20established. >=20Once=20it=20is=20established=20we=20need=20to=20ignore=20datagram=20J= /Ps.=20This=20is=20needed >=20in=20case=20a=20datagram=20J/P=20was=20sent=20by=20one=20peer=20befor= e=20connection=20got >=20established,=20and=20received=20by=20the=20other=20right=20after. >=20 >=20Else=20you=20might=20get=20a=20PORT=20(S,G)-join=20and=20a=20delayed= =20datagram=20(S,G)-prune >=20removing=20the=20(S,G)=20state=20and=20never=20recover. >=20 >=20It=20might=20also=20make=20an=20attack=20like=20sending=20a=20single= =20spoofed=20(S,G)-prune >=20efficient... Ok. =20 >=20Assume=20now=20that=20we=20have=20routers=20A=20and=20B=20with=20a=20= TCP=20connection=20between >=20them.=20Assume=20that=20B=20send=20an=20(S,G)-join=20to=20A=20at=20so= me=20point,=20but=20that=20now >=20only=20A=20sends=20joins=20to=20B.=20If=20the=20TCP=20packets=20are= =20dropped=20between=20A=20and=20B, >=20then=20A=20will=20eventually=20realize=20the=20connection=20is=20down= =20(because=20it=20does >=20enough=20retries),=20while=20B=20will=20not=20(unless=20it=20uses=20T= CP=20keep-alive) >=20because=20it=20does=20not=20try=20to=20send. Ok. >=20Then=20A=20will=20revert=20to=20datagrams=20and=20send=20J/Ps=20that= =20B=20will=20ignore.=20Also, >=20the=20(S,G)-join=20state=20on=20A=20will=20expire=20because=20it=20do= es=20not=20receive=20any >=20joins=20from=20B.=20B=20does=20not=20send=20datagram=20joins=20since= =20it=20thinks=20the >=20connection=20is=20up. But=20'B'=20was=20anyway=20not=20sending=20anything=20so=20I=20did=20not= =20understand=20the=20(S,G)=20join=20state=20on=20A=20expiring=20because= =20of=20that. >=20Using=20keep-alives=20would=20certainly=20help=20here. >=20 >=20However,=20if=20the=20connection=20goes=20down,=20I=20think=20it=20is= =20better=20to=20try=20to >=20reestablish=20it,=20than=20to=20immediately=20switch=20to=20datagram= =20mode.=20It's >=20bad=20to=20send=20a=20lot=20of=20datagrams=20J/Ps=20if=20the=20connec= tion=20is=20coming=20up >=20almost=20right=20after,=20and=20then=20have=20to=20send=20all=20the= =20J/P=20state=20again. Ok.=20I=20agree=20that=20we=20can=20retry=20couple=20of=20times=20here=20= before=20declaring=20that=20it=20will=20not=20come=20up. =20 >=20If=20the=20TCP=20connection=20fails=20repeatedly,=20why=20not=20inste= ad=20have=20the >=20router=20stop=20sending=20Hello's=20with=20the=20PORT=20option? >=20 >=20What=20do=20you=20think? Yes.=20This=20looks=20fine.=20We=20can=20stop=20using=20the=20PORT=20opti= on=20in=20the=20hello=20messages. One=20more=20thing=20I=20would=20like=20to=20clarify.=20Can=20a=20neighbo= ur=20start/stop=20using=20PORT=20option=20dynamically=20i.e.=20without=20= changing=20the=20GEN-ID? I=20am=20now=20thinking=20that=20restricting=20native=20J/P=20if=20PORT= =20option=20is=20enabled=20looks=20better.=20Let=20us=20see=20what=20othe= rs=20think=20about=20this. ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From manav.bhatia@alcatel-lucent.com Sun Feb 6 09:11:18 2011 Return-Path: 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 2EF873A6956 for ; Sun, 6 Feb 2011 09:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 YK5ezVDhqY5f for ; Sun, 6 Feb 2011 09:11:13 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6F1FD3A6951 for ; Sun, 6 Feb 2011 09:11:12 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p16HBAdJ023655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 6 Feb 2011 11:11:12 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p16HB7aP000815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 6 Feb 2011 22:41:09 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sun, 6 Feb 2011 22:41:07 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Sun, 6 Feb 2011 22:41:08 +0530 Thread-Topic: Re: [pim] Some questions and suggestions on PIM-PORT draft Thread-Index: AcvGINib+rOTtusQTAeM79wonn0q4g== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6B@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: PIM WG Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 17:11:18 -0000 Hi Stig, > > I am not sure if I follow this. In what conditions can a neighbor think= that the connection is UP while the other still think that is not UP. > > > > If a client immediately sends a join/prune message as soon as its local= connection is declared UP, TCP on the other hand will get this message onl= y after the ACK which would have brought the connection up in that neighbor= as well. I am not sure if I am missing something here. >=20 > One example is if for some reason TCP is broken so that no TCP > packets pass. Then if say one router tries to send packets, it will By "TCP is broken", do you mean a TCP implementation that is broken or some= transient condition in the network where TCP packets from A don't reach B?= I think the former can be ruled out because if a router has problems in th= eir TCP implementation then they have much bigger things to worry about the= n ensuring that their join/prune messages are being correctly sent out. > see the connection going down after reaching the retry limit. If the > other router does not try to send, it will not realize the connection Even if the other router has nothing to send it still has to acknowledge th= e TCP packets that it has received. If its unable to do that, the source wi= ll keep retransmitting the original TCP packet. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Sun Feb 6 10:03:41 2011 Return-Path: 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 9D4A63A6992 for ; Sun, 6 Feb 2011 10:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 S8AU+k7QtgbQ for ; Sun, 6 Feb 2011 10:03:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id C02943A6966 for ; Sun, 6 Feb 2011 10:03:40 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p16I3daP019508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 6 Feb 2011 12:03:42 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p16I3c6S001872 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Feb 2011 23:33:39 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sun, 6 Feb 2011 23:33:38 +0530 From: "Bhatia, Manav (Manav)" To: PIM WG Date: Sun, 6 Feb 2011 23:33:37 +0530 Thread-Topic: PORT and Datagram PIM Thread-Index: AcvGKC2q6Hz6PY8HR+SZbspHSLbouw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 18:03:41 -0000 Hi, I am new to PIM list and apologies in advance if this has already been disc= ussed on the list before.=20 I don't think I understand the reason why an operator would want to transit= ion to the datagram mode when two routers are advertising the PORT capabili= ty in their PIM Hellos. If they want to revert to the datagram mode then it= should be configured though the CLI and routers should stop advertising th= is capability in their Hellos. I would also like to understand the reason why we don't think we should add= a PIM Keepalive message for PORT. I don't think depending upon TCP Keepali= ve is a great idea. Most protocols over TCP (BGP, LDP, etc) done use it - w= hy should we? Cheers, Manav= From stig@venaas.com Mon Feb 7 10:22:34 2011 Return-Path: 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 3D84B3A6E41 for ; Mon, 7 Feb 2011 10:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 pYBQv4uWmWB0 for ; Mon, 7 Feb 2011 10:22:33 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 1E9E83A6E74 for ; Mon, 7 Feb 2011 10:22:33 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf] (unknown [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6F2557FEA; Mon, 7 Feb 2011 19:22:35 +0100 (CET) Message-ID: <4D50385F.90202@venaas.com> Date: Mon, 07 Feb 2011 10:22:23 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:22:34 -0000 I think using the TTL trick should at most be a SHOULD, maybe just a recommended option. It might be nice if it is implemented and that operators have a choice. I have two concerns with making it a MUST. One is that there could potentially be some uses for PORT between non-neighbors. I don't have any good ideas now, but I don't want to preclude that possibility. Another thing is that the IP addresses used for the PORT connection may be loopback addresses (or other addresses of the routers). Hopefully the loopback addresses are announced on the interfaces facing a PIM neighbor, but there may be cases where the TCP connection between two neighbors possibly end up going multiple hops. You could say that is a misconfiguration though. I guess also if you use say TCP-AO, then there is no need for the TTL trick. I will add that to the security considerations as you suggest. Stig From stig@venaas.com Mon Feb 7 10:30:51 2011 Return-Path: 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 2D0F83A6C87 for ; Mon, 7 Feb 2011 10:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 hzy-wnlXXQZo for ; Mon, 7 Feb 2011 10:30:50 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 2E1CF3A6E72 for ; Mon, 7 Feb 2011 10:30:49 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf] (unknown [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf]) by ufisa.uninett.no (Postfix) with ESMTPSA id F01487FEA for ; Mon, 7 Feb 2011 19:30:52 +0100 (CET) Message-ID: <4D503A5B.9070706@venaas.com> Date: Mon, 07 Feb 2011 10:30:51 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pim@ietf.org References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:30:51 -0000 On 2/6/2011 10:03 AM, Bhatia, Manav (Manav) wrote: > Hi, > > I am new to PIM list and apologies in advance if this has already been discussed on the list before. > > I don't think I understand the reason why an operator would want to transition to the datagram mode when two routers are advertising the PORT capability in their PIM Hellos. If they want to revert to the datagram mode then it should be configured though the CLI and routers should stop advertising this capability in their Hellos. Yes, I agree with you on this point. This is also what the draft says. > I would also like to understand the reason why we don't think we should add a PIM Keepalive message for PORT. I don't think depending upon TCP Keepalive is a great idea. Most protocols over TCP (BGP, LDP, etc) done use it - why should we? This may indeed be useful, although it is not entirely clear to me that we need it. I would welcome more discussion on this. Also if you have arguments for doing PORT keepalive rather than TCP keepalive. My thinking has so far been that it may be a good idea, but: We can add this option later if it becomes clear that is is needed. Or, one can do something like a keepalive by sending say an empty J/P message, if there are more than a certain time since the last sent J/P. By empty J/P message I mean that the included PIM J/P message has no groups in it. Note that there are also some that think enforcing keepalive is bad. So it should at most be an option. One nice thing is that each router can independently support it, it's not like both the peers need to. Stig > Cheers, Manav > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Mon Feb 7 10:41:11 2011 Return-Path: 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 94C0A3A6E79 for ; Mon, 7 Feb 2011 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3RHbRqfllVzF for ; Mon, 7 Feb 2011 10:41:10 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 9C9613A6C87 for ; Mon, 7 Feb 2011 10:41:10 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf] (unknown [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf]) by ufisa.uninett.no (Postfix) with ESMTPSA id EB1B07FEA; Mon, 7 Feb 2011 19:41:13 +0100 (CET) Message-ID: <4D503CC8.7050205@venaas.com> Date: Mon, 07 Feb 2011 10:41:12 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6B@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PIM WG Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:41:11 -0000 On 2/6/2011 9:11 AM, Bhatia, Manav (Manav) wrote: > Hi Stig, > >>> I am not sure if I follow this. In what conditions can a neighbor think that the connection is UP while the other still think that is not UP. >>> >>> If a client immediately sends a join/prune message as soon as its local connection is declared UP, TCP on the other hand will get this message only after the ACK which would have brought the connection up in that neighbor as well. I am not sure if I am missing something here. >> >> One example is if for some reason TCP is broken so that no TCP >> packets pass. Then if say one router tries to send packets, it will > > By "TCP is broken", do you mean a TCP implementation that is broken or some transient condition in the network where TCP packets from A don't reach B? I think the former can be ruled out because if a router has problems in their TCP implementation then they have much bigger things to worry about then ensuring that their join/prune messages are being correctly sent out. A transient condition. >> see the connection going down after reaching the retry limit. If the >> other router does not try to send, it will not realize the connection > > Even if the other router has nothing to send it still has to acknowledge the TCP packets that it has received. If its unable to do that, the source will keep retransmitting the original TCP packet. Yes, but imagine that somehow the link is broken so that no packets come through for a few minutes (of course that might lead to the PIM neighborship expiring too though). Then a router that has nothing it tries to send, also don't receive anything it needs to ACK. The connection will appear to be working just fine. > Cheers, Manav From stig@venaas.com Mon Feb 7 10:47:38 2011 Return-Path: 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 C85323A6C89 for ; Mon, 7 Feb 2011 10:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 hetXgjkGV7mv for ; Mon, 7 Feb 2011 10:47:37 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 479C73A693F for ; Mon, 7 Feb 2011 10:47:37 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf] (unknown [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf]) by ufisa.uninett.no (Postfix) with ESMTPSA id B6B4E7FEA; Mon, 7 Feb 2011 19:47:40 +0100 (CET) Message-ID: <4D503E4A.10803@venaas.com> Date: Mon, 07 Feb 2011 10:47:38 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bharat Joshi References: <31D55C4D55BEED48A4459EB64567589A108114957C@BLRKECMBX02.ad.infosys.com>, <4D0913E1.1080603@venaas.com> <31D55C4D55BEED48A4459EB64567589A108114957F@BLRKECMBX02.ad.infosys.com>, <4D0A5DAB.1010204@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149580@BLRKECMBX02.ad.infosys.com>, <4D0BF567.6030206@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com>, <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:47:38 -0000 On 2/5/2011 8:46 PM, Bharat Joshi wrote: > Hi Stig, > > Sorry for a delayed reply. Please see my response in line. > > Regards, > Bharat > >> I think the main remaining point we need to discuss is whether you can >> switch back and forth between datagram and PORT mode. >> >> The below should summarize my thoughts... I'm curious what others >> think too. >> >> Assume that we do datagrams until the PORT connection is established. >> Once it is established we need to ignore datagram J/Ps. This is needed >> in case a datagram J/P was sent by one peer before connection got >> established, and received by the other right after. >> >> Else you might get a PORT (S,G)-join and a delayed datagram (S,G)-prune >> removing the (S,G) state and never recover. >> >> It might also make an attack like sending a single spoofed (S,G)-prune >> efficient... > > Ok. > >> Assume now that we have routers A and B with a TCP connection between >> them. Assume that B send an (S,G)-join to A at some point, but that now >> only A sends joins to B. If the TCP packets are dropped between A and B, >> then A will eventually realize the connection is down (because it does >> enough retries), while B will not (unless it uses TCP keep-alive) >> because it does not try to send. > > Ok. > >> Then A will revert to datagrams and send J/Ps that B will ignore. Also, >> the (S,G)-join state on A will expire because it does not receive any >> joins from B. B does not send datagram joins since it thinks the >> connection is up. > > But 'B' was anyway not sending anything so I did not understand the (S,G) join state on A expiring because of that. B sent a PORT (S,G)-join before the connection stopped working. >> Using keep-alives would certainly help here. >> >> However, if the connection goes down, I think it is better to try to >> reestablish it, than to immediately switch to datagram mode. It's >> bad to send a lot of datagrams J/Ps if the connection is coming up >> almost right after, and then have to send all the J/P state again. > > Ok. I agree that we can retry couple of times here before declaring that it will not come up. > >> If the TCP connection fails repeatedly, why not instead have the >> router stop sending Hello's with the PORT option? >> >> What do you think? > > Yes. This looks fine. We can stop using the PORT option in the hello messages. > > One more thing I would like to clarify. Can a neighbour start/stop using PORT option dynamically i.e. without changing the GEN-ID? I would say that a neighbor can stop announcing the PORT option and not change the GENID. If any PORT connections were up and in use, they will then be taken down, and they will start sending periodic updates. When the connection goes down, timers should be started for the OIL entries, so that state expires unless they are refreshed by regular J/Ps. You only want to change the GEN-ID if you for some reason need to get a full update quickly. Stig > I am now thinking that restricting native J/P if PORT option is enabled looks better. Let us see what others think about this. > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents to any other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has taken > every reasonable precaution to minimize this risk, but is not liable for any damage > you may sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** From iesg-secretary@ietf.org Mon Feb 7 11:06:59 2011 Return-Path: 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 D85E33A6E93; Mon, 7 Feb 2011 11:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vL0zM0R89eig; Mon, 7 Feb 2011 11:06:59 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C013A6E97; Mon, 7 Feb 2011 11:06:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207190658.15199.35025.idtracker@localhost> Date: Mon, 07 Feb 2011 11:06:58 -0800 Cc: Internet Architecture Board , pim chair , pim mailing list , RFC Editor Subject: [pim] Protocol Action: 'PIM Group-to-RP Mapping' to Proposed Standard (draft-ietf-pim-group-rp-mapping-10.txt) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:07:00 -0000 The IESG has approved the following document: - 'PIM Group-to-RP Mapping' (draft-ietf-pim-group-rp-mapping-10.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-group-rp-mapping/ Technical Summary Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain which supports Any Source Multicast (ASM) maintains Group-to-RP mappings which are used to identify a Rendezvous Point(RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. This document defines a standard algorithm to deterministically choose between several group-to-rp mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. Working Group Summary WG consensus appears sound. There is consensus within the PIM WG to publish the document. While it has not received wild working group involvement, the participation has been active with individuals from a variety of vendors and providers. Document Quality The document has undergone thorough review within IETF's Multicast community. Personnel Mike McBride (mcbride@cisco.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From stig@venaas.com Mon Feb 7 11:15:03 2011 Return-Path: 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 C23823A69D2 for ; Mon, 7 Feb 2011 11:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 WRyWGSbx6oHi for ; Mon, 7 Feb 2011 11:15:03 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id F0FA23A69AF for ; Mon, 7 Feb 2011 11:15:02 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf] (unknown [IPv6:2001:420:4:ea0c:5b9:2c09:1075:ccbf]) by ufisa.uninett.no (Postfix) with ESMTPSA id CFAD67FEB for ; Mon, 7 Feb 2011 20:15:06 +0100 (CET) Message-ID: <4D5044B8.8030604@venaas.com> Date: Mon, 07 Feb 2011 11:15:04 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pim mailing list References: <20110207190658.15199.35025.idtracker@localhost> In-Reply-To: <20110207190658.15199.35025.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] Protocol Action: 'PIM Group-to-RP Mapping' to Proposed Standard (draft-ietf-pim-group-rp-mapping-10.txt) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:15:03 -0000 On 2/7/2011 11:06 AM, The IESG wrote: > The IESG has approved the following document: > - 'PIM Group-to-RP Mapping' > (draft-ietf-pim-group-rp-mapping-10.txt) as a Proposed Standard Many thanks to the authors for a lot of work on this one. Glad it finally got approved :) Stig From manav.bhatia@alcatel-lucent.com Mon Feb 7 15:33:44 2011 Return-Path: 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 262B63A6E82 for ; Mon, 7 Feb 2011 15:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fCo+0ASe25yp for ; Mon, 7 Feb 2011 15:33:43 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id D54933A6E05 for ; Mon, 7 Feb 2011 15:33:42 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p17NXhGS020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 17:33:46 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p17NXbCS031160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 05:03:43 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 8 Feb 2011 05:03:37 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Tue, 8 Feb 2011 05:03:35 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvG9APtN020whSIS22q1K2bRY3sQQAKuiZQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EE00@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> In-Reply-To: <4D50385F.90202@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: Toerless Eckert , Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:33:44 -0000 Hi Stig, =20 > I think using the TTL trick should at most be a SHOULD, maybe just a > recommended option. It might be nice if it is implemented and that > operators have a choice. I agree. >=20 > I have two concerns with making it a MUST. >=20 > One is that there could potentially be some uses for PORT between > non-neighbors. I don't have any good ideas now, but I don't want > to preclude that possibility. >=20 > Another thing is that the IP addresses used for the PORT > connection may be loopback addresses (or other addresses of > the routers). Hopefully the loopback addresses are announced > on the interfaces facing a PIM neighbor, but there may be cases Makes sense. > where the TCP connection between two neighbors possibly end up > going multiple hops. You could say that is a misconfiguration > though. If its going through multiple hops (and it certainly could in some transien= t network conditions) and if those hops arent doing PIM then all traffic wo= uld get blackholed. Even if they support PIM, it will break the protocol, s= o the TTL hack would actually help here. >=20 > I guess also if you use say TCP-AO, then there is no need for > the TTL trick. I will add that to the security considerations > as you suggest. Yes, but the TTL hack is more effective when you don't have TCP-AO as it's = a light weight mechanism to prevent someone spoofing PIM packets. You would= need it more in the absence of TCP-AO. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Mon Feb 7 16:27:35 2011 Return-Path: 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 BC4143A6C8B for ; Mon, 7 Feb 2011 16:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vmiPD9jNyiNg for ; Mon, 7 Feb 2011 16:27:34 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B10A23A6B0A for ; Mon, 7 Feb 2011 16:27:34 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p180RaQs014204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 18:27:38 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p180RXSo004071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 05:57:34 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 8 Feb 2011 05:57:34 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas , "pim@ietf.org" Date: Tue, 8 Feb 2011 05:57:37 +0530 Thread-Topic: [pim] PORT and Datagram PIM Thread-Index: AcvG9TboYgMi/+E9QDyrxxoCH6Cl7gAK5nGA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EE07@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D503A5B.9070706@venaas.com> In-Reply-To: <4D503A5B.9070706@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: Re: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:27:35 -0000 Hi Stig, =20 > > I don't think I understand the reason why an operator would=20 > want to transition to the datagram mode when two routers are=20 > advertising the PORT capability in their PIM Hellos. If they=20 > want to revert to the datagram mode then it should be=20 > configured though the CLI and routers should stop advertising=20 > this capability in their Hellos. >=20 > Yes, I agree with you on this point. This is also what the > draft says. I am confused because of all this discussion about reverting to the datagra= m mode when TCP fails, etc. I think if the routers have been configured to = use PORT then they MUST not try attempting sending native PIM Join/Prune me= ssages ever. >=20 > > I would also like to understand the reason why we don't=20 > think we should add a PIM Keepalive message for PORT. I don't=20 > think depending upon TCP Keepalive is a great idea. Most=20 > protocols over TCP (BGP, LDP, etc) done use it - why should we? >=20 > This may indeed be useful, although it is not entirely clear > to me that we need it. I would welcome more discussion on > this. Also if you have arguments for doing PORT keepalive > rather than TCP keepalive. Its well known that there can be false negatives with TCP keepalive which i= s why its use is discouraged. I am presuming that most TCP implementations = provide support for Keepalives - could there be some that don't? I am quite= sure that any router that wants to do PIM would have a TCP implementation = that supports this, however just bringing it up as a point to keep in mind.= =20 PIM will always be turned on links which also have OSPF/IS-IS running. Ther= e is thus a very good chance that BFD [RFC5882] would be running there as w= ell. Given this, all we need to do is to ensure that PIM also registers wit= h BFD and gets notified when two nodes loose IP connectivity. This would al= so give you a failover time in O(ms), something that we can never achieve w= ith TCP keepalives. Now, the above can only be done if we have PORT keepalives, as the operator= can turn off the PORT keepalives if there is BFD or some other liveliness = protocol (EFM (IEEE 802.3ah) for example) running between the PIM neighbors= . Only when no such protocol is running can the operator turn on PORT keepa= lives. However, if the WG does decide to go ahead with PORT keepalives then there = MUST be a provision to communicate this value to the other PORT neighbor, s= o that both sides send PORT keepalives well within this interval. > My thinking has so far been that it may be a good idea, but: >=20 > We can add this option later if it becomes clear that is is > needed. >=20 > Or, one can do something like a keepalive by sending say > an empty J/P message, if there are more than a certain time > since the last sent J/P. By empty J/P message I mean that the > included PIM J/P message has no groups in it. Yup this should work. Additionally, receiving any valid PIM prune/join mess= age from a peer is an implicit acknowledgement of that peer being alive. >=20 > Note that there are also some that think enforcing keepalive > is bad. So it should at most be an option. One nice thing is > that each router can independently support it, it's not like > both the peers need to. Generally you turn on keepalives on both sides. I cant envisage a scenario = where only one side would be interested in knowing the liveliness of the ot= her peer. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Mon Feb 7 16:34:43 2011 Return-Path: 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 4C76D3A6EAC for ; Mon, 7 Feb 2011 16:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BEIzXAq5HoZS for ; Mon, 7 Feb 2011 16:34:42 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 57A6A3A6B0A for ; Mon, 7 Feb 2011 16:34:42 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p180YiZp013724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 18:34:46 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p180YhFM004368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 06:04:43 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 8 Feb 2011 06:04:43 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Tue, 8 Feb 2011 06:04:51 +0530 Thread-Topic: [pim] Some questions and suggestions on PIM-PORT draft Thread-Index: AcvG9p05+igNQZGZT1+WiH3yBVBK6AAMIk/A Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EE08@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6B@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D503CC8.7050205@venaas.com> In-Reply-To: <4D503CC8.7050205@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: PIM WG Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:34:43 -0000 >=20 > Yes, but imagine that somehow the link is broken so that no packets > come through for a few minutes (of course that might lead to the > PIM neighborship expiring too though). Then a router that has nothing > it tries to send, also don't receive anything it needs to ACK. The > connection will appear to be working just fine. .. and its precisely why we would want to use Keepalives! However I still don't see why sending native PIM joins/prunes will help her= e. If your link is broken and cant carry TCP packets to directly connected = routers why do we think that they would be able to ship the multicast packe= ts. If there are TCP connectivity issues then we should just shutdown the c= onnection and wait for operator intervention if it really comes to that bef= ore restoring the PIM connectivity. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Mon Feb 7 16:39:24 2011 Return-Path: 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 CEC4A3A6EAC for ; Mon, 7 Feb 2011 16:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FN+deHd1wzsG for ; Mon, 7 Feb 2011 16:39:24 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 0689D3A6B0A for ; Mon, 7 Feb 2011 16:39:23 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p180dMpH018888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Feb 2011 18:39:24 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p180dLii001496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 06:09:21 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 8 Feb 2011 06:09:20 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas , Bharat Joshi Date: Tue, 8 Feb 2011 06:09:28 +0530 Thread-Topic: [pim] Some questions and suggestions on PIM-PORT draft Thread-Index: AcvG94hRrT7x8Xs2SDKWXM8aq+fz1gAMIMaA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <31D55C4D55BEED48A4459EB64567589A108114957C@BLRKECMBX02.ad.infosys.com>, <4D0913E1.1080603@venaas.com> <31D55C4D55BEED48A4459EB64567589A108114957F@BLRKECMBX02.ad.infosys.com>, <4D0A5DAB.1010204@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149580@BLRKECMBX02.ad.infosys.com>, <4D0BF567.6030206@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com>, <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> In-Reply-To: <4D503E4A.10803@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "pim@ietf.org" Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:39:24 -0000 > >> Then A will revert to datagrams and send J/Ps that B will=20 > ignore. Also, > >> the (S,G)-join state on A will expire because it does not=20 > receive any > >> joins from B. B does not send datagram joins since it thinks the > >> connection is up. > > > > But 'B' was anyway not sending anything so I did not=20 > understand the (S,G) join state on A expiring because of that. >=20 > B sent a PORT (S,G)-join before the connection stopped working. I repeat - I don't think it's a good idea mixing PORT joins/prunes with dat= agram joins/prunes. If a router was running PIM in the datagram mode and sw= itches to the PORT mode (or vice-versa) then all state MUST be refreshed ag= ain. Any join not refreshed should get timed out naturally. If PORT connection dies, then we MUST remove all (S,G) and (*,G) state from= the routers. >=20 > >> Using keep-alives would certainly help here. > >> > >> However, if the connection goes down, I think it is better=20 > to try to > >> reestablish it, than to immediately switch to datagram mode. It's > >> bad to send a lot of datagrams J/Ps if the connection is coming up > >> almost right after, and then have to send all the J/P state again. > > > > Ok. I agree that we can retry couple of times here before=20 > declaring that it will not come up. > > > >> If the TCP connection fails repeatedly, why not instead have the > >> router stop sending Hello's with the PORT option? > >> > >> What do you think? > > > > Yes. This looks fine. We can stop using the PORT option in=20 > the hello messages. I think it should require operator intervention and the operator MUST decon= figure the PORT mode before we start sending native joins/prunes. We MUST n= ot automatically start sending Hellos without the PORT option! Cheers, Manav= From stig@venaas.com Mon Feb 7 19:31:13 2011 Return-Path: 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 889343A6BE9 for ; Mon, 7 Feb 2011 19:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TRnE+nPRT-aW for ; Mon, 7 Feb 2011 19:31:10 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 397203A6BDA for ; Mon, 7 Feb 2011 19:31:10 -0800 (PST) Received: from [10.21.116.76] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2E5497FEB; Tue, 8 Feb 2011 04:31:13 +0100 (CET) Message-ID: <4D50B8C6.1090300@venaas.com> Date: Mon, 07 Feb 2011 19:30:14 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <31D55C4D55BEED48A4459EB64567589A108114957C@BLRKECMBX02.ad.infosys.com>, <4D0913E1.1080603@venaas.com> <31D55C4D55BEED48A4459EB64567589A108114957F@BLRKECMBX02.ad.infosys.com>, <4D0A5DAB.1010204@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149580@BLRKECMBX02.ad.infosys.com>, <4D0BF567.6030206@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com>, <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" , Bharat Joshi Subject: Re: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 03:31:14 -0000 On 07.02.2011 16:39, Bhatia, Manav (Manav) wrote: >>>> Then A will revert to datagrams and send J/Ps that B will >> ignore. Also, >>>> the (S,G)-join state on A will expire because it does not >> receive any >>>> joins from B. B does not send datagram joins since it thinks the >>>> connection is up. >>> >>> But 'B' was anyway not sending anything so I did not >> understand the (S,G) join state on A expiring because of that. >> >> B sent a PORT (S,G)-join before the connection stopped working. > > I repeat - I don't think it's a good idea mixing PORT joins/prunes with datagram joins/prunes. If a router was running PIM in the datagram mode and switches to the PORT mode (or vice-versa) then all state MUST be refreshed again. Any join not refreshed should get timed out naturally. > > If PORT connection dies, then we MUST remove all (S,G) and (*,G) state from the routers. > >> >>>> Using keep-alives would certainly help here. >>>> >>>> However, if the connection goes down, I think it is better >> to try to >>>> reestablish it, than to immediately switch to datagram mode. It's >>>> bad to send a lot of datagrams J/Ps if the connection is coming up >>>> almost right after, and then have to send all the J/P state again. >>> >>> Ok. I agree that we can retry couple of times here before >> declaring that it will not come up. >>> >>>> If the TCP connection fails repeatedly, why not instead have the >>>> router stop sending Hello's with the PORT option? >>>> >>>> What do you think? >>> >>> Yes. This looks fine. We can stop using the PORT option in >> the hello messages. > > I think it should require operator intervention and the operator MUST deconfigure the PORT mode before we start sending native joins/prunes. We MUST not automatically start sending Hellos without the PORT option! > Cheers, Manav So it seems I will keep the text in the current draft on this. That is my preferred option. I don't want to add text saying that an implementation could stop announcing the option. But I think an implementation could choose to do that (think of it as a configuration change) and still be following the spec. Whether operators would like that or not is another matter. I'll be submitting a new version shortly. It seems to be that the only open issue is regarding keep-alives. And perhaps the TTL issue. I'll respond to some of your other emails on the keep-alives. I'm also hoping others will join the discussion. I want to come to a conclusion quickly and be done with this document. Stig From pekkas@netcore.fi Mon Feb 7 22:19:21 2011 Return-Path: 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 B18123A6B69 for ; Mon, 7 Feb 2011 22:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RGtemlsv4PAd for ; Mon, 7 Feb 2011 22:19:21 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 733573A6A08 for ; Mon, 7 Feb 2011 22:19:20 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p186JDHF015928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 08:19:13 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p186JD3J015924; Tue, 8 Feb 2011 08:19:13 +0200 Date: Tue, 8 Feb 2011 08:19:13 +0200 (EET) From: Pekka Savola To: Stig Venaas In-Reply-To: <4D50385F.90202@venaas.com> Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Yiqun Cai , Toerless Eckert , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:19:21 -0000 I have not followed this thread but: I think you're mainly arguing for "could be used between non-direct neighbors". This is a case that already requires manual configuration or should require it. Such configuration could turn off GTSM on the system or it could be manually configured off at the same time. On Mon, 7 Feb 2011, Stig Venaas wrote: > One is that there could potentially be some uses for PORT between > non-neighbors. I don't have any good ideas now, but I don't want > to preclude that possibility. Setting TTL=255 when sending does not preclude that. So do we agree it MUST be set to 255? The real question is how normative checking it is. Luckily, if TTL=255 is set when sending, this does not require any coordination and can be done on the receipt side only. > Another thing is that the IP addresses used for the PORT > connection may be loopback addresses (or other addresses of > the routers). Hopefully the loopback addresses are announced > on the interfaces facing a PIM neighbor, but there may be cases > where the TCP connection between two neighbors possibly end up > going multiple hops. You could say that is a misconfiguration > though. Whether or not an IP address is configured on the loopack interface does not change the TTL compared to a physical interface address. > I guess also if you use say TCP-AO, then there is no need for > the TTL trick. I will add that to the security considerations > as you suggest. TCP-AO is a poor substitute for the lightweight TTL security provided by GTSM. More often than not, TCP-AO is NOT going to be enabled. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From eckert@cisco.com Tue Feb 8 01:49:54 2011 Return-Path: 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 C9D283A70A6 for ; Tue, 8 Feb 2011 01:49: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 ZiaoCw9cCuoy for ; Tue, 8 Feb 2011 01:49:54 -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 1C2FA3A70A1 for ; Tue, 8 Feb 2011 01:49:54 -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 09:50: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 p189o0oW015587; Tue, 8 Feb 2011 09:50: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 p189nxhS021926; Tue, 8 Feb 2011 01:49:59 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p189nwYC021923; Tue, 8 Feb 2011 01:49:58 -0800 Date: Tue, 8 Feb 2011 01:49:58 -0800 From: Toerless Eckert To: Pekka Savola Message-ID: <20110208094958.GZ22898@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:49:54 -0000 On Tue, Feb 08, 2011 at 08:19:13AM +0200, Pekka Savola wrote: > Whether or not an IP address is configured on the loopack interface > does not change the TTL compared to a physical interface address. Normally, packets sent with a loopback address would get internally routed and thereby TTL decremented. Does anybody know if BGP for example tries to still send out to a router with TTL=255 ? I haven't followed the details, but would we expect mutual autodiscovery of loopback addresses between PORT peers, eg: via PIM Hello options ? If use of loopback is something we would like to be able to occur automatically, and still want to do TTL checking then it would be good if PORT wasn't the first protocol coming up with this combination. Did i mention that i would like to see good proof for protocols like BGP successfully doing the same stuff that's proposed here on the list for TTL checking ? ;-)) Cheers Toerless From pekkas@netcore.fi Tue Feb 8 02:11:48 2011 Return-Path: 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 BC6BD3A7083 for ; Tue, 8 Feb 2011 02:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 w4A7uoR2VIIS for ; Tue, 8 Feb 2011 02:11:48 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 743393A70B8 for ; Tue, 8 Feb 2011 02:11:47 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p18ABMju020277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 12:11:22 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p18ABLB6020274; Tue, 8 Feb 2011 12:11:21 +0200 Date: Tue, 8 Feb 2011 12:11:21 +0200 (EET) From: Pekka Savola To: Toerless Eckert In-Reply-To: <20110208094958.GZ22898@cisco.com> Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:11:48 -0000 On Tue, 8 Feb 2011, Toerless Eckert wrote: > On Tue, Feb 08, 2011 at 08:19:13AM +0200, Pekka Savola wrote: >> Whether or not an IP address is configured on the loopack interface >> does not change the TTL compared to a physical interface address. > > Normally, packets sent with a loopback address would get internally > routed and thereby TTL decremented. Does anybody know if BGP for example > tries to still send out to a router with TTL=255 ? BGP spec uses TTL=1 for historical reason, only when enabling GTSM they get sent with TTL=255. Typical router implementations don't do an additional TTL decrement when using the loopback address, but there could be cornercases when this may happen (one I've seen is when a linecard sends TTL exceeded messages -- observable with funnies when running 'tracepath' through Juniper routers). You can easily test this by pinging the router's loopback IP and a physical IP. I've yet to see a case where these would differ. Therefore I contest 'normally'. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From manav.bhatia@alcatel-lucent.com Tue Feb 8 03:52:43 2011 Return-Path: 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 EFA043A6D8E for ; Tue, 8 Feb 2011 03:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 T3A63EipmJTp for ; Tue, 8 Feb 2011 03:52:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 2B6C63A6EDA for ; Tue, 8 Feb 2011 03:52:42 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p18BqfsW005872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 05:52:44 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18BqcvW026152 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 17:22:39 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 8 Feb 2011 17:22:37 +0530 From: "Bhatia, Manav (Manav)" To: Pekka Savola , Toerless Eckert Date: Tue, 8 Feb 2011 17:22:34 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHeJLbb1zaRlSQSf6V9mHBsAvvHgADdA5Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 11:52:44 -0000 >=20 > BGP spec uses TTL=3D1 for historical reason, only when enabling GTSM=20 > they get sent with TTL=3D255. >=20 > Typical router implementations don't do an additional TTL decrement=20 > when using the loopback address, but there could be cornercases when=20 > this may happen (one I've seen is when a linecard sends TTL exceeded=20 > messages -- observable with funnies when running 'tracepath' through=20 > Juniper routers). You can easily test this by pinging the router's=20 > loopback IP and a physical IP. I've yet to see a case where these=20 > would differ. >=20 > Therefore I contest 'normally'. I agree. The implementation has a bug if it decrements the TTL twice when f= orwarding packets to the loopback IP.=20 Cheers, Manav From manav.bhatia@alcatel-lucent.com Tue Feb 8 03:55:31 2011 Return-Path: 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 111293A6DD0 for ; Tue, 8 Feb 2011 03:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HrfDwxWghTLi for ; Tue, 8 Feb 2011 03:55:30 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 2FA543A6D8E for ; Tue, 8 Feb 2011 03:55:30 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p18BtVi8008174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 05:55:34 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18BtRRi029977 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 17:25:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 8 Feb 2011 17:25:28 +0530 From: "Bhatia, Manav (Manav)" To: Toerless Eckert , Pekka Savola Date: Tue, 8 Feb 2011 17:25:25 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHdajRz/T1P8HATp23LImKpHsACwAEQsyQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> In-Reply-To: <20110208094958.GZ22898@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 11:55:31 -0000 > first protocol coming up with this combination. Did i mention=20 > that i would > like to see good proof for protocols like BGP successfully doing the > same stuff that's proposed here on the list for TTL checking ? ;-)) You don't lose anything by sending packets with TTL=3D255. Its only at the = receiving end that you do the GTSM check. If you are not comfortable with t= he GTSM check, and I am not sure why, then we could add a milder statement = in the draft suggesting that implementations MAY or SHOULD verify that the = TTL=3D254 before accepting the packets on the TCP connection. We could also= add text suggesting that implementations could provide a CLI knob to toggl= e this behavior. Cheers, Manav= From eckert@cisco.com Tue Feb 8 03:57:06 2011 Return-Path: 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 D8DC23A6DDE for ; Tue, 8 Feb 2011 03:57:06 -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 ebaygNLhk2gP for ; Tue, 8 Feb 2011 03:57:03 -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 C6B3A3A6C9B for ; Tue, 8 Feb 2011 03:57:02 -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 11:57:08 +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 p18Bv9jF001321; Tue, 8 Feb 2011 11:57:09 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 p18Bv9oP027230; Tue, 8 Feb 2011 03:57:09 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18Bv9Uf027229; Tue, 8 Feb 2011 03:57:09 -0800 Date: Tue, 8 Feb 2011 03:57:09 -0800 From: Toerless Eckert To: "Bhatia, Manav (Manav)" Message-ID: <20110208115709.GE22898@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 11:57:07 -0000 On Tue, Feb 08, 2011 at 05:22:34PM +0530, Bhatia, Manav (Manav) wrote: > I agree. The implementation has a bug if it decrements the TTL twice when forwarding packets to the loopback IP. I didn't mean the receiver side, i meant the sender side. YOu send into looback not only to get it's address as the source IP address, but also often to get routing in the sending router to send out the packet to whatever is currently the best interface. Once you hit routing, you should decrement TTL and thereby only send with 254. 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). Cheers Toerless From pekkas@netcore.fi Tue Feb 8 04:07:01 2011 Return-Path: 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 D89213A6C9E for ; Tue, 8 Feb 2011 04:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 JX9FE3pTpG+C for ; Tue, 8 Feb 2011 04:07:01 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 99D653A6AE3 for ; Tue, 8 Feb 2011 04:07:00 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p18C6wOO022383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 14:06:58 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p18C6w8Y022379; Tue, 8 Feb 2011 14:06:58 +0200 Date: Tue, 8 Feb 2011 14:06:58 +0200 (EET) From: Pekka Savola To: Toerless Eckert In-Reply-To: <20110208115709.GE22898@cisco.com> Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 12:07:02 -0000 On Tue, 8 Feb 2011, Toerless Eckert wrote: > I didn't mean the receiver side, i meant the sender side. YOu send > into looback not only to get it's address as the source IP address, > but also often to get routing in the sending router to send out the > packet to whatever is currently the best interface. Once you hit routing, > you should decrement TTL and thereby only send with 254. 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. 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. 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. > 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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From eckert@cisco.com Tue Feb 8 05:18:23 2011 Return-Path: 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 7625C3A7013 for ; Tue, 8 Feb 2011 05:18:23 -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 tzbLF+YIvphs for ; Tue, 8 Feb 2011 05:18:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A81653A6F2B for ; Tue, 8 Feb 2011 05:18:22 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 13:18:29 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p18DITm7011128; Tue, 8 Feb 2011 13:18:29 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 p18DISEX030840; Tue, 8 Feb 2011 05:18:28 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18DIStt030838; Tue, 8 Feb 2011 05:18:28 -0800 Date: Tue, 8 Feb 2011 05:18:28 -0800 From: Toerless Eckert To: "Bhatia, Manav (Manav)" Message-ID: <20110208131828.GG22898@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3E@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3E@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:18:23 -0000 On Tue, Feb 08, 2011 at 05:25:25PM +0530, Bhatia, Manav (Manav) wrote: > > first protocol coming up with this combination. Did i mention > > that i would > > like to see good proof for protocols like BGP successfully doing the > > same stuff that's proposed here on the list for TTL checking ? ;-)) > > You don't lose anything by sending packets with TTL=255. Its only at the receiving end that you do the GTSM check. If you are not comfortable with the GTSM check, and I am not sure why, then we could add a milder statement in the draft suggesting that implementations MAY or SHOULD verify that the TTL=254 before accepting the packets on the TCP connection. We could also add text suggesting that implementations could provide a CLI knob to toggle this behavior. I am not uncomfortable with the GTSM check. I think my first sentence about this on the thread was that i do in general like it. I would just like to follow established proven solutions from other protocols if at all possible, that's why i was asking. >From this discussion there seem to be at least three cases: a) directly connected PORT neighbors using interface IP addresses, no routing involved. This is IMHO the same as eBGP, which seems to recommend GTSM now in this case. So i think PORT should do the same and i do not see a reason why it could not even be a MUST. b) directly connected PORT neighbors using loopback addresses to deal with eg: multiple links with a single PORT connection. It is not clear to me whether GTSM would work in this case due to possible TTL decrement on the sender side. I wonder if we have existing precedence of other protocols for this case. LDP comes to mind, i think it also has this case (loopback addresses). c) non-directly connected PORT neighbors. The GTSM check is not applicable in this situation. I am not quite sure what difference it would make to MUST/SHOULD a TTL of 255 in this case. I think that the usual TTL used in unicast connectsions more like 64 or 128, right ? Eg: Why should we NOT want to use whatever the default for TCP connections is ? Cheers Toerless > > Cheers, Manav From eckert@cisco.com Tue Feb 8 05:50:54 2011 Return-Path: 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 ; 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 ; 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 ; 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, 8 Feb 2011 05:50:59 -0800 From: Toerless Eckert To: Pekka Savola 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> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From stig@venaas.com Tue Feb 8 06:36:23 2011 Return-Path: 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 54CA23A67A5 for ; Tue, 8 Feb 2011 06:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 i8tnmk-nbrSj for ; Tue, 8 Feb 2011 06:36:22 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id B30FB3A67A2 for ; Tue, 8 Feb 2011 06:36:21 -0800 (PST) Received: from [192.168.1.102] (c-67-170-194-177.hsd1.ca.comcast.net [67.170.194.177]) by ufisa.uninett.no (Postfix) with ESMTPSA id AF1457FED; Tue, 8 Feb 2011 15:36:26 +0100 (CET) Message-ID: <4D5154AB.1030600@venaas.com> Date: Tue, 08 Feb 2011 06:35:23 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Pekka Savola References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yiqun Cai , Toerless Eckert , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:36:23 -0000 On 08.02.2011 04:06, Pekka Savola wrote: [...] > 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. I would certainly be interested to know whether there are other TCP based protocols doing this. I'm a bit concerned that there may be TCP implementations where you cannot check TTL when receiving TCP. Can you do this with a standard socket API? I know you can for datagrams of course, Stig From stig@venaas.com Tue Feb 8 06:42:03 2011 Return-Path: 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 0708E3A6403 for ; Tue, 8 Feb 2011 06:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 t6IrMm3fRyzs for ; Tue, 8 Feb 2011 06:42:02 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 024C63A63EB for ; Tue, 8 Feb 2011 06:42:02 -0800 (PST) Received: from [192.168.1.102] (c-67-170-194-177.hsd1.ca.comcast.net [67.170.194.177]) by ufisa.uninett.no (Postfix) with ESMTPSA id 5C0097FED; Tue, 8 Feb 2011 15:42:06 +0100 (CET) Message-ID: <4D515602.90302@venaas.com> Date: Tue, 08 Feb 2011 06:41:06 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Toerless Eckert References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> In-Reply-To: <20110208094958.GZ22898@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:42:03 -0000 On 08.02.2011 01:49, Toerless Eckert wrote: > On Tue, Feb 08, 2011 at 08:19:13AM +0200, Pekka Savola wrote: >> Whether or not an IP address is configured on the loopack interface >> does not change the TTL compared to a physical interface address. > > Normally, packets sent with a loopback address would get internally > routed and thereby TTL decremented. Does anybody know if BGP for example > tries to still send out to a router with TTL=255 ? > > I haven't followed the details, but would we expect mutual autodiscovery > of loopback addresses between PORT peers, eg: via PIM Hello options ? Yes. PORT allows for using a single TCP connection for multiple neighborships (if say two routers are neighbors on multiple links). You would then announce typically a loopback address in the PIM Hello's to be used for the connection. I would say loopback mainly because you want the connection to stay up if any single physical interface goes down. > If use of loopback is something we would like to be able to occur automatically, It would probably not be automatic, although the spec doesn't specify that. Stig > and still want to do TTL checking then it would be good if PORT wasn't the > first protocol coming up with this combination. Did i mention that i would > like to see good proof for protocols like BGP successfully doing the > same stuff that's proposed here on the list for TTL checking ? ;-)) > > Cheers > Toerless From manav.bhatia@alcatel-lucent.com Tue Feb 8 06:53:31 2011 Return-Path: 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 679603A67A8 for ; Tue, 8 Feb 2011 06:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 f3J2OIA8CMWN for ; Tue, 8 Feb 2011 06:53:30 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8BF2B3A659A for ; Tue, 8 Feb 2011 06:53:30 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p18Er9cL010909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 08:53:12 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18Er7Kk004835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 20:23:08 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 8 Feb 2011 20:23:07 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas , Pekka Savola Date: Tue, 8 Feb 2011 20:23:06 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHnZmJyIXGjRqsSh+wC6J4XQTHMwAAK0bA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EADF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> In-Reply-To: <4D5154AB.1030600@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: Toerless Eckert , Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:53:31 -0000 BFD, defined in RFC5881 is not a TCP based protocol but it uses GTSM.=20 RFC 4953 which describes how TCP can be protected against spoofing attacks.= It recommends that GTSM should be used. RFC 5405 describes UDP usage guidelines for designers recommends using GTSM= . RFC 4381 also recommends using GTSM for all supported protocols. RFC 4732, RFC 4778 recommends GTSM for BGP. .. the list is endless. Cheers, Manav > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com]=20 > Sent: Tuesday, February 08, 2011 8.05 PM > To: Pekka Savola > Cc: Toerless Eckert; Bhatia, Manav (Manav); Yiqun Cai; pim@ietf.org > Subject: Re: [pim] TTL for PORT >=20 > On 08.02.2011 04:06, Pekka Savola wrote: > [...] > > Protocols such as BGP are burdened by their history. Their=20 > TTL behaviour > > was designed before TTL=3D255 checking was invented and for backward > > compatibility reasons cannot change the default behaviour. When > > designing a new protocol, we should look at current models.=20 > There may be > > more recent (TCP) protocols on the field that successfully=20 > employ TTL=3D255. >=20 > I would certainly be interested to know whether there are other TCP > based protocols doing this. I'm a bit concerned that there may be TCP > implementations where you cannot check TTL when receiving TCP. >=20 > Can you do this with a standard socket API? I know you can for > datagrams of course, >=20 > Stig >=20 >=20 > = From eckert@cisco.com Tue Feb 8 07:04:28 2011 Return-Path: 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 9CA6D3A659B for ; Tue, 8 Feb 2011 07:04:28 -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 nmZxLDW-YNoD for ; Tue, 8 Feb 2011 07:04:27 -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 D1B523A659A for ; Tue, 8 Feb 2011 07:04:27 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 15:04:34 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p18F4ZAL014026; Tue, 8 Feb 2011 15:04:35 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 p18F4Y4x003145; Tue, 8 Feb 2011 07:04:34 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18F4YOq003144; Tue, 8 Feb 2011 07:04:34 -0800 Date: Tue, 8 Feb 2011 07:04:34 -0800 From: Toerless Eckert To: "Bhatia, Manav (Manav)" Message-ID: <20110208150434.GO22898@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:04:28 -0000 Are you aware of any implementations that enforce GTSM and not have a knob to relax the checck - just in case there is a problem on the remote side which would make the connection fail the GTSM check ? I still have to see the first level of increased security that's without problems. Maybe PORT needs a statement like this: The use of unicast transport makes the neighbor security problem more difficult than when using link-local-scope multicast. ;-))) CHeers Toerless On Tue, Feb 08, 2011 at 08:23:06PM +0530, Bhatia, Manav (Manav) wrote: > BFD, defined in RFC5881 is not a TCP based protocol but it uses GTSM. > > RFC 4953 which describes how TCP can be protected against spoofing attacks. It recommends that GTSM should be used. > RFC 5405 describes UDP usage guidelines for designers recommends using GTSM. > RFC 4381 also recommends using GTSM for all supported protocols. > RFC 4732, RFC 4778 recommends GTSM for BGP. > > .. the list is endless. > > Cheers, Manav > > > -----Original Message----- > > From: Stig Venaas [mailto:stig@venaas.com] > > Sent: Tuesday, February 08, 2011 8.05 PM > > To: Pekka Savola > > Cc: Toerless Eckert; Bhatia, Manav (Manav); Yiqun Cai; pim@ietf.org > > Subject: Re: [pim] TTL for PORT > > > > On 08.02.2011 04:06, Pekka Savola wrote: > > [...] > > > 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. > > > > I would certainly be interested to know whether there are other TCP > > based protocols doing this. I'm a bit concerned that there may be TCP > > implementations where you cannot check TTL when receiving TCP. > > > > Can you do this with a standard socket API? I know you can for > > datagrams of course, > > > > Stig > > > > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture Network Agnostic: Applications that work best on cheap, stupid networks. Suicide: Devaluating the intelligent network with network agnostic apps. From manav.bhatia@alcatel-lucent.com Tue Feb 8 07:16:12 2011 Return-Path: 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 8AC7C3A67DA for ; Tue, 8 Feb 2011 07:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 S7Qsfwk4diQi for ; Tue, 8 Feb 2011 07:16:11 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C07563A67D9 for ; Tue, 8 Feb 2011 07:16:11 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p18FGDVK005970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 09:16:16 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18FGDlv010077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 20:46:13 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 8 Feb 2011 20:46:13 +0530 From: "Bhatia, Manav (Manav)" To: Toerless Eckert Date: Tue, 8 Feb 2011 20:46:07 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHoY4+d+6NoiUvSaasZNXamxXOOwAALJKA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> In-Reply-To: <20110208150434.GO22898@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:16:12 -0000 Most implementations that I am aware of (including ours) have a CLI option = that will enforce this check. On our platforms we do it for BGP and LDP. It= s not turned on by default and the user has to explicitly turn on this knob= . >=20 > Maybe PORT needs a statement like this: >=20 > The use of unicast transport makes the neighbor security problem > more difficult than when using link-local-scope multicast. :-) It actually does since unicast packets can be spoofed easily and can be lau= nched from a host sitting multiple hops away; something that's almost impos= sible with multicast. Cheers, Manav= From erosen@cisco.com Tue Feb 8 07:16:37 2011 Return-Path: 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 3105C3A659B for ; Tue, 8 Feb 2011 07:16:37 -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 4Oe+ppLfvVBP for ; Tue, 8 Feb 2011 07:16:36 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 56E9E3A6407 for ; Tue, 8 Feb 2011 07:16:36 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 15:16:43 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18FGgA4004017; Tue, 8 Feb 2011 15:16:43 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p18FGfHD026054; Tue, 8 Feb 2011 10:16:42 -0500 To: "Bhatia, Manav (Manav)" In-reply-to: Your message of Sat, 05 Feb 2011 11:16:37 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 08 Feb 2011 10:16:41 -0500 Message-ID: <26053.1297178201@erosen-linux> From: Eric Rosen Cc: Yiqun Cai , "pim@ietf.org" Subject: Re: [pim] TTL for PORT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:16:37 -0000 Yiqun> Well, we might want to extend PORT to support tunnels or Yiqun> unidirectional links. Enforcing TTL=254 on the receiving end will Yiqun> make it more complicated. I agree with Yiqun. Checking that the TTL is 254 would not be a very good idea. PORT could potentially be used in the same way as, e.g., targeted LDP. There's also such a thing as multi-hop EBGP. Manav> If it's the MPLS tunnels that you are alluding to then it would still Manav> make sense to have the TTL=254 as it'll still be just one hop away Manav> for the PIM packet. It's the MPLS TTL that'll get decremented. Not necessarily: - The control packets don't necessarily travel through the same tunnel that the data packets travel through. In fact, the tunnel could be unidirectional (in the direction of the data). - If the control packets do travel through a tunnel, there is no guarantee that the TTL will not be decremented. In the case of an MPLS tunnel, the MPLS TTL is sometimes initialized from the IP TTL on ingress, and the IP TTL is sometimes set from the MPLS TTL on egress. In general, I think these TTL checks are always a bad practice anyway, because they embed knowledge of the topology into the protocol. There will always be a deployment in which this "knowledge" turns out to be false, so there always needs to be a knob to turn the TTL checks off. From stig@venaas.com Tue Feb 8 07:23:59 2011 Return-Path: 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 D32FD3A67B0 for ; Tue, 8 Feb 2011 07:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1HWRXAX0D8Yx for ; Tue, 8 Feb 2011 07:23:59 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 081C83A6407 for ; Tue, 8 Feb 2011 07:23:54 -0800 (PST) Received: from [192.168.1.102] (c-67-170-194-177.hsd1.ca.comcast.net [67.170.194.177]) by ufisa.uninett.no (Postfix) with ESMTPSA id 316607FED; Tue, 8 Feb 2011 16:23:57 +0100 (CET) Message-ID: <4D515FD2.6090705@venaas.com> Date: Tue, 08 Feb 2011 07:22:58 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:24:00 -0000 On 08.02.2011 07:16, Bhatia, Manav (Manav) wrote: > Most implementations that I am aware of (including ours) have a CLI option that will enforce this check. On our platforms we do it for BGP and LDP. Its not turned on by default and the user has to explicitly turn on this knob. So we could perhaps say that implementations SHOULD have a knob for enabling such a check. One question then is whether one should always send with TTL 255 so that it can be enabled unilaterally, or if one starts sending with TTL 255 when this is enabled. I'm still wondering if there is a standard API, although someone told me that FreeBSD can do this. >> >> Maybe PORT needs a statement like this: >> >> The use of unicast transport makes the neighbor security problem >> more difficult than when using link-local-scope multicast. > > :-) > > It actually does since unicast packets can be spoofed easily and can be launched from a host sitting multiple hops away; something that's almost impossible with multicast. Agree. And I have thought about having such a check before. > Cheers, Manav Stig From manav.bhatia@alcatel-lucent.com Tue Feb 8 07:32:41 2011 Return-Path: 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 588083A67C3 for ; Tue, 8 Feb 2011 07:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1QyHRvgTDYnH for ; Tue, 8 Feb 2011 07:32:40 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 60C593A65A5 for ; Tue, 8 Feb 2011 07:32:40 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p18FWLlO026849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 09:32:24 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18FWLE8006407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 21:02:21 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 8 Feb 2011 21:02:21 +0530 From: "Bhatia, Manav (Manav)" To: "erosen@cisco.com" Date: Tue, 8 Feb 2011 21:02:15 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHozVlzHeZc5EyRYCB+xdM+w77fwAAHTZQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of Sat, 05 Feb 2011 11:16:37 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <26053.1297178201@erosen-linux> In-Reply-To: <26053.1297178201@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:32:41 -0000 Eric, =20 > I agree with Yiqun. Checking that the TTL is 254 would not=20 > be a very good > idea. PORT could potentially be used in the same way as,=20 > e.g., targeted > LDP. There's also such a thing as multi-hop EBGP. I don't think I understand this. How would the PIM hello message which goes= with TTL=3D1 reach the PIM neighbor which is multiple hops away. If you re= ally want to do this then the PIM hello message should also be changed.=20 Are you alluding to a case where two PIM neighbors are the ingress and egre= ss nodes of a P2MP LSP. Even in that case, how would the PIM HELLO message = reach the other end, without which a PORT session cannot be established. If= the Hello is reaching then it means that the tunnel was treated as a singl= e hop. In that case the Join/Prune will also cover that same hop length. >=20 > Manav> If it's the MPLS tunnels that you are alluding to then=20 > it would still > Manav> make sense to have the TTL=3D254 as it'll still be just=20 > one hop away > Manav> for the PIM packet. It's the MPLS TTL that'll get decremented. >=20 > Not necessarily: >=20 > - The control packets don't necessarily travel through the=20 > same tunnel that > the data packets travel through. In fact, the tunnel could be > unidirectional (in the direction of the data). >=20 > - If the control packets do travel through a tunnel, there is=20 > no guarantee > that the TTL will not be decremented. In the case of an=20 > MPLS tunnel, the > MPLS TTL is sometimes initialized from the IP TTL on=20 > ingress, and the IP > TTL is sometimes set from the MPLS TTL on egress. >=20 I agree to both the points above. > In general, I think these TTL checks are always a bad practice anyway, > because they embed knowledge of the topology into the=20 > protocol. There will We need the PIM hellos to establish the PORT session. PIM hellos imo assume= a directly connected link (ttl=3D1) and there is thus some knowledge of to= pology embedded in the protocol already. Cheers, Manav= From pekkas@netcore.fi Tue Feb 8 07:33:51 2011 Return-Path: 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 F1F5B3A67B7 for ; Tue, 8 Feb 2011 07:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 V9rdsDTJ1bJM for ; Tue, 8 Feb 2011 07:33:50 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id BDDEF3A6765 for ; Tue, 8 Feb 2011 07:33:49 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p18FXlco026621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 17:33:47 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p18FXl3Y026618; Tue, 8 Feb 2011 17:33:47 +0200 Date: Tue, 8 Feb 2011 17:33:47 +0200 (EET) From: Pekka Savola To: Stig Venaas In-Reply-To: <4D515FD2.6090705@venaas.com> Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D515FD2.6090705@venaas.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Yiqun Cai , Toerless Eckert , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:33:51 -0000 On Tue, 8 Feb 2011, Stig Venaas wrote: > On 08.02.2011 07:16, Bhatia, Manav (Manav) wrote: >> Most implementations that I am aware of (including ours) have a CLI option >> that will enforce this check. On our platforms we do it for BGP and LDP. >> Its not turned on by default and the user has to explicitly turn on this >> knob. > > So we could perhaps say that implementations SHOULD have a > knob for enabling such a check. > > One question then is whether one should always send with > TTL 255 so that it can be enabled unilaterally, or if one > starts sending with TTL 255 when this is enabled. > > I'm still wondering if there is a standard API, although > someone told me that FreeBSD can do this. I'd argue: MUST send by default to TTL=255 MUST check at receipt by default that TTL=255 SHOULD be configurable to omit the check at receipt or accept a different TTL threshold value Various signalling mechanisms (PIM Hellos or whatever) that would configure PORT to be used by non-adjacent neighbors or in non-TTL-preserving tunnel scenarios could reconfigure or disable the check as part of the procedure. FWIW, I think there is no standard API for TCP TTL checking in the application (e.g. in Linux, IP_RECVTTL is not supported with TCP). This needs to be done in the kernel or by filtering. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From stig@venaas.com Tue Feb 8 10:06:04 2011 Return-Path: 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 3B0873A67F5 for ; Tue, 8 Feb 2011 10:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.612 X-Spam-Level: X-Spam-Status: No, score=-98.612 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3C0oT2QxTh30 for ; Tue, 8 Feb 2011 10:06:03 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 401553A6803 for ; Tue, 8 Feb 2011 10:06:03 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a] (unknown [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a]) by ufisa.uninett.no (Postfix) with ESMTPSA id C3B217FEC; Tue, 8 Feb 2011 19:06:08 +0100 (CET) Message-ID: <4D518608.1070902@venaas.com> Date: Tue, 08 Feb 2011 10:06:00 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Pekka Savola References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <20110208094958.GZ22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D515FD2.6090705@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yiqun Cai , Toerless Eckert , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:06:04 -0000 On 2/8/2011 7:33 AM, Pekka Savola wrote: > On Tue, 8 Feb 2011, Stig Venaas wrote: >> On 08.02.2011 07:16, Bhatia, Manav (Manav) wrote: >>> Most implementations that I am aware of (including ours) have a CLI >>> option >>> that will enforce this check. On our platforms we do it for BGP and LDP. >>> Its not turned on by default and the user has to explicitly turn on this >>> knob. >> >> So we could perhaps say that implementations SHOULD have a >> knob for enabling such a check. >> >> One question then is whether one should always send with >> TTL 255 so that it can be enabled unilaterally, or if one >> starts sending with TTL 255 when this is enabled. >> >> I'm still wondering if there is a standard API, although >> someone told me that FreeBSD can do this. > > I'd argue: > > MUST send by default to TTL=255 > MUST check at receipt by default that TTL=255 I think this is too strict. But I'm happy to encourage implementations to support it (more like a SHOULD). So I think we may agree that this check can be useful. And also that we should say something about it in the draft. The main issue is whether it should be required, and whether it should be on by default. > SHOULD be configurable to omit the check at receipt or accept a > different TTL threshold value > Various signalling mechanisms (PIM Hellos or whatever) that would > configure PORT to be used by non-adjacent neighbors or in > non-TTL-preserving tunnel scenarios could reconfigure or disable the > check as part of the procedure. This is not that easy. Well, basically what I think you would have to do, is to compare the source address of the PIM Hello with the ConnectionID, and disable the check if they are different. But I would prefer a single configuration option. I think it's better to require manual configuration than to have built in "intelligence". > FWIW, I think there is no standard API for TCP TTL checking in the > application (e.g. in Linux, IP_RECVTTL is not supported with TCP). This > needs to be done in the kernel or by filtering. Right, was afraid so. This may not be that critical though, but I was curious. If it is becoming common to do this kind of filtering for TCP, then it would be good if the IETF pushed for an API, like a setsockopt() to be standardized. Stig From eckert@cisco.com Tue Feb 8 10:28:24 2011 Return-Path: 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 8F18E3A67E9 for ; Tue, 8 Feb 2011 10:28:24 -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 IfvZFcQlOOV2 for ; Tue, 8 Feb 2011 10:28:23 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1D2ED3A6812 for ; Tue, 8 Feb 2011 10:28:21 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Feb 2011 18:28:28 +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 p18ISSXu005091; Tue, 8 Feb 2011 18:28:28 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 p18ISS8t012526; Tue, 8 Feb 2011 10:28:28 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18ISRPj012525; Tue, 8 Feb 2011 10:28:27 -0800 Date: Tue, 8 Feb 2011 10:28:27 -0800 From: Toerless Eckert To: Stig Venaas Message-ID: <20110208182827.GS22898@cisco.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D515FD2.6090705@venaas.com> <4D518608.1070902@venaas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D518608.1070902@venaas.com> User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:28:24 -0000 On Tue, Feb 08, 2011 at 10:06:00AM -0800, Stig Venaas wrote: > >MUST send by default to TTL=255 > >MUST check at receipt by default that TTL=255 > > I think this is too strict. But I'm happy to encourage > implementations to support it (more like a SHOULD). > > So I think we may agree that this check can be useful. And also > that we should say something about it in the draft. The main issue > is whether it should be required, and whether it should be on by > default. Or going to back what i tried to say initially: We shouldn't put in stronger requirements than what we know exists in unicast protocols. Admittedly something like BGP with decades of hstory is a bad protocol to expect having the strongest security requirements, but if there is so much agreement that GTSM is a MUST then ther should be any other protocol from the IETF thats newer and that has the "MUST check". PORT should not be the first one to explore such a MUST. Cheers Toerless From jeff.tantsura@ericsson.com Tue Feb 8 10:53:39 2011 Return-Path: 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 31DEC3A681C for ; Tue, 8 Feb 2011 10:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 EMD0VGlGQpFG for ; Tue, 8 Feb 2011 10:53:38 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 3D82A3A67F5 for ; Tue, 8 Feb 2011 10:53:38 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p18JbRxu001024; Tue, 8 Feb 2011 13:37:28 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 8 Feb 2011 13:53:36 -0500 From: Jeff Tantsura To: Toerless Eckert , Stig Venaas Date: Tue, 8 Feb 2011 13:53:35 -0500 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHvgxIjFbNVvZpQFGQEMjktINPWwAAI9LA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60AA0B03FDD@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D515FD2.6090705@venaas.com> <4D518608.1070902@venaas.com> <20110208182827.GS22898@cisco.com> In-Reply-To: <20110208182827.GS22898@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:53:39 -0000 Agree, it should be SHOULD rather than MUST, let's provide means to configu= re it and if an operator things it is necessary and doesn't break their net= work, we as a vendor will be more than happy to provide functionality to do= so. +1 Toerless=20 Regards, Jeff =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Toerl= ess Eckert Sent: Tuesday, February 08, 2011 10:28 To: Stig Venaas Cc: Yiqun Cai; Pekka Savola; pim@ietf.org Subject: Re: [pim] TTL for PORT On Tue, Feb 08, 2011 at 10:06:00AM -0800, Stig Venaas wrote: > >MUST send by default to TTL=3D255 > >MUST check at receipt by default that TTL=3D255 >=20 > I think this is too strict. But I'm happy to encourage > implementations to support it (more like a SHOULD). >=20 > So I think we may agree that this check can be useful. And also > that we should say something about it in the draft. The main issue > is whether it should be required, and whether it should be on by > default. Or going to back what i tried to say initially: We shouldn't put in stronger requirements than what we know exists in unicast protocols. Admittedly something like BGP with decades of hstory is a bad protocol to expect having the strongest security requirements, but if there is so much agreement that GTSM is a MUST then ther should be any other protocol from the IETF thats newer and that has the "MUST check". PORT should not be the first one to explore such a MUST. Cheers Toerless _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Tue Feb 8 11:10:24 2011 Return-Path: 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 12F873A6828 for ; Tue, 8 Feb 2011 11:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.606 X-Spam-Level: X-Spam-Status: No, score=-100.606 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 CqvQQn3Km+qo for ; Tue, 8 Feb 2011 11:10:23 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 823DC3A681C for ; Tue, 8 Feb 2011 11:10:22 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a] (unknown [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a]) by ufisa.uninett.no (Postfix) with ESMTPSA id 0B4A37FEF; Tue, 8 Feb 2011 20:10:27 +0100 (CET) Message-ID: <4D519520.9090402@venaas.com> Date: Tue, 08 Feb 2011 11:10:24 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeff Tantsura References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D515FD2.6090705@venaas.com> <4D518608.1070902@venaas.com> <20110208182827.GS22898@cisco.com> <0ED867EB33AB2B45AAB470D5A64CDBF60AA0B03FDD@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60AA0B03FDD@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:10:24 -0000 On 2/8/2011 10:53 AM, Jeff Tantsura wrote: > Agree, it should be SHOULD rather than MUST, let's provide means to configure it and if an operator things it is necessary and doesn't break their network, we as a vendor will be more than happy to provide functionality to do so. I have now looked at various RFCs, like: RFC 3682, RFC 4953, RFC 5405, RFC 4381, RFC 4732, RFC 4778 and none of them say it should be done by default. That is, 3682 says Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis. GTSM SHOULD NOT be enabled by default. Some of the other RFCs are more operational and give recommendations to operators. BTW, many operators have other filtering that makes GTSM less important. As it says in 3682: (ii) It is common practice for many service providers to ingress filter (deny) packets that have the provider's loopback addresses as the source IP address. So I'll update the version of the draft I'm just about to post, with a SHOULD. Something like: Implementations SHOULD provide a configuration option for enabling GTSM. Of course anyone's opinions are welcome and I'll do what seems to be the WGs opinion. Stig > +1 Toerless > > Regards, > Jeff > > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Tuesday, February 08, 2011 10:28 > To: Stig Venaas > Cc: Yiqun Cai; Pekka Savola; pim@ietf.org > Subject: Re: [pim] TTL for PORT > > On Tue, Feb 08, 2011 at 10:06:00AM -0800, Stig Venaas wrote: >>> MUST send by default to TTL=255 >>> MUST check at receipt by default that TTL=255 >> >> I think this is too strict. But I'm happy to encourage >> implementations to support it (more like a SHOULD). >> >> So I think we may agree that this check can be useful. And also >> that we should say something about it in the draft. The main issue >> is whether it should be required, and whether it should be on by >> default. > > Or going to back what i tried to say initially: We shouldn't put in > stronger requirements than what we know exists in unicast protocols. > Admittedly something like BGP with decades of hstory is a bad protocol > to expect having the strongest security requirements, but if there > is so much agreement that GTSM is a MUST then ther should be any other > protocol from the IETF thats newer and that has the "MUST check". > PORT should not be the first one to explore such a MUST. > > Cheers > Toerless > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Tue Feb 8 11:23:13 2011 Return-Path: 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 951093A672E for ; Tue, 8 Feb 2011 11:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.603 X-Spam-Level: X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Xjvcw03lQ+Zf for ; Tue, 8 Feb 2011 11:23:12 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 9D2B53A67D6 for ; Tue, 8 Feb 2011 11:23:12 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a] (unknown [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a]) by ufisa.uninett.no (Postfix) with ESMTPSA id DE37D7FEF; Tue, 8 Feb 2011 20:23:18 +0100 (CET) Message-ID: <4D519824.1050506@venaas.com> Date: Tue, 08 Feb 2011 11:23:16 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pim@ietf.org" References: <31D55C4D55BEED48A4459EB64567589A108114957C@BLRKECMBX02.ad.infosys.com>, <4D0913E1.1080603@venaas.com> <31D55C4D55BEED48A4459EB64567589A108114957F@BLRKECMBX02.ad.infosys.com>, <4D0A5DAB.1010204@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149580@BLRKECMBX02.ad.infosys.com>, <4D0BF567.6030206@venaas.com> <31D55C4D55BEED48A4459EB64567589A1081149581@BLRKECMBX02.ad.infosys.com>, <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:23:13 -0000 It's nice to see all this activity on the wg list :) One remaining issue, and which you may have thoughts on, is whether keep-alives should be TCP keep-alives or in PORT itself. I hope we have some kind of agreement that keep-alives can be useful to detect error conditions, and that it is good to allow some kind of keep-alive to be enabled. I prefer for it to be off by default though. Do you see good reasons for doing one rather than the other? I think a benefit of doing it in PORT is that you check that the communication path is working all the way from PIM process to PIM process, rather than just TCP. I'm also wondering whether it is useful to detect that the neighbor has failed to send keep-alives. If we choose to do keep-alives in PORT, then I think it should only be in the absence of other traffic. I.e. you restart a timer every time you send a PORT message. If the timer expires, you send a keep-alive. Stig From eckert@cisco.com Tue Feb 8 11:52:31 2011 Return-Path: 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 6EEE13A681B for ; Tue, 8 Feb 2011 11:52:31 -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 zLK5hB3ukb0G for ; Tue, 8 Feb 2011 11:52:30 -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 D00C93A67C3 for ; Tue, 8 Feb 2011 11:52:29 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACcuUU2rR7H+/2dsb2JhbAClN3OhWps7hVoEhHuGbw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 19:52:37 +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 p18JqbsU002444; Tue, 8 Feb 2011 19:52:37 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 p18JqaFL016138; Tue, 8 Feb 2011 11:52:36 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18JqahN016137; Tue, 8 Feb 2011 11:52:36 -0800 Date: Tue, 8 Feb 2011 11:52:36 -0800 From: Toerless Eckert To: Stig Venaas Message-ID: <20110208195236.GU22898@cisco.com> References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D519824.1050506@venaas.com> User-Agent: Mutt/1.4.2.2i Cc: "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:52:31 -0000 Any reason why the BFD faction shouldn't jump up and declare further keepalives obsolete ? Btw: when it comes to all these environmental factors of PORT, i think it would be good to consider taking guidance from LDP. When we designed MPLS support for multicast, we originally started thinking it should be over TCP directly, but we just got tired of figuring out neighbor discovery, graceful restart, addressing, and the like. So we put it over LDP and called it mLDP. Of course, PORT should not use LDP, but if you remove all the label stuff from LDP, the rest of the protocol can give good guidance on how to do things in PORT if in doubt. Definitely closer to PORT than BGP (which is the other widely deployed unicast TCP based protocol). Just saying ;-)) I know it's always dangerous to mention label protocols in the non-label world or vice versa ;-)) Cheers Toerless On Tue, Feb 08, 2011 at 11:23:16AM -0800, Stig Venaas wrote: > It's nice to see all this activity on the wg list :) > > One remaining issue, and which you may have thoughts on, > is whether keep-alives should be TCP keep-alives or in > PORT itself. > > I hope we have some kind of agreement that keep-alives > can be useful to detect error conditions, and that it is > good to allow some kind of keep-alive to be enabled. I > prefer for it to be off by default though. > > Do you see good reasons for doing one rather than the > other? I think a benefit of doing it in PORT is that > you check that the communication path is working all > the way from PIM process to PIM process, rather than > just TCP. I'm also wondering whether it is useful to > detect that the neighbor has failed to send keep-alives. > > If we choose to do keep-alives in PORT, then I think > it should only be in the absence of other traffic. > I.e. you restart a timer every time you send a PORT > message. If the timer expires, you send a keep-alive. > > Stig > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture Network Agnostic: Applications that work best on cheap, stupid networks. Suicide: Devaluating the intelligent network with network agnostic apps. From stig@venaas.com Tue Feb 8 12:14:50 2011 Return-Path: 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 F0D573A67C3 for ; Tue, 8 Feb 2011 12:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.935 X-Spam-Level: X-Spam-Status: No, score=-101.935 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 G1CNEmkX7e9n for ; Tue, 8 Feb 2011 12:14:50 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id BF7DF3A683B for ; Tue, 8 Feb 2011 12:14:46 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a] (unknown [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3A8827FED; Tue, 8 Feb 2011 21:14:53 +0100 (CET) Message-ID: <4D51A439.5030606@venaas.com> Date: Tue, 08 Feb 2011 12:14:49 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Toerless Eckert References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> In-Reply-To: <20110208195236.GU22898@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:14:51 -0000 On 2/8/2011 11:52 AM, Toerless Eckert wrote: > Any reason why the BFD faction shouldn't jump up and declare > further keepalives obsolete ? Certainly. Which is one reason for not always doing keep-alives. Even though I see some benefit with keep-alives (if not doing BFD), I'm also fine with not defining keep-alives now, and adding it later if real life experience with PORT shows that it is needed. The options are: No keep-alive PORT keep-alive TCP keep-alive Stig From erosen@cisco.com Tue Feb 8 12:46:23 2011 Return-Path: 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 DEB293A6880 for ; Tue, 8 Feb 2011 12:46:23 -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 nSMWXq1FE2dY for ; Tue, 8 Feb 2011 12:46:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EF18E3A6859 for ; Tue, 8 Feb 2011 12:46:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 20:46:30 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18KkUrK001368; Tue, 8 Feb 2011 20:46:30 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p18KkT3t029540; Tue, 8 Feb 2011 15:46:29 -0500 To: "Bhatia, Manav (Manav)" In-reply-to: Your message of Tue, 08 Feb 2011 21:02:15 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8F@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 08 Feb 2011 15:46:29 -0500 Message-ID: <29539.1297197989@erosen-linux> From: Eric Rosen Cc: Yiqun Cai , "pim@ietf.org" Subject: Re: [pim] TTL for PORT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:46:24 -0000 Manav> How would the PIM hello message which goes with TTL=1 reach the PIM Manav> neighbor which is multiple hops away. If you really want to do this Manav> then the PIM hello message should also be changed. You're right, the Hello mechanism needs some work (or replacement) in order to facilitate the use of PORT across multiple hops, e.g., using a different IP destination address. Pekka> Various signalling mechanisms (PIM Hellos or whatever) that would Pekka> configure PORT to be used by non-adjacent neighbors or in Pekka> non-TTL-preserving tunnel scenarios could reconfigure or disable the Pekka> check as part of the procedure. Fair enough. Stig> But I would prefer a single configuration option. The spec should not require that there be manual configuration, or that the check apply (or not apply) to all adjacencies. The proper default for a given adjacency really depends on how the adjacency is discovered. From erosen@cisco.com Tue Feb 8 12:59:24 2011 Return-Path: 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 799243A6863 for ; Tue, 8 Feb 2011 12:59:24 -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 EoXtJvtm84jB for ; Tue, 8 Feb 2011 12:59:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AA2D53A684C for ; Tue, 8 Feb 2011 12:59:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 20:59:31 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p18KxVHP025989; Tue, 8 Feb 2011 20:59:31 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p18KxUuj029691; Tue, 8 Feb 2011 15:59:30 -0500 To: Toerless Eckert In-reply-to: Your message of Tue, 08 Feb 2011 11:52:36 -0800. <20110208195236.GU22898@cisco.com> Date: Tue, 08 Feb 2011 15:59:30 -0500 Message-ID: <29690.1297198770@erosen-linux> From: Eric Rosen Cc: "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:59:24 -0000 > if you remove all the label stuff from LDP, the rest of the protocol can > give good guidance on how to do things in PORT LDP does have a keepalive timer, and an LDP speaker expects to receive some LDP PDU from its peer before the timer expires. There is a keepalive message, but that is only sent if nothing else has been sent during the keepalive interval. BGP has a similar keepalive, I believe. I don't think anyone really knows for sure whether these are valuable or not, but they don't seem to do any harm. If an application level keepalive is defined, I don't think there's much point to having it off by default. From stig@venaas.com Tue Feb 8 13:06:53 2011 Return-Path: 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 82CAD3A683C for ; Tue, 8 Feb 2011 13:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 S4UJaSP222Hx for ; Tue, 8 Feb 2011 13:06:52 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 720493A683A for ; Tue, 8 Feb 2011 13:06:52 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a] (unknown [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a]) by ufisa.uninett.no (Postfix) with ESMTPSA id A15247FAC; Tue, 8 Feb 2011 22:06:58 +0100 (CET) Message-ID: <4D51B06E.4050302@venaas.com> Date: Tue, 08 Feb 2011 13:06:54 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: erosen@cisco.com References: <29539.1297197989@erosen-linux> In-Reply-To: <29539.1297197989@erosen-linux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:06:53 -0000 On 2/8/2011 12:46 PM, Eric Rosen wrote: > Manav> How would the PIM hello message which goes with TTL=1 reach the PIM > Manav> neighbor which is multiple hops away. If you really want to do this > Manav> then the PIM hello message should also be changed. > > You're right, the Hello mechanism needs some work (or replacement) in order > to facilitate the use of PORT across multiple hops, e.g., using a different > IP destination address. > > Pekka> Various signalling mechanisms (PIM Hellos or whatever) that would > Pekka> configure PORT to be used by non-adjacent neighbors or in > Pekka> non-TTL-preserving tunnel scenarios could reconfigure or disable the > Pekka> check as part of the procedure. > > Fair enough. > > Stig> But I would prefer a single configuration option. > > The spec should not require that there be manual configuration, or that the > check apply (or not apply) to all adjacencies. The proper default for a > given adjacency really depends on how the adjacency is discovered. I agree. I've now written the following text for the new version of the draft (I did not include per adjacency, I can try to add that if you think it is important). But note that unless you want to statically configure IP addresses of neighbors, it's more per interface than per adjacency. Other things, like ConnectionID, is also per interface, so I think that is OK. Implementations SHOULD support the Generalized TTL Security Mechanism (GTSM) [RFC3682]. We RECOMMEND that it is disabled by default. When this mechanism is enabled, TCP/SCTP packets are sent with a TTL/Hop-Limit of 255, and a directly connected neighbor only accepts inbound packets with a TTL/Hop-Limit of 255. For further details, see [RFC3682]. We have a similar problem with TCP encryption (AO/MD5) where you have to configure the key per interface rather than per adjacency (unless statically configuring neighors). Stig > > > > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From manav.bhatia@alcatel-lucent.com Tue Feb 8 14:22:58 2011 Return-Path: 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 754783A6835 for ; Tue, 8 Feb 2011 14:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 KP7V+VGNfBuu for ; Tue, 8 Feb 2011 14:22:57 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 4A1E93A6891 for ; Tue, 8 Feb 2011 14:22:57 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p18MN0on019513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 16:23:03 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18MMvr6023785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 03:52:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 9 Feb 2011 03:52:57 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas , Toerless Eckert Date: Wed, 9 Feb 2011 03:52:54 +0530 Thread-Topic: [pim] PORT and keep-alives Thread-Index: AcvHzOHdofuqlr0ZSDKFQE3H1XrmlQAEXIog Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> In-Reply-To: <4D51A439.5030606@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:22:58 -0000 Hi Stig,=20 I would prefer PORT keep-alives, with a CLI knob to turn them off if not re= quired. Using TCP keep-alive only ensures that the TCP connection (at the TCP socke= t layer) is up. It does not indicate if the PORT session is up. Thus TCP ke= epalives will NOT detect a PORT task that is say deadlocked with some other= task in the system. Its thus imperative that we have this connectivity che= ck at the application layer. Cheers, Manav > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On=20 > Behalf Of Stig Venaas > Sent: Wednesday, February 09, 2011 1.45 AM > To: Toerless Eckert > Cc: pim@ietf.org > Subject: Re: [pim] PORT and keep-alives >=20 > On 2/8/2011 11:52 AM, Toerless Eckert wrote: > > Any reason why the BFD faction shouldn't jump up and declare > > further keepalives obsolete ? >=20 > Certainly. Which is one reason for not always doing keep-alives. > Even though I see some benefit with keep-alives (if not doing > BFD), I'm also fine with not defining keep-alives now, and > adding it later if real life experience with PORT shows that > it is needed. >=20 > The options are: >=20 > No keep-alive > PORT keep-alive > TCP keep-alive >=20 > Stig > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > = From manav.bhatia@alcatel-lucent.com Tue Feb 8 14:30:22 2011 Return-Path: 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 950373A6857 for ; Tue, 8 Feb 2011 14:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ak1vocRPAwtt for ; Tue, 8 Feb 2011 14:30:18 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B49423A686C for ; Tue, 8 Feb 2011 14:30:15 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p18MUIfO022617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 16:30:21 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18MUILk024110 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 04:00:18 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 9 Feb 2011 04:00:17 +0530 From: "Bhatia, Manav (Manav)" To: "erosen@cisco.com" Date: Wed, 9 Feb 2011 04:00:14 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvH0UcjgAHxcVb5Swm/oNqz640hTAADYwWg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE5@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of Tue, 08 Feb 2011 21:02:15 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8F@INBANSXCHMBSA1.in.alcatel-lucent.com> <29539.1297197989@erosen-linux> In-Reply-To: <29539.1297197989@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:30:22 -0000 Eric, > Manav> How would the PIM hello message which goes with TTL=3D1=20 > reach the PIM > Manav> neighbor which is multiple hops away. If you really=20 > want to do this > Manav> then the PIM hello message should also be changed. >=20 > You're right, the Hello mechanism needs some work (or=20 > replacement) in order > to facilitate the use of PORT across multiple hops, e.g.,=20 > using a different > IP destination address. If we envisage PORT to ever work on non directly connected neighbors, like = for example two ends of a point-to-multipoint LSP, then the HELLO discovery= message should probably use unicast UDP similar to how its done for LDP. Also multihop PORT connection will only work when there is a tunnel separat= ing the two ends of the PORT neighbors because otherwise the multicast pack= ets will get dropped between these two routers (as they are not aware of th= e Joins being exchanged between them).=20 Cheers, Manav= From stig@venaas.com Tue Feb 8 14:44:27 2011 Return-Path: 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 D33C03A687A for ; Tue, 8 Feb 2011 14:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Af0BlrQ63-gk for ; Tue, 8 Feb 2011 14:44:26 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id A1C273A6857 for ; Tue, 8 Feb 2011 14:44:26 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a] (unknown [IPv6:2001:420:4:ea0c:5cf8:a1c5:88c1:9e9a]) by ufisa.uninett.no (Postfix) with ESMTPSA id C31847FF0; Tue, 8 Feb 2011 23:44:32 +0100 (CET) Message-ID: <4D51C74C.2060805@venaas.com> Date: Tue, 08 Feb 2011 14:44:28 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:44:27 -0000 On 2/8/2011 2:22 PM, Bhatia, Manav (Manav) wrote: > Hi Stig, > > I would prefer PORT keep-alives, with a CLI knob to turn them off if not required. > > Using TCP keep-alive only ensures that the TCP connection (at the TCP socket layer) is up. It does not indicate if the PORT session is up. Thus TCP keepalives will NOT detect a PORT task that is say deadlocked with some other task in the system. Its thus imperative that we have this connectivity check at the application layer. Yes, I think doing it with PORT messages provides more info. Note though that in our case we have PIM Hello's, so if say the PIM process stopped responding, or whatever, the neighborship would expire. Of course it is possible that the PIM process keeps sending Hello's and something else goes wrong. Another thing, how helpful is it to notice that PORT is not working, if all you can do is establish a new connection. I think it might be helpful, I'm trying to get a better understanding of why. Main thing I can think of is alerting operators, logging/debugging. Sending keep-alives would make the session eventually reset if there are no ACKs, but you probably also want to reset the connection if you don't receive any messages from your neighbor then? Assuming that either both or none of the peers are doing keep-alive. Stig > Cheers, Manav > >> -----Original Message----- >> From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On >> Behalf Of Stig Venaas >> Sent: Wednesday, February 09, 2011 1.45 AM >> To: Toerless Eckert >> Cc: pim@ietf.org >> Subject: Re: [pim] PORT and keep-alives >> >> On 2/8/2011 11:52 AM, Toerless Eckert wrote: >>> Any reason why the BFD faction shouldn't jump up and declare >>> further keepalives obsolete ? >> >> Certainly. Which is one reason for not always doing keep-alives. >> Even though I see some benefit with keep-alives (if not doing >> BFD), I'm also fine with not defining keep-alives now, and >> adding it later if real life experience with PORT shows that >> it is needed. >> >> The options are: >> >> No keep-alive >> PORT keep-alive >> TCP keep-alive >> >> Stig >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim From manav.bhatia@alcatel-lucent.com Tue Feb 8 14:51:27 2011 Return-Path: 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 9E97C3A67D4 for ; Tue, 8 Feb 2011 14:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WXeb0W+NLTJC for ; Tue, 8 Feb 2011 14:51:26 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 193FB3A67A1 for ; Tue, 8 Feb 2011 14:51:26 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p18MpTaO019418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 16:51:32 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18MpTrv024956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 04:21:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 9 Feb 2011 04:21:29 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Wed, 9 Feb 2011 04:21:26 +0530 Thread-Topic: [pim] PORT and keep-alives Thread-Index: AcvH4cwszclgTY6WQ2WETh8bKjAXswAADZUw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> In-Reply-To: <4D51C74C.2060805@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:51:27 -0000 >=20 > Sending keep-alives would make the session eventually reset > if there are no ACKs, but you probably also want to reset > the connection if you don't receive any messages from your > neighbor then? Assuming that either both or none of the > peers are doing keep-alive. The reason most protocols use keep-alives is to inform to the remote peer a= bout their liveliness. So its symmetrical and is turned on on both sides.=20 Since we have PIM hellos that also pretty much does the same thing we shoul= d imo define the keep-alives in PORT and put in some text in the draft that= PORT neighbors MAY want to use it for liveliness detection. Cheers, Manav From manav.bhatia@alcatel-lucent.com Tue Feb 8 14:56:16 2011 Return-Path: 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 5A7383A682B for ; Tue, 8 Feb 2011 14:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3+4-9xDWJf42 for ; Tue, 8 Feb 2011 14:56:15 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6CDE93A6827 for ; Tue, 8 Feb 2011 14:56:15 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p18MuGhI021817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 16:56:19 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18MuGCr025178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 04:26:16 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 9 Feb 2011 04:26:16 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas , Jeff Tantsura Date: Wed, 9 Feb 2011 04:26:09 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvHw94lc3lwadX2REqTbFIBCYbjcgAHaPKA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEE@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <4D5154AB.1030600@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C89@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208150434.GO22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D515FD2.6090705@venaas.com> <4D518608.1070902@venaas.com> <20110208182827.GS22898@cisco.com> <0ED867EB33AB2B45AAB470D5A64CDBF60AA0B03FDD@EUSAACMS0701.eamcs.ericsson.se> <4D519520.9090402@venaas.com> In-Reply-To: <4D519520.9090402@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Pekka, Toerless Eckert , Yiqun Cai , Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:56:16 -0000 =20 > and none of them say it should be done by default. That is, > 3682 says You should actually look at RFC 5082 which is a standards-track RFC as oppo= sed to 3682 which was experimental. >=20 > Use of GTSM is OPTIONAL, and can be configured on a per-peer > (group) basis. > GTSM SHOULD NOT be enabled by default. The was done for ensuring backward compatibility for protocols that were de= veloped before GTSM technique became well known. PORT is a new protocol and= we need not be that strict about it not turning this on by default. I have another clarification that I seek.=20 Are we in agreement that PORT by default should use the TTL=3D255? Is there= any opposition to that? Now whats being contended is whether the receivers should verify this TTL o= r not. I think it would be ok to say that receiver MAY want to verify the TTL of t= he incoming PORT message based on GTSM. >=20 > Implementations SHOULD provide a configuration option for enabling > GTSM. Yes, as long as this means turning on the receiver behavior. We MUST always= send PORT messages with TTL=3D255. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Tue Feb 8 15:32:07 2011 Return-Path: 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 7A4023A6836 for ; Tue, 8 Feb 2011 15:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 x3MVtVRzH2Xu for ; Tue, 8 Feb 2011 15:32:06 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AD0213A67AD for ; Tue, 8 Feb 2011 15:32:06 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p18NW9M1020145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 17:32:12 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18NW8UB026675 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 05:02:08 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 9 Feb 2011 05:02:08 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas , "pim@ietf.org" Date: Wed, 9 Feb 2011 05:02:06 +0530 Thread-Topic: [pim] PORT and Datagram PIM Thread-Index: AcvG9TboYgMi/+E9QDyrxxoCH6Cl7gA8bVSg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFC@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D503A5B.9070706@venaas.com> In-Reply-To: <4D503A5B.9070706@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: Re: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:32:07 -0000 Hi Stig, > > I don't think I understand the reason why an operator would=20 > want to transition to the datagram mode when two routers are=20 > advertising the PORT capability in their PIM Hellos. If they=20 > want to revert to the datagram mode then it should be=20 > configured though the CLI and routers should stop advertising=20 > this capability in their Hellos. >=20 > Yes, I agree with you on this point. This is also what the > draft says. In that case we must remove the following line from Sec 3.1: When the router cannot setup a TCP connection, it will refrain from includi= ng this option. I don't think implementations should automatically revert to the datagram m= ode. The above statement actually causes more problems than without being t= here. Since there is no guidance on when implementations should refrain fro= m including this option we can easily get into interoperability problems wh= ere A and B are trying to establish a TCP connection but are unable to do s= o. A, based on the above text decides to send PIM Hellos with the PORT capa= bility, while B still continues to send Hellos including this capability. B= may never stop doing this since the RFC says that PORT capable routers MUS= T always send this capability. This brings another aspect that I don't think is covered in the current tex= t. What should A do if it is PORT capable and it receives Hello messages witho= ut this capability. Should it downgrade and not include this capability in = the subsequent Hellos? I think we should include some text discussing this = as well. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Tue Feb 8 15:33:55 2011 Return-Path: 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 336313A67AD for ; Tue, 8 Feb 2011 15:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6FWdPcc8lhqk for ; Tue, 8 Feb 2011 15:33:54 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 53F123A688C for ; Tue, 8 Feb 2011 15:33:54 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p18NXxK1003415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 17:34:01 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18NXwP6026683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 05:03:58 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 9 Feb 2011 05:03:58 +0530 From: "Bhatia, Manav (Manav)" To: "Bhatia, Manav (Manav)" , Stig Venaas , "pim@ietf.org" Date: Wed, 9 Feb 2011 05:03:58 +0530 Thread-Topic: [pim] PORT and Datagram PIM Thread-Index: AcvG9TboYgMi/+E9QDyrxxoCH6Cl7gA8bVSgAABoIgA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFD@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D503A5B.9070706@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFC@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFC@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: Re: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:33:55 -0000 =20 > option we can easily get into interoperability problems where=20 > A and B are trying to establish a TCP connection but are=20 > unable to do so. A, based on the above text decides to send=20 > PIM Hellos with the PORT capability, while B still continues=20 It's a typo here - I mean A sends PIM Hellos *without* the PORT capability. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Tue Feb 8 15:56:36 2011 Return-Path: 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 023413A68DE for ; Tue, 8 Feb 2011 15:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9a7aWajJeIN1 for ; Tue, 8 Feb 2011 15:56:35 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 538313A68B1 for ; Tue, 8 Feb 2011 15:56:25 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p18NuUxE022774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Feb 2011 17:56:32 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18NuTk3020699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Feb 2011 05:26:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 9 Feb 2011 05:26:29 +0530 From: "Bhatia, Manav (Manav)" To: "pim@ietf.org" Date: Wed, 9 Feb 2011 05:26:33 +0530 Thread-Topic: TCP Connection ID Thread-Index: AcvH69ACZN6UP17tRAONAvfTrJ2LKQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:56:36 -0000 Hi, Assume A and B have a PORT session established. Now A receives a PIM Hello = message from B with a different Connection ID. What should it do? Should it= kill the existing TCP session and establish a new one or should it ignore = this change as long as the PORT session is up (i.e. PORT keepalives continu= e being exchanged). I think it should be the latter, however this needs to be discussed and add= ressed in the spec. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From pekkas@netcore.fi Tue Feb 8 22:21:26 2011 Return-Path: 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 7F1083A6900 for ; Tue, 8 Feb 2011 22:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fanT2E1C7G+0 for ; Tue, 8 Feb 2011 22:21:22 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 2E5663A685D for ; Tue, 8 Feb 2011 22:21:21 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p196LG4L011266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 08:21:16 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p196LGue011263; Wed, 9 Feb 2011 08:21:16 +0200 Date: Wed, 9 Feb 2011 08:21:16 +0200 (EET) From: Pekka Savola To: Stig Venaas In-Reply-To: <4D51B06E.4050302@venaas.com> Message-ID: References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:21:26 -0000 On Tue, 8 Feb 2011, Stig Venaas wrote: > I agree. I've now written the following text for the new version of the > draft (I did not include per adjacency, I can try to add that if you > think it is important). But note that unless you want to statically > configure IP addresses of neighbors, it's more per interface than per > adjacency. Other things, like ConnectionID, is also per interface, so > I think that is OK. > > Implementations SHOULD support the Generalized TTL Security > Mechanism (GTSM) [RFC3682]. We RECOMMEND that it is > disabled by default. When this mechanism is enabled, TCP/SCTP > packets are sent with a TTL/Hop-Limit of 255, and a directly > connected neighbor only accepts inbound packets with a > TTL/Hop-Limit of 255. For further details, see [RFC3682]. The very minimum that needs to happen is that by default, packets are sent with TTL=255. This enables the other end to have the choice whether to enable it or not. Checking on receipt could be a SHOULD. Isn't the fact that a peer is receiving a PIM Hello which was sent with TTL=1 proof enough that TTL decrement is not happening? In any case, if negotiation or TTL changes are expected, these should be done as part of establishing the adjacency. I suggest rephrasing this: TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to facilitate enabling of Generalized TTL Security Mechanism [RFC5082] by neighbors. Directly connected neighbors see the inbound packets with a TTL/Hop Limit as 255, and the implementations SHOULD enable GTSM check by default on receipt [RFC5082]. Implementations SHOULD provide a configuration option to disable the check or change the accepted TTL/Hop Limit threshold. This configuration capability MAY be used by signalling protocol(s) establishing PORT adjacencies to disable the check when required. > We have a similar problem with TCP encryption (AO/MD5) where you > have to configure the key per interface rather than per adjacency > (unless statically configuring neighors). No, this is absolutely a different thing. TCP AO always requires manual keying. GTSM in normal case does not require manual action. The typical case of PIM is an adjacency between direct neighbors (PIM Hello); other types of adjacencies are not even supported at the moment. Manual actions are only required in (what appears to me) special circumstances. Therefore it follows that GTSM should be enabled by default (because enabling by default is relatevely "safe"), and TCP AO cannot (because there is no default keying). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From eckert@cisco.com Wed Feb 9 00:38:49 2011 Return-Path: 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 E84053A694E for ; Wed, 9 Feb 2011 00:38:49 -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 cUIchfZXohHD for ; Wed, 9 Feb 2011 00:38:49 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 26EAE3A6885 for ; Wed, 9 Feb 2011 00:38:49 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2011 08:38:58 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p198cwLV018509; Wed, 9 Feb 2011 08:38:58 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 p198cvQt018078; Wed, 9 Feb 2011 00:38:57 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p198cun5018077; Wed, 9 Feb 2011 00:38:56 -0800 Date: Wed, 9 Feb 2011 00:38:56 -0800 From: Toerless Eckert To: Pekka Savola Message-ID: <20110209083856.GC22898@cisco.com> References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 08:38:50 -0000 On Wed, Feb 09, 2011 at 08:21:16AM +0200, Pekka Savola wrote: > I suggest rephrasing this: > > TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to > facilitate enabling of Generalized TTL Security Mechanism > [RFC5082] by neighbors. > > Directly connected neighbors see the inbound packets with a > TTL/Hop Limit as 255, and the implementations SHOULD enable GTSM > check by default on receipt [RFC5082]. Implementations SHOULD ^ for these neighbors > provide a configuration option to disable the check or change the > accepted TTL/Hop Limit threshold. This configuration capability > MAY be used by signalling protocol(s) establishing PORT > adjacencies to disable the check when required. This makes it clearer that we should enable by default GTSM only for directly connected neighbor. The text still doesn't make any expllicit statements about the defaults for non-directly connected neighbors, which i think is in-line with the rest of the PORT spec: We kinda want to be able to support tem, but there are no specifics. From pekkas@netcore.fi Wed Feb 9 01:00:25 2011 Return-Path: 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 B42273A6950 for ; Wed, 9 Feb 2011 01:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 KbCPwC8-KCam for ; Wed, 9 Feb 2011 01:00:25 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 328303A6968 for ; Wed, 9 Feb 2011 01:00:23 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1990PDw013827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 11:00:25 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1990PKu013823; Wed, 9 Feb 2011 11:00:25 +0200 Date: Wed, 9 Feb 2011 11:00:25 +0200 (EET) From: Pekka Savola To: Toerless Eckert In-Reply-To: <20110209083856.GC22898@cisco.com> Message-ID: References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:00:25 -0000 On Wed, 9 Feb 2011, Toerless Eckert wrote: >> Directly connected neighbors see the inbound packets with a >> TTL/Hop Limit as 255, and the implementations SHOULD enable GTSM >> check by default on receipt [RFC5082]. Implementations SHOULD > ^ > for these neighbors ... > This makes it clearer that we should enable by default GTSM only > for directly connected neighbor. The text still doesn't make any > expllicit statements about the defaults for non-directly > connected neighbors, which i think is in-line with the rest of the > PORT spec: We kinda want to be able to support tem, but there are > no specifics. You make an interesting point. The first part of the text I wrote was meant as informative only. Currently there are no non-directly connected neighbors, right? I could be wrong... So it seems a bit odd to prepare for these in the spec at this point. Obviously, non-directly connected neighbors need to disable TTL checking, but logically this should happen when this kind of behaviour is specified, right? But if non-directly connected neighbors are already in the spec, I agree that the TTL checking at receipt text should address both scenarios. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From eckert@cisco.com Wed Feb 9 01:30:24 2011 Return-Path: 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 E7B753A6956 for ; Wed, 9 Feb 2011 01:30:23 -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 7eqLiRLS-Yqy for ; Wed, 9 Feb 2011 01:30:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8C7153A683B for ; Wed, 9 Feb 2011 01:30:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 09:30:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p199UVo9015127; Wed, 9 Feb 2011 09:30:31 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 p199UUX9020261; Wed, 9 Feb 2011 01:30:30 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p199UUmc020260; Wed, 9 Feb 2011 01:30:30 -0800 Date: Wed, 9 Feb 2011 01:30:30 -0800 From: Toerless Eckert To: Pekka Savola Message-ID: <20110209093030.GH22898@cisco.com> References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:30:24 -0000 >From reading the opinions on this thread it sounds to me the goal of the document should be: "We primarily want to be able to create a complete and sufficient spec for PORT with directly connected neighbor. This doc is incomplete for indirectly connected neighbors, but we foresee that there can be later followup drafts that complete the definition for them. To help this futures, we do not explicitly discuss the connectedness of neighbor in all parts of the document where we do have at least the expectation that it can equally apply to non-directly connected neighbors, but we specify point out the behavior explicitly only for connected neighbors when we do know the behavior would have to be different for non-directly connected ones." That's why i suggested the change in wording. On Wed, Feb 09, 2011 at 11:00:25AM +0200, Pekka Savola wrote: > Currently there are no non-directly connected neighbors, right? I > could be wrong... So it seems a bit odd to prepare for these in the > spec at this point. > > Obviously, non-directly connected neighbors need to disable TTL > checking, but logically this should happen when this kind of behaviour > is specified, right? > > But if non-directly connected neighbors are already in the spec, I > agree that the TTL checking at receipt text should address both > scenarios. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From manav.bhatia@alcatel-lucent.com Wed Feb 9 01:41:48 2011 Return-Path: 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 D92B63A6967 for ; Wed, 9 Feb 2011 01:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HmqB-OKkPr7Y for ; Wed, 9 Feb 2011 01:41:48 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 02BF53A6947 for ; Wed, 9 Feb 2011 01:41:47 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p199fogw018652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 03:41:53 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p199fn8N007358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 15:11:49 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 9 Feb 2011 15:11:49 +0530 From: "Bhatia, Manav (Manav)" To: Pekka Savola , Toerless Eckert Date: Wed, 9 Feb 2011 15:11:49 +0530 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvIOA3AnGej4O02TM+kkcorVFaVUwAA/ROQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6E88@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:41:48 -0000 =20 >=20 > Currently there are no non-directly connected neighbors, right? I=20 > could be wrong... So it seems a bit odd to prepare for these in the=20 > spec at this point. When I started reading this draft I too was under the impression that PORT = is only for directly connected neighbors as its discovered through PIM HELL= Os which go out with TTL=3D1. However, I am beginning to think that we coul= d use it for non directly connected neighbors as well. Here is the scenario= that I have in mind: A -- -- B A and B establish a PORT session. This could either be a trigger for creati= ng an LSP between them or we could have an already existing LSP for the dat= a traffic (beyond the scope of this discussion). B sends PORT JOINs to A (w= hich has to go via multiple hops) which results in A sending multicast traf= fic destined for groups specified in those Joins over the LSP that has been= established (or was pre-established). In this case the intermediate router= s need not be aware of the Joins as they don't switch the multicast traffic= and only route it based on the outer MPLS labels. Specifying GTSM behavior in such cases may be a trifle difficult as we may = not know the exact hops between A and B. > Obviously, non-directly connected neighbors need to disable TTL=20 > checking, but logically this should happen when this kind of=20 > behaviour=20 > is specified, right? I think we should not preclude the possibility of the above happening, in w= hich case we might have to be a little lenient in the receiver behavior. >=20 > But if non-directly connected neighbors are already in the spec, I=20 > agree that the TTL checking at receipt text should address both=20 > scenarios. I don't think the current draft is explicit on this. However, if the above = scenario is possible (and it certainly is) then we must address that in the= current draft. It would also be good if we could extend the PIM PORT disco= very to work with neighbors that are multiple hops away. Cheers, Manav= From stig@venaas.com Wed Feb 9 09:37:33 2011 Return-Path: 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 640FA3A6811 for ; Wed, 9 Feb 2011 09:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 jgWuYsDX7g-p for ; Wed, 9 Feb 2011 09:37:32 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 046803A67A5 for ; Wed, 9 Feb 2011 09:37:32 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 7D2C9800A; Wed, 9 Feb 2011 18:37:40 +0100 (CET) Message-ID: <4D52D0D9.7070705@venaas.com> Date: Wed, 09 Feb 2011 09:37:29 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Toerless Eckert References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> In-Reply-To: <20110209083856.GC22898@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:37:33 -0000 On 2/9/2011 12:38 AM, Toerless Eckert wrote: > On Wed, Feb 09, 2011 at 08:21:16AM +0200, Pekka Savola wrote: >> I suggest rephrasing this: >> >> TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to >> facilitate enabling of Generalized TTL Security Mechanism >> [RFC5082] by neighbors. >> >> Directly connected neighbors see the inbound packets with a >> TTL/Hop Limit as 255, and the implementations SHOULD enable GTSM >> check by default on receipt [RFC5082]. Implementations SHOULD > ^ > for these neighbors > >> provide a configuration option to disable the check or change the >> accepted TTL/Hop Limit threshold. This configuration capability >> MAY be used by signalling protocol(s) establishing PORT >> adjacencies to disable the check when required. > > This makes it clearer that we should enable by default GTSM only > for directly connected neighbor. The text still doesn't make any > expllicit statements about the defaults for non-directly > connected neighbors, which i think is in-line with the rest of the > PORT spec: We kinda want to be able to support tem, but there are > no specifics. I am fine with a MUST for sending. But I'm not so happy about enabling the receiver check by default. My main concern is that you may have a topology like this: A --- B \ / C where A and B are neighbors, and using say loopback addresses for ConnectionIDs so that the TCP connection between A and B end-point addresses are those loopbacks. It may then be that the TCP connection goes via C. This may happen in two cases. 1. If by accident the loopback is not advertised in the IGP on the link A-B, or there could be static routes where one is missing for the loopback for one of the routers. You may say this is a configuration mistake, but it would then make the TCP connection fail. 2. If the link between A and B goes down, the TCP connection would still be up. Let's say there is just a brief flap of the link, it is then better to keep the connection up, than to tear it down, create a new one, and have to do a full update. Also, if the link stays down for some time, keeping the connection allow prunes to be sent and remove state. Also, there are cases where GTSM would not buy you much. For IPv6 you would normally use link-local addresses (if just using PORT between neighbors). Which means the packets can't arrive from off-link. Also, if used between routers in say a core network, there would typically be filters at the edge discarding packets coming from the outside with internal addresses as source, and also filters limiting who can send packets addressed to the routers. Stig From stig@venaas.com Wed Feb 9 09:44:05 2011 Return-Path: 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 397283A69E4 for ; Wed, 9 Feb 2011 09:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 DV+-fykWxib5 for ; Wed, 9 Feb 2011 09:44:04 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 34FB43A67A5 for ; Wed, 9 Feb 2011 09:44:04 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id E081C800A; Wed, 9 Feb 2011 18:44:12 +0100 (CET) Message-ID: <4D52D26A.5070402@venaas.com> Date: Wed, 09 Feb 2011 09:44:10 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:44:05 -0000 On 2/8/2011 2:51 PM, Bhatia, Manav (Manav) wrote: >> >> Sending keep-alives would make the session eventually reset >> if there are no ACKs, but you probably also want to reset >> the connection if you don't receive any messages from your >> neighbor then? Assuming that either both or none of the >> peers are doing keep-alive. > > The reason most protocols use keep-alives is to inform to the remote peer about their liveliness. So its symmetrical and is turned on on both sides. > > Since we have PIM hellos that also pretty much does the same thing we should imo define the keep-alives in PORT and put in some text in the draft that PORT neighbors MAY want to use it for liveliness detection. Do others agree that this is a good plan? I'll take out the current text on TCP keep-alives, define a keep-alive PORT message type, say that implementations MAY (or SHOULD?) support it? I would also prefer to say that it MUST be off by default (I think it's bad if different implementations have different defaults since it would probably make the connection go down if you just use default between two neighbors). I'm thinking the keep-alives should be sent if there are more than 60s since the last PORT message, which means you only send them if there are no other PORT messages being sent. On the receiving end you can take some action if you don't receive them, do we want to describe a particular action? Is 60s a reasonable default interval? Stig > Cheers, Manav From manav.bhatia@alcatel-lucent.com Wed Feb 9 09:50:22 2011 Return-Path: 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 185913A6846 for ; Wed, 9 Feb 2011 09:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vdRJ125DJVrS for ; Wed, 9 Feb 2011 09:50:21 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DD98F3A67A5 for ; Wed, 9 Feb 2011 09:50:20 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p19Ho6AQ006207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 11:50:09 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p19Ho3fK011059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 23:20:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 9 Feb 2011 23:20:03 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Wed, 9 Feb 2011 23:20:01 +0530 Thread-Topic: [pim] PORT and keep-alives Thread-Index: AcvIgPzu42MypUnmTIa7HdHOuJrAJQAAJSsg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F80@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D26A.5070402@venaas.com> In-Reply-To: <4D52D26A.5070402@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:50:22 -0000 =20 > I'm thinking the keep-alives should be sent if there are more than 60s > since the last PORT message, which means you only send them if there > are no other PORT messages being sent. On the receiving end you can > take some action if you don't receive them, do we want to describe a > particular action? Is 60s a reasonable default interval? You'll have to define a Holdtime which would typically be 3 times of the Ke= epalive. Thus a router will have to miss 3 Keepalives, after which the neig= hbor session is torn down. Cheers, Manav= From stig@venaas.com Wed Feb 9 09:52:56 2011 Return-Path: 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 52F1F3A67EE for ; Wed, 9 Feb 2011 09:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 ryt5V5Bp-bvr for ; Wed, 9 Feb 2011 09:52:55 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 9687B3A67A5 for ; Wed, 9 Feb 2011 09:52:51 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 7D7B1800A; Wed, 9 Feb 2011 18:53:00 +0100 (CET) Message-ID: <4D52D47A.8040309@venaas.com> Date: Wed, 09 Feb 2011 09:52:58 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:52:56 -0000 On 2/8/2011 3:56 PM, Bhatia, Manav (Manav) wrote: > Hi, > > Assume A and B have a PORT session established. Now A receives a PIM Hello message from B with a different Connection ID. What should it do? Should it kill the existing TCP session and establish a new one or should it ignore this change as long as the PORT session is up (i.e. PORT keepalives continue being exchanged). > > I think it should be the latter, however this needs to be discussed and addressed in the spec. I remember planning to add text on this. I think the connection should be taken down and re-established. If an administrator makes the decision that connections should be terminated at a new IP address, then I would say that should effect all connections. There may be reasons why do not want the old IP address to be used anymore. If the old address becomes unavailable, then the connection would later fail, but I think it's better to switch immediately. Even if the old IP address remains valid and the TCP connections can stay up, there may be reasons why one wants to change addresses. One example might be that you install a second link between two PIM routers and you decide that you want to do connection sharing. You might start out using just link-local addresses (a likely default for IPv6), but would then need to change to global addresses. Stig > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Wed Feb 9 09:56:25 2011 Return-Path: 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 840783A67BD for ; Wed, 9 Feb 2011 09:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 XY8bKdB2nFIF for ; Wed, 9 Feb 2011 09:56:24 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 58F3B3A67A5 for ; Wed, 9 Feb 2011 09:56:24 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id D4C7E800A; Wed, 9 Feb 2011 18:56:32 +0100 (CET) Message-ID: <4D52D54E.3010707@venaas.com> Date: Wed, 09 Feb 2011 09:56:30 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D26A.5070402@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F80@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F80@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:56:25 -0000 On 2/9/2011 9:50 AM, Bhatia, Manav (Manav) wrote: > >> I'm thinking the keep-alives should be sent if there are more than 60s >> since the last PORT message, which means you only send them if there >> are no other PORT messages being sent. On the receiving end you can >> take some action if you don't receive them, do we want to describe a >> particular action? Is 60s a reasonable default interval? > > You'll have to define a Holdtime which would typically be 3 times of the Keepalive. Thus a router will have to miss 3 Keepalives, after which the neighbor session is torn down. I think the typical "3 times" rule is due to possible packet loss. Is it still reasonable with a reliable transport? Stig > Cheers, Manav From manav.bhatia@alcatel-lucent.com Wed Feb 9 10:02:28 2011 Return-Path: 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 79EAF3A67D7 for ; Wed, 9 Feb 2011 10:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LxZW0LUIOjfM for ; Wed, 9 Feb 2011 10:02:27 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 858B23A67BD for ; Wed, 9 Feb 2011 10:02:27 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p19I1rw6014735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 12:01:55 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p19I1q2P011393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 23:31:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 9 Feb 2011 23:31:52 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Wed, 9 Feb 2011 23:31:50 +0530 Thread-Topic: [pim] PORT and keep-alives Thread-Index: AcvIgrTUC0u45BRoRhS3Xcwp3x9xGwAAClKw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F84@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D26A.5070402@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F80@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D54E.3010707@venaas.com> In-Reply-To: <4D52D54E.3010707@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:02:28 -0000 >=20 > I think the typical "3 times" rule is due to possible packet loss. Is > it still reasonable with a reliable transport? >=20 Most TCP based applications still use 3x factor because it would also indic= ate if the application/process is in a sane condition (not deadlocked, CPU = too busy to give this application any CPU cycles, etc) and is able to respo= nd to your KA packets. The router may be too busy to respond to your keepal= ives and you would not want to bring down your session based on one delayed= packet. If you however find that its not responding to the last three keep= alives that you have sent then its probably a good idea to bring down the s= ession. Cheers, Manav= From stig@venaas.com Wed Feb 9 10:05:52 2011 Return-Path: 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 82E8A3A67BD for ; Wed, 9 Feb 2011 10:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 PACZfkw+42KS for ; Wed, 9 Feb 2011 10:05:51 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 6655A3A67A4 for ; Wed, 9 Feb 2011 10:05:51 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 52A96800A; Wed, 9 Feb 2011 19:06:00 +0100 (CET) Message-ID: <4D52D786.1060303@venaas.com> Date: Wed, 09 Feb 2011 10:05:58 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D503A5B.9070706@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFC@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFC@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" Subject: Re: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:05:52 -0000 On 2/8/2011 3:32 PM, Bhatia, Manav (Manav) wrote: > Hi Stig, > >>> I don't think I understand the reason why an operator would >> want to transition to the datagram mode when two routers are >> advertising the PORT capability in their PIM Hellos. If they >> want to revert to the datagram mode then it should be >> configured though the CLI and routers should stop advertising >> this capability in their Hellos. >> >> Yes, I agree with you on this point. This is also what the >> draft says. > > In that case we must remove the following line from Sec 3.1: > > When the router cannot setup a TCP connection, it will refrain from including this option. Agree. > I don't think implementations should automatically revert to the datagram mode. The above statement actually causes more problems than without being there. Since there is no guidance on when implementations should refrain from including this option we can easily get into interoperability problems where A and B are trying to establish a TCP connection but are unable to do so. A, based on the above text decides to send PIM Hellos with the PORT capability, while B still continues to send Hellos including this capability. B may never stop doing this since the RFC says that PORT capable routers MUST always send this capability. > > This brings another aspect that I don't think is covered in the current text. > > What should A do if it is PORT capable and it receives Hello messages without this capability. Should it downgrade and not include this capability in the subsequent Hellos? I think we should include some text discussing this as well. I think this is covered by the current text. It says: Once PORT is enabled on an interface and a PIM neighbor also announces that it is PORT enabled, only PORT Join/Prune messages will be used. That is, only PORT Join/Prune messages are accepted from, and sent to, that particular neighbor. Native Join/Prune messages may still be used for other neighbors. Which means as soon as one neighbor stops being PORT enabled, you revert to native. Perhaps it could be made clearer. Perhaps it helps changing the last sentence to say that "Native Join/Prune messages are still used for PIM neighbors that are not PORT enabled". In the introduction it says: Two routers that are PIM neighbors on a link will always use Transport mode if and only if both have Transport mode enabled. Note that in the latest version I am changing the terms a bit as Transport mode is not defined. Stig > Cheers, Manav From stig@venaas.com Wed Feb 9 10:08:16 2011 Return-Path: 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 CCE3D3A67A4 for ; Wed, 9 Feb 2011 10:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 KgvXWPzhTuVX for ; Wed, 9 Feb 2011 10:08:16 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 02C203A6768 for ; Wed, 9 Feb 2011 10:08:16 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8430A800A; Wed, 9 Feb 2011 19:08:24 +0100 (CET) Message-ID: <4D52D816.70303@venaas.com> Date: Wed, 09 Feb 2011 10:08:22 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D26A.5070402@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F80@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D54E.3010707@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F84@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F84@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:08:16 -0000 On 2/9/2011 10:01 AM, Bhatia, Manav (Manav) wrote: >> >> I think the typical "3 times" rule is due to possible packet loss. Is >> it still reasonable with a reliable transport? >> > > Most TCP based applications still use 3x factor because it would also indicate if the application/process is in a sane condition (not deadlocked, CPU too busy to give this application any CPU cycles, etc) and is able to respond to your KA packets. The router may be too busy to respond to your keepalives and you would not want to bring down your session based on one delayed packet. If you however find that its not responding to the last three keepalives that you have sent then its probably a good idea to bring down the session. Yes, you may be right. Note that it would not be about reacting to the keep-alives, but rather that it is too busy to send you keep-alives. Stig > Cheers, Manav From manav.bhatia@alcatel-lucent.com Wed Feb 9 10:08:39 2011 Return-Path: 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 0DF263A67EC for ; Wed, 9 Feb 2011 10:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 j0vx5e9sAdhN for ; Wed, 9 Feb 2011 10:08:38 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 44F683A6768 for ; Wed, 9 Feb 2011 10:08:38 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p19I8jqI016505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 12:08:47 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p19I8f7q004833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 23:38:43 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 9 Feb 2011 23:38:41 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Wed, 9 Feb 2011 23:38:39 +0530 Thread-Topic: [pim] PORT and Datagram PIM Thread-Index: AcvIhAT6+21YkERdRea2k/7VtE7xKQAAEnrw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F87@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D503A5B.9070706@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFC@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D786.1060303@venaas.com> In-Reply-To: <4D52D786.1060303@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "pim@ietf.org" Subject: Re: [pim] PORT and Datagram PIM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:08:39 -0000 =20 > Which means as soon as one neighbor stops being PORT enabled, you > revert to native. Perhaps it could be made clearer. Perhaps it > helps changing the last sentence to say that "Native Join/Prune > messages are still used for PIM neighbors that are not PORT > enabled". Yup, this sounds much better. Manav= From manav.bhatia@alcatel-lucent.com Wed Feb 9 10:11:46 2011 Return-Path: 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 4A3ED3A6866 for ; Wed, 9 Feb 2011 10:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jOZ4NVe6seV4 for ; Wed, 9 Feb 2011 10:11:44 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 910C63A6768 for ; Wed, 9 Feb 2011 10:11:44 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p19IBo5V000308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 12:11:52 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p19IBnof011674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 23:41:49 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 9 Feb 2011 23:41:49 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Wed, 9 Feb 2011 23:41:46 +0530 Thread-Topic: [pim] PORT and keep-alives Thread-Index: AcvIhF8JQFALq1dcR9yPrJW+zBJviAAABtGg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F88@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D0913E1.1080603@venaas.com> <4D0A5DAB.1010204@venaas.com> <4D0BF567.6030206@venaas.com> <4D485EA7.2010203@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED44444@BLRKECMBX02.ad.infosys.com> <4D503E4A.10803@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EE0A@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D519824.1050506@venaas.com> <20110208195236.GU22898@cisco.com> <4D51A439.5030606@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D51C74C.2060805@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6CEB@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D26A.5070402@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F80@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D54E.3010707@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F84@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D816.70303@venaas.com> In-Reply-To: <4D52D816.70303@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: Toerless Eckert , "pim@ietf.org" Subject: Re: [pim] PORT and keep-alives X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:11:46 -0000 =20 > Yes, you may be right. Note that it would not be about reacting to the > keep-alives, but rather that it is too busy to send you keep-alives. Yes, which is why I said CPU too busy to give this application any CPU cycl= es. If this application is not getting any CPU cycles it cannot respond to = your keep-alives. Another scenario when CPU may be giving it cycles and yet= it doesn't respond to keep-alives is when its (i) either blocked on some r= esource OR (ii) is deadlocked with some other task. So, we need to define a HoldTime which is 3x Keep-Alive. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Wed Feb 9 10:23:07 2011 Return-Path: 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 2E85A3A6768 for ; Wed, 9 Feb 2011 10:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WqOEVO7vRR+o for ; Wed, 9 Feb 2011 10:23:06 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 43B7D3A67F7 for ; Wed, 9 Feb 2011 10:23:06 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p19INDva011576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 12:23:15 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p19INCgb005186 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Feb 2011 23:53:12 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 9 Feb 2011 23:53:12 +0530 From: "Bhatia, Manav (Manav)" To: Stig Venaas Date: Wed, 9 Feb 2011 23:53:10 +0530 Thread-Topic: [pim] TCP Connection ID Thread-Index: AcvIgjgG+wwp6Cu+QGSzaM4Xg2n4dAAAHjPg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F95@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D47A.8040309@venaas.com> In-Reply-To: <4D52D47A.8040309@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:23:07 -0000 > > > > I think it should be the latter, however this needs to be=20 > discussed and addressed in the spec. >=20 > I remember planning to add text on this. I think the connection should > be taken down and re-established. If an administrator makes=20 > the decision > that connections should be terminated at a new IP address,=20 > then I would Ok, then the router that changes the Connection ID MUST gracefully terminat= e the PORT session by closing the TCP socket. The onus should lie on the si= de that's changing the Connection ID, rather than the side that's receiving= the PIM HELLO. Can you also add this to the draft? Lets see how this helps (i.e. the sending side initiating the termination v= is-=E0-vis the receiving side doing this). If it's the receiving side that = decides to terminate the session based on a new Connection ID then we're ma= king PORT vulnerable to attacks where a single malicious HELLO packet will = bring down the PORT session? Also note that while we are currently using a = link local mcast address for the HELLOs, we might in future use some other,= and possibly a unicast address (for discovering routers multiple hops away= ). In that case spoofing HELLOs would become much simpler, and thus easier = to attack PORT. I would thus suggest that if we want to re-establish a PORT session then th= e sending side should initiate this. This means that the receiving side wil= l not do anything if it sees that the connection ID has changed. Cheers, Manav= From stig@venaas.com Wed Feb 9 10:41:32 2011 Return-Path: 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 769C73A67A4 for ; Wed, 9 Feb 2011 10:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 5YG9ICMRy-NZ for ; Wed, 9 Feb 2011 10:41:31 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 714A73A672F for ; Wed, 9 Feb 2011 10:41:31 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6FE11800A; Wed, 9 Feb 2011 19:41:40 +0100 (CET) Message-ID: <4D52DFE2.6060207@venaas.com> Date: Wed, 09 Feb 2011 10:41:38 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D52D47A.8040309@venaas.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6F95@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6F95@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:41:32 -0000 On 2/9/2011 10:23 AM, Bhatia, Manav (Manav) wrote: >>> >>> I think it should be the latter, however this needs to be >> discussed and addressed in the spec. >> >> I remember planning to add text on this. I think the connection should >> be taken down and re-established. If an administrator makes >> the decision >> that connections should be terminated at a new IP address, >> then I would > > Ok, then the router that changes the Connection ID MUST gracefully terminate the PORT session by closing the TCP socket. The onus should lie on the side that's changing the Connection ID, rather than the side that's receiving the PIM HELLO. Can you also add this to the draft? I think both of them should terminate it. The only bad thing I see with doing it on the sending side is if a Hello is getting lost. The other side may then try to reconnect to the old address. Another issue I can think of is if somehow one router cannot send packets from the previous IP address. Then it cannot do a graceful termination. > Lets see how this helps (i.e. the sending side initiating the termination vis-à-vis the receiving side doing this). If it's the receiving side that decides to terminate the session based on a new Connection ID then we're making PORT vulnerable to attacks where a single malicious HELLO packet will bring down the PORT session? Also note that while we are currently using a link local mcast address for the HELLOs, we might in future use some other, and possibly a unicast address (for discovering routers multiple hops away). In that case spoofing HELLOs would become much simpler, and thus easier to attack PORT. I agree that may be a concern. But if you can spoof a Hello, you can also send one without the PORT Option, forcing the connection to go down. If you can send malicious PIM packets you can do a lot of bad things. > I would thus suggest that if we want to re-establish a PORT session then the sending side should initiate this. This means that the receiving side will not do anything if it sees that the connection ID has changed. I think it should be back to the usual rules. It is based on who has the highest ConnectionID. Once the connection is down, the state could be the same as if it never was up. Stig > Cheers, Manav From stig@venaas.com Wed Feb 9 13:00:01 2011 Return-Path: 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 0E9EE3A68D8 for ; Wed, 9 Feb 2011 13:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 8jXXAAuoMAkH for ; Wed, 9 Feb 2011 13:00:00 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id DA2DC3A6842 for ; Wed, 9 Feb 2011 12:59:59 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 49085800F; Wed, 9 Feb 2011 22:00:07 +0100 (CET) Message-ID: <4D530053.10100@venaas.com> Date: Wed, 09 Feb 2011 13:00:03 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F6E88@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F6E88@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , Yiqun Cai , Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:00:01 -0000 On 2/9/2011 1:41 AM, Bhatia, Manav (Manav) wrote: > >> >> Currently there are no non-directly connected neighbors, right? I >> could be wrong... So it seems a bit odd to prepare for these in the >> spec at this point. > > When I started reading this draft I too was under the impression that PORT is only for directly connected neighbors as its discovered through PIM HELLOs which go out with TTL=1. However, I am beginning to think that we could use it for non directly connected neighbors as well. Here is the scenario that I have in mind: > > A -- -- B > > A and B establish a PORT session. This could either be a trigger for creating an LSP between them or we could have an already existing LSP for the data traffic (beyond the scope of this discussion). B sends PORT JOINs to A (which has to go via multiple hops) which results in A sending multicast traffic destined for groups specified in those Joins over the LSP that has been established (or was pre-established). In this case the intermediate routers need not be aware of the Joins as they don't switch the multicast traffic and only route it based on the outer MPLS labels. Yes, I have been thinking of some such things too. Nothing too specific at the moment, but I see some potential uses like this for PORT. And you don't necessarily need Hello's to initiate a PORT connection. Stig > Specifying GTSM behavior in such cases may be a trifle difficult as we may not know the exact hops between A and B. > >> Obviously, non-directly connected neighbors need to disable TTL >> checking, but logically this should happen when this kind of >> behaviour >> is specified, right? > > I think we should not preclude the possibility of the above happening, in which case we might have to be a little lenient in the receiver behavior. > >> >> But if non-directly connected neighbors are already in the spec, I >> agree that the TTL checking at receipt text should address both >> scenarios. > > I don't think the current draft is explicit on this. However, if the above scenario is possible (and it certainly is) then we must address that in the current draft. It would also be good if we could extend the PIM PORT discovery to work with neighbors that are multiple hops away. > > Cheers, Manav > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From bharat_joshi@infosys.com Wed Feb 9 19:26:34 2011 Return-Path: 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 3CDD83A6844 for ; Wed, 9 Feb 2011 19:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 V0EdVllkBrUa for ; Wed, 9 Feb 2011 19:26:33 -0800 (PST) Received: from KECGATE03.infosys.com (Kecgate03.infosys.com [122.98.10.31]) by core3.amsl.com (Postfix) with ESMTP id 522FB3A680C for ; Wed, 9 Feb 2011 19:26:32 -0800 (PST) X-TM-IMSS-Message-ID: <22cabed40004055d@infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 22cabed40004055d ; Thu, 10 Feb 2011 08:51:23 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.26]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Thu, 10 Feb 2011 08:56:38 +0530 From: Bharat Joshi To: Stig Venaas , "Bhatia, Manav (Manav)" Date: Thu, 10 Feb 2011 08:54:47 +0530 Thread-Topic: [pim] TCP Connection ID Thread-Index: AcvIgjh2jd/hpufUTne4i9eAjDKS+QAT9jPj Message-ID: <31D55C4D55BEED48A4459EB64567589A108ED4444A@BLRKECMBX02.ad.infosys.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com>, <4D52D47A.8040309@venaas.com> In-Reply-To: <4D52D47A.8040309@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 03:26:34 -0000 Stig, >=20>=20Assume=20A=20and=20B=20have=20a=20PORT=20session=20established.= =20Now=20A=20receives=20a=20PIM=20Hello=20message=20from=20B=20with=20a= =20different=20Connection=20ID.=20What=20should=20it=20do?=20Should=20it= =20kill=20the=20existing=20TCP=20session=20and=20establish=20a=20new=20on= e=20or=20should=20it=20ignore=20this=20change=20as=20long=20as=20the=20PO= RT=20session=20is=20up=20(i.e.=20PORT=20keepalives=20continue=20being=20e= xchanged). >=20> >=20>=20I=20think=20it=20should=20be=20the=20latter,=20however=20this=20n= eeds=20to=20be=20discussed=20and=20addressed=20in=20the=20spec. >=20 >=20I=20remember=20planning=20to=20add=20text=20on=20this.=20I=20think=20= the=20connection=20should >=20be=20taken=20down=20and=20re-established.=20If=20an=20administrator= =20makes=20the=20decision >=20that=20connections=20should=20be=20terminated=20at=20a=20new=20IP=20a= ddress,=20then=20I=20would >=20say=20that=20should=20effect=20all=20connections.=20There=20may=20be= =20reasons=20why=20do=20not >=20want=20the=20old=20IP=20address=20to=20be=20used=20anymore.=20If=20th= e=20old=20address=20becomes >=20unavailable,=20then=20the=20connection=20would=20later=20fail,=20but= =20I=20think=20it's >=20better=20to=20switch=20immediately.=20Even=20if=20the=20old=20IP=20ad= dress=20remains=20valid >=20and=20the=20TCP=20connections=20can=20stay=20up,=20there=20may=20be= =20reasons=20why=20one=20wants >=20to=20change=20addresses. If=20we=20tear=20down=20a=20connection=20because=20of=20hold-time,=20what= =20will=20happen=20to=20the=20J/P=20learned=20from=20a=20given=20connecti= on? Thanks, Bharat =20 >=20One=20example=20might=20be=20that=20you=20install=20a=20second=20link= =20between=20two=20PIM >=20routers=20and=20you=20decide=20that=20you=20want=20to=20do=20connecti= on=20sharing.=20You >=20might=20start=20out=20using=20just=20link-local=20addresses=20(a=20li= kely=20default >=20for=20IPv6),=20but=20would=20then=20need=20to=20change=20to=20global= =20addresses. >=20 >=20Stig >=20 >=20>=20Cheers,=20Manav >=20> >=20>=20-- >=20>=20Manav=20Bhatia, >=20>=20IP=20Division,=20Alcatel-Lucent, >=20>=20Bangalore=20-=20India >=20> >=20> >=20>=20_______________________________________________ >=20>=20pim=20mailing=20list >=20>=20pim@ietf.org >=20>=20https://www.ietf.org/mailman/listinfo/pim >=20 ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From manav.bhatia@alcatel-lucent.com Wed Feb 9 20:12:32 2011 Return-Path: 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 A28583A6850 for ; Wed, 9 Feb 2011 20:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uQv878akgrzp for ; Wed, 9 Feb 2011 20:12:32 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E16C03A6844 for ; Wed, 9 Feb 2011 20:12:31 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1A4Cb3E018830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 22:12:39 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1A4CZCl009890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Feb 2011 09:42:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 10 Feb 2011 09:42:35 +0530 From: "Bhatia, Manav (Manav)" To: Bharat Joshi , Stig Venaas Date: Thu, 10 Feb 2011 09:42:33 +0530 Thread-Topic: [pim] TCP Connection ID Thread-Index: AcvIgjh2jd/hpufUTne4i9eAjDKS+QAT9jPjAAGn3TA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F7001@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com>, <4D52D47A.8040309@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED4444A@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A108ED4444A@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 04:12:32 -0000 Bharat, > If we tear down a connection because of hold-time, what will=20 > happen to the J/P learned from a given connection? You clear that state in the HW. Cheers, Manav= From bharat_joshi@infosys.com Wed Feb 9 20:15:46 2011 Return-Path: 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 357793A6886 for ; Wed, 9 Feb 2011 20:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 blJReXlzMpz7 for ; Wed, 9 Feb 2011 20:15:45 -0800 (PST) Received: from KECGATE03.infosys.com (Kecgate03.infosysconsulting.com [122.98.10.31]) by core3.amsl.com (Postfix) with ESMTP id C034D3A687E for ; Wed, 9 Feb 2011 20:15:44 -0800 (PST) X-TM-IMSS-Message-ID: <22f7d82e0004107b@infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 22f7d82e0004107b ; Thu, 10 Feb 2011 09:40:39 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.26]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Thu, 10 Feb 2011 09:45:53 +0530 From: Bharat Joshi To: "Bhatia, Manav (Manav)" , Stig Venaas Date: Thu, 10 Feb 2011 09:43:40 +0530 Thread-Topic: [pim] TCP Connection ID Thread-Index: AcvIgjh2jd/hpufUTne4i9eAjDKS+QAT9jPjAAGn3TAAAA05Aw== Message-ID: <31D55C4D55BEED48A4459EB64567589A108ED4444B@BLRKECMBX02.ad.infosys.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com>, <4D52D47A.8040309@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED4444A@BLRKECMBX02.ad.infosys.com>, <7C362EEF9C7896468B36C9B79200D8350CFB2F7001@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F7001@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 04:15:46 -0000 Manav, >>=20If=20we=20tear=20down=20a=20connection=20because=20of=20hold-time,= =20what=20will >>=20happen=20to=20the=20J/P=20learned=20from=20a=20given=20connection? > >=20You=20clear=20that=20state=20in=20the=20HW. > I=20agree=20that=20this=20will=20be=20logical=20to=20clear=20the=20state. But=20sometime=20back,=20we=20were=20discussing=20that=20we=20can=20start= =20a=20timer=20for=20each=20J/P=20and=20can=20let=20them=20time-out=20if= =20no=20update=20comes=20either=20through=20native=20J/P=20or=20the=20con= nection=20gets=20re-established.=20Though=20I=20understand=20there=20are= =20issues=20in=20doing=20that=20also. Thanks, Bharat ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From manav.bhatia@alcatel-lucent.com Wed Feb 9 20:32:37 2011 Return-Path: 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 AA9653A6856 for ; Wed, 9 Feb 2011 20:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 l1058QX0BT2o for ; Wed, 9 Feb 2011 20:32:36 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 59D963A67F7 for ; Wed, 9 Feb 2011 20:32:34 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p1A4WeZ7016112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 22:32:44 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1A4WdZP012161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Feb 2011 10:02:39 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 10 Feb 2011 10:02:39 +0530 From: "Bhatia, Manav (Manav)" To: Bharat Joshi , Stig Venaas Date: Thu, 10 Feb 2011 10:02:40 +0530 Thread-Topic: [pim] TCP Connection ID Thread-Index: AcvIgjh2jd/hpufUTne4i9eAjDKS+QAT9jPjAAGn3TAAAA05AwAAiLRg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F7010@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com>, <4D52D47A.8040309@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED4444A@BLRKECMBX02.ad.infosys.com>, <7C362EEF9C7896468B36C9B79200D8350CFB2F7001@INBANSXCHMBSA1.in.alcatel-lucent.com> <31D55C4D55BEED48A4459EB64567589A108ED4444B@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A108ED4444B@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "pim@ietf.org" Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 04:32:38 -0000 Hi Bharat, =20 > I agree that this will be logical to clear the state. >=20 > But sometime back, we were discussing that we can start a=20 > timer for each J/P and can let them time-out if no update=20 > comes either through native J/P or the connection gets=20 > re-established. Though I understand there are issues in doing=20 > that also. The idea behind doing that was to provide a hitless support for PORT, where= we don't remove all the HW state if there is (i) a switchover to the redun= dant OR (ii) PORT crashes and comes back up before the J/P timers expire an= d it was able to preserve the state. This should still be done, as long as PORT comes back up within the Hold Ti= me. If it takes more than that, then the PORT neighbor is considered to be = DEAD. A lot of routing protocols use this technique to provide a graceful restart= option where the restarted router MUST come back up before the Holdtimer o= n the other end expires. We need to do the same for PORT. Cheers, Manav =20 From pekkas@netcore.fi Wed Feb 9 23:31:02 2011 Return-Path: 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 B75F13A68D9 for ; Wed, 9 Feb 2011 23:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UP5FIHAb2W02 for ; Wed, 9 Feb 2011 23:31:01 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 68F8D3A68D5 for ; Wed, 9 Feb 2011 23:31:01 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1A7UthQ011083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 09:30:55 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1A7Ur0n011079; Thu, 10 Feb 2011 09:30:53 +0200 Date: Thu, 10 Feb 2011 09:30:53 +0200 (EET) From: Pekka Savola To: Stig Venaas In-Reply-To: <4D52D0D9.7070705@venaas.com> Message-ID: References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <4D52D0D9.7070705@venaas.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Toerless Eckert , Yiqun Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:31:02 -0000 On Wed, 9 Feb 2011, Stig Venaas wrote: > My main concern is that you may have a topology like this: > > A --- B > \ / > C > where A and B are neighbors, and using say loopback addresses > for ConnectionIDs so that the TCP connection between A and B > end-point addresses are those loopbacks. ... > 2. If the link between A and B goes down, the TCP connection > would still be up. Let's say there is just a brief flap > of the link, it is then better to keep the connection up, > than to tear it down, create a new one, and have to do a > full update. Also, if the link stays down for some time, > keeping the connection allow prunes to be sent and remove > state. Good that we agree with MUST TTL=255 when sending. Your point 2 is convincing to me operationally when PIM is run internally in a domain. The big question here, however, is how ConnectionIDs are chosen. In internal domains (compare to iBGP), GTSM is not strictly necessary and could cause issues like you describe upon rerouting if loopback ConnectionIDs are used. Further, simple security can already be implemented by having ACLs at border devices. I'd strongly argue in favor of using interface addresses for external PIM sessions (compare to eBGP), because there ACLs won't help (that much) to protect from spoofing the neighbor. In these kinds of setups using non-loopback ConnectionIDs is usually a good idea. Even if loopback ConnectionIDs are used (e.g. for L3 loadbalancing two links between two routers), the TTL is still 255. So, the question becomes whether the scenario where PORT is used can be identified and how ConnectionIDs are chosen. Is this done automatically? Are we going to expect something similar to i/eBGP configuration. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jeff.tantsura@ericsson.com Thu Feb 10 09:34:57 2011 Return-Path: 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 314FC3A69DA for ; Thu, 10 Feb 2011 09:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1k+4OgNXCl+m for ; Thu, 10 Feb 2011 09:34:56 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 361313A69D9 for ; Thu, 10 Feb 2011 09:34:55 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1AIJCxL031953; Thu, 10 Feb 2011 12:19:14 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 10 Feb 2011 12:34:57 -0500 From: Jeff Tantsura To: Pekka Savola Date: Thu, 10 Feb 2011 12:34:53 -0500 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvJSNX2o70eafghQj627a2eUqTFmw== Message-ID: References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <4D52D0D9.7070705@venaas.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Toerless Eckert , Yiqun, Cai , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:34:57 -0000 Hi, Pekka - would you prefer per peer (configurable) connectionID rather than "= router pim" global one? Regards, Jeff On Feb 9, 2011, at 23:31, "Pekka Savola" wrote: > On Wed, 9 Feb 2011, Stig Venaas wrote: >> My main concern is that you may have a topology like this: >>=20 >> A --- B >> \ / >> C >> where A and B are neighbors, and using say loopback addresses >> for ConnectionIDs so that the TCP connection between A and B >> end-point addresses are those loopbacks. > ... >> 2. If the link between A and B goes down, the TCP connection >> would still be up. Let's say there is just a brief flap >> of the link, it is then better to keep the connection up, >> than to tear it down, create a new one, and have to do a >> full update. Also, if the link stays down for some time, >> keeping the connection allow prunes to be sent and remove >> state. >=20 > Good that we agree with MUST TTL=3D255 when sending. >=20 > Your point 2 is convincing to me operationally when PIM is run=20 > internally in a domain. >=20 > The big question here, however, is how ConnectionIDs are chosen. >=20 > In internal domains (compare to iBGP), GTSM is not strictly necessary=20 > and could cause issues like you describe upon rerouting if loopback=20 > ConnectionIDs are used. Further, simple security can already be=20 > implemented by having ACLs at border devices. >=20 > I'd strongly argue in favor of using interface addresses for external=20 > PIM sessions (compare to eBGP), because there ACLs won't help (that=20 > much) to protect from spoofing the neighbor. In these kinds of setups=20 > using non-loopback ConnectionIDs is usually a good idea. Even if=20 > loopback ConnectionIDs are used (e.g. for L3 loadbalancing two links=20 > between two routers), the TTL is still 255. >=20 > So, the question becomes whether the scenario where PORT is used can=20 > be identified and how ConnectionIDs are chosen. Is this done=20 > automatically? Are we going to expect something similar to i/eBGP=20 > configuration. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From pekkas@netcore.fi Thu Feb 10 09:50:18 2011 Return-Path: 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 15AA83A69DA for ; Thu, 10 Feb 2011 09:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AJbXNYRDWAjo for ; Thu, 10 Feb 2011 09:50:16 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3FD8C3A6A50 for ; Thu, 10 Feb 2011 09:50:06 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p1AHnoKb025915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 19:49:50 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p1AHno36025911; Thu, 10 Feb 2011 19:49:50 +0200 Date: Thu, 10 Feb 2011 19:49:50 +0200 (EET) From: Pekka Savola To: Jeff Tantsura In-Reply-To: Message-ID: References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <4D52D0D9.7070705@venaas.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi X-Virus-Status: Clean Cc: Toerless Eckert , Cai , Yiqun@core3.amsl.com, "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:50:18 -0000 On Thu, 10 Feb 2011, Jeff Tantsura wrote: > Pekka - would you prefer per peer (configurable) connectionID rather than "router pim" global one? Yes, I'd think that would likely make sense when interfacing external PIM domains. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From stig@venaas.com Thu Feb 10 10:19:40 2011 Return-Path: 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 6F6833A67EE for ; Thu, 10 Feb 2011 10:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 uIN944DvGEmc for ; Thu, 10 Feb 2011 10:19:39 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 1E13B3A659A for ; Thu, 10 Feb 2011 10:19:39 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:8560:7a13:4656:69ee] (unknown [IPv6:2001:420:4:ea0c:8560:7a13:4656:69ee]) by ufisa.uninett.no (Postfix) with ESMTPSA id 59345802B; Thu, 10 Feb 2011 19:19:50 +0100 (CET) Message-ID: <4D542C3E.2090604@venaas.com> Date: Thu, 10 Feb 2011 10:19:42 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CFB2F6CFF@INBANSXCHMBSA1.in.alcatel-lucent.com>, <4D52D47A.8040309@venaas.com> <31D55C4D55BEED48A4459EB64567589A108ED4444A@BLRKECMBX02.ad.infosys.com>, <7C362EEF9C7896468B36C9B79200D8350CFB2F7001@INBANSXCHMBSA1.in.alcatel-lucent.com> <31D55C4D55BEED48A4459EB64567589A108ED4444B@BLRKECMBX02.ad.infosys.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F7010@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F7010@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" , Bharat Joshi Subject: Re: [pim] TCP Connection ID X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:19:40 -0000 On 2/9/2011 8:32 PM, Bhatia, Manav (Manav) wrote: > Hi Bharat, > >> I agree that this will be logical to clear the state. >> >> But sometime back, we were discussing that we can start a >> timer for each J/P and can let them time-out if no update >> comes either through native J/P or the connection gets >> re-established. Though I understand there are issues in doing >> that also. > > The idea behind doing that was to provide a hitless support for PORT, where we don't remove all the HW state if there is (i) a switchover to the redundant OR (ii) PORT crashes and comes back up before the J/P timers expire and it was able to preserve the state. > > This should still be done, as long as PORT comes back up within the Hold Time. If it takes more than that, then the PORT neighbor is considered to be DEAD. > > A lot of routing protocols use this technique to provide a graceful restart option where the restarted router MUST come back up before the Holdtimer on the other end expires. We need to do the same for PORT. What the draft says now is: When a Transport connection goes down, Join/Prune state that was sent over the Transport connection is still retained. The neighbor should not be considered down until the neighbor timer has expired. This allows routers to do a control-plane switchover without disrupting the network. If a Transport connection is reestablished before the neighbor timer expires, the previous state is intact and any new Join/Prune messages sent cause state to be created or removed (depending on if it was a Join or Prune). If the neighbor timer does expire, only the upstream router, that has oif-list state, to the expired downstream neighbor will need to clear state. So when the connection goes down (note that the rule is different if PORT is unconfigured so that we are reverting to datagram mode), the state is retained as long as the neighbor is alive. I think it makes sense to not immediately remove state. The question I have though is whether we should eventually remove the state even if the neighbor is alive. We may not want state to stay there permanently if somehow the PIM Hello's make it through but no working TCP connection can be established. When switching to datagram mode the draft says: There may be situations where an administrator decides to stop using PORT. If PORT is disabled on a router interface, we start expiry timers with the respective neighbor holdtimes as the initial values. Similarly if we receive a Hello message without a PORT Capable option from a neighbor, we start expiry timers for all Join/Prune state we have for that particular neighbor. I think we should do this in all cases when a PORT connection goes down. Stig > Cheers, Manav > From stig@venaas.com Thu Feb 10 10:33:24 2011 Return-Path: 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 BB1443A6A55 for ; Thu, 10 Feb 2011 10:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 AioJQvee10Ia for ; Thu, 10 Feb 2011 10:33:24 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id BDFDE3A6A25 for ; Thu, 10 Feb 2011 10:33:23 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:8560:7a13:4656:69ee] (unknown [IPv6:2001:420:4:ea0c:8560:7a13:4656:69ee]) by ufisa.uninett.no (Postfix) with ESMTPSA id 67AF3802D; Thu, 10 Feb 2011 19:33:35 +0100 (CET) Message-ID: <4D542F7C.5020009@venaas.com> Date: Thu, 10 Feb 2011 10:33:32 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Pekka Savola References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <4D52D0D9.7070705@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:33:24 -0000 On 2/10/2011 9:49 AM, Pekka Savola wrote: > On Thu, 10 Feb 2011, Jeff Tantsura wrote: >> Pekka - would you prefer per peer (configurable) connectionID rather >> than "router pim" global one? > > Yes, I'd think that would likely make sense when interfacing external > PIM domains. > The way I think it should be implemented is basically that you on a router interface may configure something like: ip pim sparse-mode ip pim port That would enable PORT on the interface and use the primary IP address (the one used as source for PIM Hello's, link-local for IPv6) as the Connection-ID. This is the address announced as the ConnectionID in Hellos sent on this interface. With this default you won't do connection sharing. However, you might configure something like ip pim sparse-mode ip pim port connection-id Loopback0 Which means that in the PIM Hellos on this interface we will now use the IP address of Loopback0 as the ConnnectionID. You would then probably want to do something similar on the neighbor. If the two routers have two neighborships, then you could configure the same on both interfaces on both routers to get connection sharing. All this would be per interface. As you say, you might want to use your loopback on internal interfaces, but just use the primary interface address for an external connection. You could perhaps try to come up with heuristics for when to apply GTSM, but I would prefer it to be off by default, and that you have to configure say: ip pim port ttl-limit 253 or ip pim port max-hops 2 on the interface. Maybe something slightly simpler for the common case of 255 (0 hops). Anyway, these are just examples and as long as we have interoperability, we should allow implementations flexibility for how to do this. We agree that it at least SHOULD be possible to use GTSM. My only concern is to do the receiver check by default. Stig From jeff.tantsura@ericsson.com Thu Feb 10 11:25:47 2011 Return-Path: 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 176853A6997 for ; Thu, 10 Feb 2011 11:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 74Co1XioXrfL for ; Thu, 10 Feb 2011 11:25:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 15CFE3A686A for ; Thu, 10 Feb 2011 11:25:45 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1AKA9Lr020450; Thu, 10 Feb 2011 14:10:10 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 10 Feb 2011 14:25:54 -0500 From: Jeff Tantsura To: Stig Venaas Date: Thu, 10 Feb 2011 14:25:49 -0500 Thread-Topic: [pim] TTL for PORT Thread-Index: AcvJWFTojpXV0kTUTV+UYA1L7AxGpg== Message-ID: <415A6E02-A43D-457B-B213-C92DA5FC159F@ericsson.com> References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <4D52D0D9.7070705@venaas.com> <4D542F7C.5020009@venaas.com> In-Reply-To: <4D542F7C.5020009@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:25:47 -0000 IMHO it should be a bit different: most implementations out there configure pim in a separate "router pim" sta= nza and then have interfaces within + pim is mostly used within an AS wit= h a common IGP. I'd propose to have pim global connectionID similar to router-id configurat= ion for IGPs and use it as default connectionID which could then be overwri= tten under interface Regards, Jeff On Feb 10, 2011, at 10:33, "Stig Venaas" wrote: > On 2/10/2011 9:49 AM, Pekka Savola wrote: >> On Thu, 10 Feb 2011, Jeff Tantsura wrote: >>> Pekka - would you prefer per peer (configurable) connectionID rather >>> than "router pim" global one? >>=20 >> Yes, I'd think that would likely make sense when interfacing external >> PIM domains. >>=20 >=20 > The way I think it should be implemented is basically that you on > a router interface may configure something like: >=20 > ip pim sparse-mode > ip pim port >=20 > That would enable PORT on the interface and use the primary > IP address (the one used as source for PIM Hello's, link-local > for IPv6) as the Connection-ID. This is the address announced > as the ConnectionID in Hellos sent on this interface. >=20 > With this default you won't do connection sharing. >=20 > However, you might configure something like >=20 > ip pim sparse-mode > ip pim port connection-id Loopback0 >=20 > Which means that in the PIM Hellos on this interface we > will now use the IP address of Loopback0 as the ConnnectionID. >=20 > You would then probably want to do something similar on the > neighbor. >=20 > If the two routers have two neighborships, then you could > configure the same on both interfaces on both routers to > get connection sharing. >=20 > All this would be per interface. As you say, you might > want to use your loopback on internal interfaces, but > just use the primary interface address for an external > connection. >=20 > You could perhaps try to come up with heuristics for > when to apply GTSM, but I would prefer it to be off by > default, and that you have to configure say: >=20 > ip pim port ttl-limit 253 > or > ip pim port max-hops 2 >=20 > on the interface. Maybe something slightly simpler > for the common case of 255 (0 hops). >=20 > Anyway, these are just examples and as long as we > have interoperability, we should allow implementations > flexibility for how to do this. We agree that it at > least SHOULD be possible to use GTSM. My only concern > is to do the receiver check by default. >=20 > Stig > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Thu Feb 10 11:29:56 2011 Return-Path: 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 CB0343A69E5 for ; Thu, 10 Feb 2011 11:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Ynz+iVm3UMcV for ; Thu, 10 Feb 2011 11:29:56 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id C2AD43A6A0B for ; Thu, 10 Feb 2011 11:29:55 -0800 (PST) Received: from [128.107.115.7] (unknown [128.107.115.7]) by ufisa.uninett.no (Postfix) with ESMTPSA id CF180802F; Thu, 10 Feb 2011 20:30:06 +0100 (CET) Message-ID: <4D543CBC.2050106@venaas.com> Date: Thu, 10 Feb 2011 11:30:04 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeff Tantsura References: <29539.1297197989@erosen-linux> <4D51B06E.4050302@venaas.com> <20110209083856.GC22898@cisco.com> <4D52D0D9.7070705@venaas.com> <4D542F7C.5020009@venaas.com> <415A6E02-A43D-457B-B213-C92DA5FC159F@ericsson.com> In-Reply-To: <415A6E02-A43D-457B-B213-C92DA5FC159F@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pekka Savola , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:29:57 -0000 On 2/10/2011 11:25 AM, Jeff Tantsura wrote: > IMHO it should be a bit different: > most implementations out there configure pim in a separate "router pim" stanza and then have interfaces within + pim is mostly used within an AS with a common IGP. > I'd propose to have pim global connectionID similar to router-id configuration for IGPs and use it as default connectionID which could then be overwritten under interface OK, that makes sense. Anyway, we don't want to specify this in any way IMO. Although I think we agree that interface specific config should be possible. Stig > Regards > Jeff From manav.bhatia@alcatel-lucent.com Thu Feb 10 16:36:26 2011 Return-Path: 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 791C73A6B18 for ; Thu, 10 Feb 2011 16:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.657 X-Spam-Level: X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9kumev-7lv+q for ; Thu, 10 Feb 2011 16:36:25 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6253E3A6B09 for ; Thu, 10 Feb 2011 16:36:25 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1B0aZ5v024938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Feb 2011 18:36:37 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1B0aY0O016988 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 11 Feb 2011 06:06:34 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 11 Feb 2011 06:06:34 +0530 From: "Bhatia, Manav (Manav)" To: "pim@ietf.org" Date: Fri, 11 Feb 2011 06:06:33 +0530 Thread-Topic: Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvJg7tBIubApCYHTRaLZqp0lWWgPA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F7263@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:36:26 -0000 Hi, I have written a small draft that describes how we could use MPLS tunnels f= or sending the multicast data traffic to the RP till the SPT is formed, ins= tead of encapsulating them in PIM Register packets. Abstract In PIM-SM the designated router (DR) closest to the source keeps sending PIM register packets till it receives an explicit Register- Stop message from the rendezvous point (RP) router. The process of encapsulating multicast data traffic to the RP, and the decapsulation done by RP are relatively expensive operations for a router to perform, depending upon whether or not the router has appropriate hardware support for these tasks. Since the PIM register messages are native IP packets and routed based on IP forwarding tables no resource reservation mechanisms are available. All IP packets will follow common paths that are defined by the traditional IGP's algorithm and customizing the path for multicast applications is impossible. This document proposes using MPLS tunnel(s) to send traffic from the source to the RP till the shortest path tree (SPT) from the RP to the source is established. Processing MPLS packets is easy and is readily supported on most platforms. The draft is available here: http://www.ietf.org/id/draft-bhatia-pim-mpls-register-packets-00.txt Would love to hear feedback and comments from the WG. Thanks, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From b4a1r6d4@gmail.com Fri Feb 11 00:15:13 2011 Return-Path: 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 531BB3A68BB for ; Fri, 11 Feb 2011 00:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 R8G9lSJiuMZA for ; Fri, 11 Feb 2011 00:15:12 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 692BA3A69D4 for ; Fri, 11 Feb 2011 00:15:12 -0800 (PST) Received: by qwi2 with SMTP id 2so1450597qwi.31 for ; Fri, 11 Feb 2011 00:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=I2iwykCtbn3yTm072gFO/ktmQbrY/oODXZaxlxnURHY=; b=o1NRFEfC9z12xvViS2KP8mW4wKCJrcbl21HRnB5iZw3HfW+a95/hdTThHqR5wpQQwn m2r1baPHEjpkLRUhqvuxpMeyf5tcpu/t7DsljiVWZkKOK1C9/uo8gS3DE+JMKtjpE9G+ kMjxBkBhWRLDvLp6VlAWmy+WIhF/113LWbJUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HvNG4F8qA1YRcFFv58TB1Beu+gyrmX5CJ7YNGd0lZVBydHjv55b97oGyh/oDSlDB93 ozDVNxuFLm+muUZ9XMhB9xfLB1Rcz3NN72zTkB0fHIIxNjomFsm6Km8wXO9MlxFWvBz0 cz0XDJdatY9IC5b+x98KU6sgSAPldrbBImj4A= MIME-Version: 1.0 Received: by 10.229.82.8 with SMTP id z8mr216674qck.108.1297412126362; Fri, 11 Feb 2011 00:15:26 -0800 (PST) Received: by 10.229.95.21 with HTTP; Fri, 11 Feb 2011 00:15:26 -0800 (PST) Date: Fri, 11 Feb 2011 13:45:26 +0530 Message-ID: From: David Bard To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pim] draft-zhou-pim-fhr-source-network-prohibition-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 08:16:07 -0000 Hi, This draft assumes that the source will always be running PIM which i believe is not correct. It could just be a video server streaming out huge quantities of video. Dave From erosen@cisco.com Fri Feb 11 09:25:37 2011 Return-Path: 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 C1E6F3A67D9 for ; Fri, 11 Feb 2011 09:25:37 -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 JIPElSanlFMc for ; Fri, 11 Feb 2011 09:25:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E0A2E3A67BD for ; Fri, 11 Feb 2011 09:25:36 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,456,1291593600"; d="scan'208";a="214576013" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2011 17:25:52 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1BHPpEI002995; Fri, 11 Feb 2011 17:25:52 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p1BHPptA004569; Fri, 11 Feb 2011 12:25:51 -0500 To: "Bhatia, Manav (Manav)" In-reply-to: Your message of Fri, 11 Feb 2011 06:06:33 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB2F7263@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 11 Feb 2011 12:25:51 -0500 Message-ID: <4568.1297445151@erosen-linux> From: Eric Rosen Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 17:25:37 -0000 The gist of the proposal seems to be: > This document proposes using MPLS tunnel(s) to send traffic from the > source to the RP till the shortest path tree (SPT) from the RP to the > source is established. > The DR close to the source MUST set up an MPLS RSVP-TE tunnel > [RFC3936] between itself and the RP > This draft introduces no changes in how the DR sends the Register > packets. The same rules apply as defined in[RFC4601]. The only > thing that changes is that the DR MUST send Register packets using > the tunnel, instead of the regular registration encapsulation that's > defined in [RFC4601]. But then how does the RP distinguish a Register packet for (S,G) from an "ordinary" (S,G) data packet? From manav.bhatia@alcatel-lucent.com Fri Feb 11 16:05:06 2011 Return-Path: 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 B25483A6A10 for ; Fri, 11 Feb 2011 16:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.656 X-Spam-Level: X-Spam-Status: No, score=-6.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5rvJnGi+KdAo for ; Fri, 11 Feb 2011 16:05:05 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 988383A6A62 for ; Fri, 11 Feb 2011 16:05:05 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p1C05CNX005796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 18:05:14 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1C05BLe020692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 12 Feb 2011 05:35:11 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 12 Feb 2011 05:35:11 +0530 From: "Bhatia, Manav (Manav)" To: "erosen@cisco.com" Date: Sat, 12 Feb 2011 05:35:10 +0530 Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvKEMFJfZEWW3RpQFuBsGTJXziO6AAN0ePA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F752C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of Fri, 11 Feb 2011 06:06:33 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB2F7263@INBANSXCHMBSA1.in.alcatel-lucent.com> <4568.1297445151@erosen-linux> In-Reply-To: <4568.1297445151@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:05:06 -0000 >=20 > > This draft introduces no changes in how the DR sends the Register > > packets. The same rules apply as defined in[RFC4601]. The only > > thing that changes is that the DR MUST send Register packets using > > the tunnel, instead of the regular registration encapsulation that's > > defined in [RFC4601]. >=20 > But then how does the RP distinguish a Register packet for=20 > (S,G) from an > "ordinary" (S,G) data packet? The regular (S,G) data packets would reach the RP natively over the SPT. It= s only the register packets that will use the tunnel. I do explain this in = the Appendix. "When the RP joins the SPT by sending (S,G) Join to its RPF neighbor for th= e source it will wait till it starts receiving packets natively before send= ing a Register-Stop message. Meanwhile, it will continue using the traffic= that arrives on the RSVP-TE tunnel and will forward it natively on the RPT= tree." Cheers, Manav= From sureshkannan@gmail.com Fri Feb 11 16:18:45 2011 Return-Path: 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 B11E73A6A24 for ; Fri, 11 Feb 2011 16:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 51L6MA1hi9pG for ; Fri, 11 Feb 2011 16:18:44 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 542493A69D1 for ; Fri, 11 Feb 2011 16:18:44 -0800 (PST) Received: by bwz12 with SMTP id 12so4086726bwz.31 for ; Fri, 11 Feb 2011 16:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oDqZ6c90E9zenpATnrhT5gpcXiKN91hgTSDmBtbcYdE=; b=dpxvBDY1Qc5GZAh5Z5MO/fvDhVf55pN9QbWJxTeP8oKJazZBQClOBvmP2HRIq+KYql 49kGITdEvuCpD9m4F02VRDKADMY4dXMP0dvNw72T4tl994EMOSqDk2fzJTLzIKl6LENP 0hSAByZRPdBmegNeuKYKux6dcGaykpMM/TUyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fSvOfnTJ+5KX7ehrW8HA5Eff7J6z6lnSQi4IECkUjFf5JhxgSoGep6gUDDwdVueFgL gAHeSSSl051pV8kgBp15vlIY8oho7pm51TaGblZuL8cW5wOJKMupE0S3gHUYI7Nf9i70 gnyB8sf17zYB/Le5Fag3MNqy2k2pKUyRveev8= MIME-Version: 1.0 Received: by 10.204.123.144 with SMTP id p16mr1029698bkr.25.1297469938140; Fri, 11 Feb 2011 16:18:58 -0800 (PST) Received: by 10.204.59.138 with HTTP; Fri, 11 Feb 2011 16:18:58 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F752C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F7263@INBANSXCHMBSA1.in.alcatel-lucent.com> <4568.1297445151@erosen-linux> <7C362EEF9C7896468B36C9B79200D8350CFB2F752C@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 11 Feb 2011 16:18:58 -0800 Message-ID: From: Sureshkannan To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=0016e6dd8969c50741049c0ac28e Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:18:45 -0000 --0016e6dd8969c50741049c0ac28e Content-Type: text/plain; charset=ISO-8859-1 Hi Manav, PIM RP router would accept (s,g) register packet and creates (s,g) entries even though its not local (s) (interface subnet). In this case, how does RP differentiate this packet?. Will MPLS gives some info to PIM about this packet is actually register packet based on tunnel end point ?. Thanks, Regards, Sureshkannan. On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > > > > > This draft introduces no changes in how the DR sends the Register > > > packets. The same rules apply as defined in[RFC4601]. The only > > > thing that changes is that the DR MUST send Register packets using > > > the tunnel, instead of the regular registration encapsulation that's > > > defined in [RFC4601]. > > > > But then how does the RP distinguish a Register packet for > > (S,G) from an > > "ordinary" (S,G) data packet? > > The regular (S,G) data packets would reach the RP natively over the SPT. > Its only the register packets that will use the tunnel. I do explain this in > the Appendix. > > "When the RP joins the SPT by sending (S,G) Join to its RPF neighbor for > the source it will wait till it starts receiving packets natively before > sending a Register-Stop message. Meanwhile, it will continue using the > traffic that arrives on the RSVP-TE tunnel and will forward it natively on > the RPT tree." > > Cheers, Manav > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > --0016e6dd8969c50741049c0ac28e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Manav,

PIM RP router would accept (s,g) register packet and creat= es (s,g) entries even though its not local (s) (interface subnet). In this = case, how does RP differentiate this packet?. Will MPLS gives some info to = PIM about this packet is actually register packet based on tunnel end point= ?.

Thanks,
Regards,
Sureshkannan.

= On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) &l= t;manav.bhatia@alcatel-l= ucent.com> wrote:
>
> > This draft introduces no changes in how the DR sends the Register=
> > packets. =A0The same rules apply as defined in[RFC4601]. =A0The o= nly
> > thing that changes is that the DR MUST send Register packets usin= g
> > the tunnel, instead of the regular registration encapsulation tha= t's
> > defined in [RFC4601].
>
> But then how does the RP distinguish a Register packet for
> (S,G) from an
> "ordinary" (S,G) data packet?

The regular (S,G) data packets would reach the RP natively over the S= PT. Its only the register packets that will use the tunnel. I do explain th= is in the Appendix.

"When the RP joins the SPT by sending (S,G) Join to its RPF neighbor f= or the source it will wait till it starts receiving packets natively before= sending a Register-Stop message. =A0Meanwhile, it will continue using the = traffic that arrives on the RSVP-TE tunnel and will forward it natively on = the RPT tree."

Cheers, Manav
_________________________________________= ______
pim mailing list
pim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pim

--0016e6dd8969c50741049c0ac28e-- From manav.bhatia@alcatel-lucent.com Fri Feb 11 16:25:36 2011 Return-Path: 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 4C0E93A6A21 for ; Fri, 11 Feb 2011 16:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.654 X-Spam-Level: X-Spam-Status: No, score=-6.654 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 NKvVtd6opf6Z for ; Fri, 11 Feb 2011 16:25:35 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D581C3A69D1 for ; Fri, 11 Feb 2011 16:25:34 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1C0PhBU018975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 18:25:45 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1C0PgKe021292 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 12 Feb 2011 05:55:42 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 12 Feb 2011 05:55:42 +0530 From: "Bhatia, Manav (Manav)" To: Sureshkannan Date: Sat, 12 Feb 2011 05:55:41 +0530 Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvKSnYf/EZcxFNwTMGcYtSYfZuBOAAAH5lA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB2F7530@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F7263@INBANSXCHMBSA1.in.alcatel-lucent.com> <4568.1297445151@erosen-linux> <7C362EEF9C7896468B36C9B79200D8350CFB2F752C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFB2F7530INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:25:36 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFB2F7530INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Suresh, The RP can identify that its an equivalent of a Register packet if it arriv= ed on an MPLS tunnel as against a packet that arrived natively over the SPT= . In case there is a P2MP/regular LSP thats delivering traffic over the SPT= , in which case you will get labeled packets there as well, the RP can disa= mbiguate between the two packets by looking at the tunnel label that the pa= cket arrives with. Cheers, Manav ________________________________ From: Sureshkannan [mailto:sureshkannan@gmail.com] Sent: Saturday, February 12, 2011 5.49 AM To: Bhatia, Manav (Manav) Cc: erosen@cisco.com; pim@ietf.org Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation Hi Manav, PIM RP router would accept (s,g) register packet and creates (s,g) entries = even though its not local (s) (interface subnet). In this case, how does RP= differentiate this packet?. Will MPLS gives some info to PIM about this pa= cket is actually register packet based on tunnel end point ?. Thanks, Regards, Sureshkannan. On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) > wrote: > > > This draft introduces no changes in how the DR sends the Register > > packets. The same rules apply as defined in[RFC4601]. The only > > thing that changes is that the DR MUST send Register packets using > > the tunnel, instead of the regular registration encapsulation that's > > defined in [RFC4601]. > > But then how does the RP distinguish a Register packet for > (S,G) from an > "ordinary" (S,G) data packet? The regular (S,G) data packets would reach the RP natively over the SPT. It= s only the register packets that will use the tunnel. I do explain this in = the Appendix. "When the RP joins the SPT by sending (S,G) Join to its RPF neighbor for th= e source it will wait till it starts receiving packets natively before send= ing a Register-Stop message. Meanwhile, it will continue using the traffic= that arrives on the RSVP-TE tunnel and will forward it natively on the RPT= tree." Cheers, Manav _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim --_000_7C362EEF9C7896468B36C9B79200D8350CFB2F7530INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Suresh,
 
The=20 RP can identify that its an equivalent of a Register packet if it arrived o= n an=20 MPLS tunnel as against a packet that arrived natively over the SPT. In case= =20 there is a P2MP/regular LSP thats delivering traffic over the SPT, in which= case=20 you will get labeled packets there as well, the RP can disambiguate between= the=20 two packets by looking at the tunnel label that the packet arrives=20 with.
 
Cheers, Manav

From: Sureshkannan=20 [mailto:sureshkannan@gmail.com]
Sent: Saturday, February 12, 2= 011=20 5.49 AM
To: Bhatia, Manav (Manav)
Cc: erosen@cisco.co= m;=20 pim@ietf.org
Subject: Re: [pim] Replacing PIM Register packets = with=20 MPLS encapsulation

Hi Manav,

PIM RP router would accept (s,g) register pac= ket=20 and creates (s,g) entries even though its not local (s) (interface subnet= ). In=20 this case, how does RP differentiate this packet?. Will MPLS gives some i= nfo=20 to PIM about this packet is actually register packet based on tunnel end = point=20 ?.

Thanks,
Regards,
Sureshkannan.

On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (= Manav)=20 <manav.bhatia@alcatel-luce= nt.com>=20 wrote:
>
> > This draft introduces no changes in h= ow the=20 DR sends the Register
> > packets.  The same rules apply = as=20 defined in[RFC4601].  The only
> > thing that changes is = that=20 the DR MUST send Register packets using
> > the tunnel, instea= d of=20 the regular registration encapsulation that's
> > defined in=20 [RFC4601].
>
> But then how does the RP distinguish a Regis= ter=20 packet for
> (S,G) from an
> "ordinary" (S,G) data=20 packet?

The regular (S,G) data packets would reach the RP= =20 natively over the SPT. Its only the register packets that will use the= =20 tunnel. I do explain this in the Appendix.

"When the RP joins th= e SPT=20 by sending (S,G) Join to its RPF neighbor for the source it will wait t= ill=20 it starts receiving packets natively before sending a Register-Stop mes= sage.=20  Meanwhile, it will continue using the traffic that arrives on the= =20 RSVP-TE tunnel and will forward it natively on the RPT tree."

Ch= eers,=20 Manav
_______________________________________________
pim = mailing=20 list
pim@ietf.org
https://www.ietf.org/mailman/listinfo/pim
=

--_000_7C362EEF9C7896468B36C9B79200D8350CFB2F7530INBANSXCHMBSA_-- From b4a1r6d4@gmail.com Sat Feb 12 14:49:21 2011 Return-Path: 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 B645E3A69CA for ; Sat, 12 Feb 2011 14:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 50cyb1JcCbS0 for ; Sat, 12 Feb 2011 14:49:20 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B39183A6A58 for ; Sat, 12 Feb 2011 14:49:20 -0800 (PST) Received: by qwi2 with SMTP id 2so2486665qwi.31 for ; Sat, 12 Feb 2011 14:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VvI/VbbWZQFt34O9HNaNvAcj3nTvtaAvBjRvotyaVLg=; b=nx7BMmP3usUG3Y5Q0Q2QlhUDLHy4cYObH7VvYaJEMZsSMPZvj8TKCWRBAaYlNtfG3v U7o/X5lRuC9tlsbEOsa5E2op+NRo3bCbd7wb/vs+qb4SAgAJ/lJ7xP5R1pA0v1iX2hRp edGtyXaQ0VNQ/m9daQOt1FU+vR9VEgQP8cCME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lRoftiQN61+Lv1bvLpSmIKCyboW08zNu7en8mKiNasdEIupFCq0JpMFCxiOGAsAsQE 5th29yc9SZ93Ox2AG0x7piJuDoGRmqOaDotSuGlnDzlbFPNRBnMakZXZN2mVfY8L9aic VSHRcvpDcEgO6YGspL4HLCjkIawEdSom9KwOo= MIME-Version: 1.0 Received: by 10.229.101.206 with SMTP id d14mr1743528qco.32.1297550977559; Sat, 12 Feb 2011 14:49:37 -0800 (PST) Received: by 10.229.95.21 with HTTP; Sat, 12 Feb 2011 14:49:37 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB2F7530@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB2F7263@INBANSXCHMBSA1.in.alcatel-lucent.com> <4568.1297445151@erosen-linux> <7C362EEF9C7896468B36C9B79200D8350CFB2F752C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFB2F7530@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sun, 13 Feb 2011 04:19:37 +0530 Message-ID: From: David Bard To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 22:49:21 -0000 Hi Manav, You might face an issue if RP is doing a PHP, as in that case you will not be able to differentiate these packets with the native multicast packets arriving over the SPT. However, this should not an issue since the RP must never send a label value 3 to the penultimate LSR. You might want to add this in your draft. Overall, i think the idea holds merit and i do support it. Dave On Sat, Feb 12, 2011 at 5:55 AM, Bhatia, Manav (Manav) wrote: > Hi Suresh, > > The RP can identify that its an equivalent of a Register packet if it > arrived on an MPLS tunnel as against a packet that arrived natively over = the > SPT. In case there is a P2MP/regular LSP thats delivering traffic over th= e > SPT, in which case you will get labeled packets there as well, the RP can > disambiguate between the two packets by looking at the tunnel label that = the > packet arrives with. > > Cheers, Manav > > ________________________________ > From: Sureshkannan [mailto:sureshkannan@gmail.com] > Sent: Saturday, February 12, 2011 5.49 AM > To: Bhatia, Manav (Manav) > Cc: erosen@cisco.com; pim@ietf.org > Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation > > Hi Manav, > > PIM RP router would accept (s,g) register packet and creates (s,g) entrie= s > even though its not local (s) (interface subnet). In this case, how does = RP > differentiate this packet?. Will MPLS gives some info to PIM about this > packet is actually register packet based on tunnel end point ?. > > Thanks, > Regards, > Sureshkannan. > > On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) > wrote: >> >> > >> > > This draft introduces no changes in how the DR sends the Register >> > > packets. =A0The same rules apply as defined in[RFC4601]. =A0The only >> > > thing that changes is that the DR MUST send Register packets using >> > > the tunnel, instead of the regular registration encapsulation that's >> > > defined in [RFC4601]. >> > >> > But then how does the RP distinguish a Register packet for >> > (S,G) from an >> > "ordinary" (S,G) data packet? >> >> The regular (S,G) data packets would reach the RP natively over the SPT. >> Its only the register packets that will use the tunnel. I do explain thi= s in >> the Appendix. >> >> "When the RP joins the SPT by sending (S,G) Join to its RPF neighbor for >> the source it will wait till it starts receiving packets natively before >> sending a Register-Stop message. =A0Meanwhile, it will continue using th= e >> traffic that arrives on the RSVP-TE tunnel and will forward it natively = on >> the RPT tree." >> >> Cheers, Manav >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > > From ycai@cisco.com Sat Feb 12 20:29:34 2011 Return-Path: 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 3ABE83A6A8A for ; Sat, 12 Feb 2011 20:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 hEAc5C0M0DHy for ; Sat, 12 Feb 2011 20:29:32 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 701383A6A89 for ; Sat, 12 Feb 2011 20:29:32 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBANrsVk2rRN+J/2dsb2JhbACXKI12ZXOeQZosgn2CYQSFBIZ7gziDBg X-IronPort-AV: E=Sophos;i="4.60,464,1291593600"; d="scan'208";a="262663277" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2011 04:29:51 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1D4TplQ019478; Sun, 13 Feb 2011 04:29:51 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Feb 2011 20:29:51 -0800 Received: from 10.21.69.89 ([10.21.69.89]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Feb 2011 04:29:51 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Sat, 12 Feb 2011 20:29:52 -0800 From: Yiqun Cai To: David Bard , "Bhatia, Manav (Manav)" Message-ID: Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvLNqgn435SgTf4g0CibZtiq3bDqA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 13 Feb 2011 04:29:51.0433 (UTC) FILETIME=[A7D09B90:01CBCB36] Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 04:29:34 -0000 I do have some concerns with the proposal. Most of the RP implementations today attempt to switch to source trees upon receiving a register. After that, most, if not all, the processing is related to the handling of null registers. The overhead of extracting the (S,G) information from the null register is not that significant, because i= t is a fixed sized header from a fixed offset. So I don't see using an MPLS tunnel can improve scalability or performance substantially. On the other hand, using an MPLS tunnel requires some mechanism, static or dynamic, to distribute labels between the RP and the DRs (and maybe everyon= e in between too). This overhead has to be discussed when evaluating the improvement over the existing registering mechanism. Finally, the draft doesn't address how the proposal can work with Anycast R= P as described by RFC3446 and RFC4610. As Anycast RP is the most common and important choice of RP engineering in today's network, not addressing this issue will make the solution very difficult to deploy. Thanks. =20 On 2/12/11 2:49 PM, "David Bard" wrote: > Hi Manav, >=20 > You might face an issue if RP is doing a PHP, as in that case you will > not be able to differentiate these packets with the native multicast > packets arriving over the SPT. However, this should not an issue since > the RP must never send a label value 3 to the penultimate LSR. You > might want to add this in your draft. >=20 > Overall, i think the idea holds merit and i do support it. >=20 > Dave >=20 > On Sat, Feb 12, 2011 at 5:55 AM, Bhatia, Manav (Manav) > wrote: >> Hi Suresh, >>=20 >> The RP can identify that its an equivalent of a Register packet if it >> arrived on an MPLS tunnel as against a packet that arrived natively over= the >> SPT. In case there is a P2MP/regular LSP thats delivering traffic over t= he >> SPT, in which case you will get labeled packets there as well, the RP ca= n >> disambiguate between the two packets by looking at the tunnel label that= the >> packet arrives with. >>=20 >> Cheers, Manav >>=20 >> ________________________________ >> From: Sureshkannan [mailto:sureshkannan@gmail.com] >> Sent: Saturday, February 12, 2011 5.49 AM >> To: Bhatia, Manav (Manav) >> Cc: erosen@cisco.com; pim@ietf.org >> Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulatio= n >>=20 >> Hi Manav, >>=20 >> PIM RP router would accept (s,g) register packet and creates (s,g) entri= es >> even though its not local (s) (interface subnet). In this case, how does= RP >> differentiate this packet?. Will MPLS gives some info to PIM about this >> packet is actually register packet based on tunnel end point ?. >>=20 >> Thanks, >> Regards, >> Sureshkannan. >>=20 >> On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) >> wrote: >>>=20 >>>>=20 >>>>> This draft introduces no changes in how the DR sends the Register >>>>> packets. =A0The same rules apply as defined in[RFC4601]. =A0The only >>>>> thing that changes is that the DR MUST send Register packets using >>>>> the tunnel, instead of the regular registration encapsulation that's >>>>> defined in [RFC4601]. >>>>=20 >>>> But then how does the RP distinguish a Register packet for >>>> (S,G) from an >>>> "ordinary" (S,G) data packet? >>>=20 >>> The regular (S,G) data packets would reach the RP natively over the SPT= . >>> Its only the register packets that will use the tunnel. I do explain th= is in >>> the Appendix. >>>=20 >>> "When the RP joins the SPT by sending (S,G) Join to its RPF neighbor fo= r >>> the source it will wait till it starts receiving packets natively befor= e >>> sending a Register-Stop message. =A0Meanwhile, it will continue using the >>> traffic that arrives on the RSVP-TE tunnel and will forward it natively= on >>> the RPT tree." >>>=20 >>> Cheers, Manav >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >>=20 >>=20 >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >>=20 >>=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim --=20 Yiqun From manav.bhatia@alcatel-lucent.com Sun Feb 13 00:48:30 2011 Return-Path: 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 96BE73A6B5B for ; Sun, 13 Feb 2011 00:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.652 X-Spam-Level: X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qYx9emrMsqm0 for ; Sun, 13 Feb 2011 00:48:29 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 63A323A68A4 for ; Sun, 13 Feb 2011 00:48:29 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p1D8m3k4022010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Feb 2011 02:48:05 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1D8m1fK026376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 13 Feb 2011 14:18:01 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sun, 13 Feb 2011 14:18:01 +0530 From: "Bhatia, Manav (Manav)" To: Yiqun Cai , David Bard Date: Sun, 13 Feb 2011 14:17:54 +0530 Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvLNqgn435SgTf4g0CibZtiq3bDqAAIlHmw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFC91B03E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 08:48:30 -0000 Hi Yiqun, This mechanism is exclusively meant for networks that are MPLS enabled, so = setting up a tunnel and distributing labels between the DRs and the RPs sho= uld not be a concern. If it's the RSVP control traffic that you are concern= ed with then we can use the RSVP Refresh reduction mechanism as described i= n RFC 2961. If it's the state that you are concerned with then we could go = in for a LDP based solution. I agree that this draft must also address Anycast RP; will do that in the n= ext revision. Quickly, would the following approach work?=20 Instead of the RP (one closest to the source) ensuring that all PIM Registe= r messages reach the other RPs in the Anycast-RP set, cant the DR set up se= parate RSVP tunnels to each RP. Alternatively the DR can set up one P2MP LS= P with all the RPs. The mechanism would then be the same as described in th= e current draft. No changes there. Using one Path message to describe all t= he S2L sub-LSPs the control traffic too would be limited. Cheers, Manav > -----Original Message----- > From: Yiqun Cai [mailto:ycai@cisco.com]=20 > Sent: Sunday, February 13, 2011 10.00 AM > To: David Bard; Bhatia, Manav (Manav) > Cc: pim@ietf.org > Subject: Re: [pim] Replacing PIM Register packets with MPLS=20 > encapsulation >=20 > I do have some concerns with the proposal. >=20 > Most of the RP implementations today attempt to switch to=20 > source trees upon > receiving a register. After that, most, if not all, the processing is > related to the handling of null registers. The overhead of=20 > extracting the > (S,G) information from the null register is not that=20 > significant, because it > is a fixed sized header from a fixed offset. So I don't see=20 > using an MPLS > tunnel can improve scalability or performance substantially. >=20 > On the other hand, using an MPLS tunnel requires some=20 > mechanism, static or > dynamic, to distribute labels between the RP and the DRs (and=20 > maybe everyone > in between too). This overhead has to be discussed when=20 > evaluating the > improvement over the existing registering mechanism. >=20 > Finally, the draft doesn't address how the proposal can work=20 > with Anycast RP > as described by RFC3446 and RFC4610. As Anycast RP is the=20 > most common and > important choice of RP engineering in today's network, not=20 > addressing this > issue will make the solution very difficult to deploy. >=20 > Thanks. >=20 >=20 >=20 > =20 >=20 >=20 > On 2/12/11 2:49 PM, "David Bard" wrote: >=20 > > Hi Manav, > >=20 > > You might face an issue if RP is doing a PHP, as in that=20 > case you will > > not be able to differentiate these packets with the native multicast > > packets arriving over the SPT. However, this should not an=20 > issue since > > the RP must never send a label value 3 to the penultimate LSR. You > > might want to add this in your draft. > >=20 > > Overall, i think the idea holds merit and i do support it. > >=20 > > Dave > >=20 > > On Sat, Feb 12, 2011 at 5:55 AM, Bhatia, Manav (Manav) > > wrote: > >> Hi Suresh, > >>=20 > >> The RP can identify that its an equivalent of a Register=20 > packet if it > >> arrived on an MPLS tunnel as against a packet that arrived=20 > natively over the > >> SPT. In case there is a P2MP/regular LSP thats delivering=20 > traffic over the > >> SPT, in which case you will get labeled packets there as=20 > well, the RP can > >> disambiguate between the two packets by looking at the=20 > tunnel label that the > >> packet arrives with. > >>=20 > >> Cheers, Manav > >>=20 > >> ________________________________ > >> From: Sureshkannan [mailto:sureshkannan@gmail.com] > >> Sent: Saturday, February 12, 2011 5.49 AM > >> To: Bhatia, Manav (Manav) > >> Cc: erosen@cisco.com; pim@ietf.org > >> Subject: Re: [pim] Replacing PIM Register packets with=20 > MPLS encapsulation > >>=20 > >> Hi Manav, > >>=20 > >> PIM RP router would accept (s,g) register packet and=20 > creates (s,g) entries > >> even though its not local (s) (interface subnet). In this=20 > case, how does RP > >> differentiate this packet?. Will MPLS gives some info to=20 > PIM about this > >> packet is actually register packet based on tunnel end point ?. > >>=20 > >> Thanks, > >> Regards, > >> Sureshkannan. > >>=20 > >> On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) > >> wrote: > >>>=20 > >>>>=20 > >>>>> This draft introduces no changes in how the DR sends=20 > the Register > >>>>> packets. =A0The same rules apply as defined in[RFC4601]. =A0The onl= y > >>>>> thing that changes is that the DR MUST send Register=20 > packets using > >>>>> the tunnel, instead of the regular registration=20 > encapsulation that's > >>>>> defined in [RFC4601]. > >>>>=20 > >>>> But then how does the RP distinguish a Register packet for > >>>> (S,G) from an > >>>> "ordinary" (S,G) data packet? > >>>=20 > >>> The regular (S,G) data packets would reach the RP=20 > natively over the SPT. > >>> Its only the register packets that will use the tunnel. I=20 > do explain this in > >>> the Appendix. > >>>=20 > >>> "When the RP joins the SPT by sending (S,G) Join to its=20 > RPF neighbor for > >>> the source it will wait till it starts receiving packets=20 > natively before > >>> sending a Register-Stop message. =A0Meanwhile, it will=20 > continue using the > >>> traffic that arrives on the RSVP-TE tunnel and will=20 > forward it natively on > >>> the RPT tree." > >>>=20 > >>> Cheers, Manav > >>> _______________________________________________ > >>> pim mailing list > >>> pim@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pim > >>=20 > >>=20 > >> _______________________________________________ > >> pim mailing list > >> pim@ietf.org > >> https://www.ietf.org/mailman/listinfo/pim > >>=20 > >>=20 > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 >=20 > --=20 > Yiqun >=20 > = From erosen@cisco.com Mon Feb 14 06:21:28 2011 Return-Path: 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 5DBD73A6D54 for ; Mon, 14 Feb 2011 06:21:28 -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 7W3BlOCOAfCg for ; Mon, 14 Feb 2011 06:21:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 67C7E3A6D4A for ; Mon, 14 Feb 2011 06:21:27 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="215379047" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2011 14:21:38 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1EELbKw025927; Mon, 14 Feb 2011 14:21:37 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p1EELbdA031409; Mon, 14 Feb 2011 09:21:37 -0500 To: "Bhatia, Manav (Manav)" In-reply-to: Your message of Sat, 12 Feb 2011 05:55:41 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB2F7530@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 14 Feb 2011 09:21:37 -0500 Message-ID: <31408.1297693297@erosen-linux> From: Eric Rosen Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 14:21:28 -0000 Manav> The RP can identify that its an equivalent of a Register packet if it Manav> arrived on an MPLS tunnel as against a packet that arrived natively Manav> over the SPT I really don't understand this. If you were running PIM on an overlay topology that consists of pseudowires, e.g., every packet whatsoever would be arriving on an MPLS tunnel. In another scenario, an (S,G) data packet might be arriving from its prior hop over a backup tunnel. David> However, this should not an issue since the RP must never send a David> label value 3 to the penultimate LSR. Under any circumstances? I don't think you want to turn off php for all traffic just because you're functioning as an RP. Perhaps the supposition is that the DR sets up a special TE tunnel to the RP, where the purpose of that tunnel is exclusively to carry register packets, and the tunnel does not use php. But this would require additional signaling between the DR and the RP so that the RP knows that the tunnel is being used only for register packets originating from that DR. From ycai@cisco.com Mon Feb 14 14:01:31 2011 Return-Path: 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 700A93A6C2B for ; Mon, 14 Feb 2011 14:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 eS2jODX8+7HQ for ; Mon, 14 Feb 2011 14:01:30 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8AC6B3A6810 for ; Mon, 14 Feb 2011 14:01:30 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4HAOs0WU2rR7Ht/2dsb2JhbACmCQJzoDSbO4J9gmEEhQSGe4M4hSE X-IronPort-AV: E=Sophos;i="4.60,470,1291593600"; d="scan'208";a="259944202" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2011 22:01:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1EM1ssT009406; Mon, 14 Feb 2011 22:01:54 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 14:01:54 -0800 Received: from 128.107.112.114 ([128.107.112.114]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Feb 2011 22:01:54 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 14 Feb 2011 14:02:00 -0800 From: Yiqun Cai To: Eric Rosen , "Bhatia, Manav (Manav)" Message-ID: Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvMks3JPGaJjrKBYUaq9wbmA+hPxw== In-Reply-To: <31408.1297693297@erosen-linux> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Feb 2011 22:01:54.0205 (UTC) FILETIME=[CA54FCD0:01CBCC92] Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 22:01:31 -0000 On 2/14/11 6:21 AM, "Eric Rosen" wrote: > > Manav> The RP can identify that its an equivalent of a Register packet if it > Manav> arrived on an MPLS tunnel as against a packet that arrived natively > Manav> over the SPT > > I really don't understand this. If you were running PIM on an overlay > topology that consists of pseudowires, e.g., every packet whatsoever would > be arriving on an MPLS tunnel. In another scenario, an (S,G) data packet > might be arriving from its prior hop over a backup tunnel. > > David> However, this should not an issue since the RP must never send a > David> label value 3 to the penultimate LSR. > > Under any circumstances? I don't think you want to turn off php for all > traffic just because you're functioning as an RP. > > Perhaps the supposition is that the DR sets up a special TE tunnel to the > RP, where the purpose of that tunnel is exclusively to carry register > packets, and the tunnel does not use php. But this would require additional > signaling between the DR and the RP so that the RP knows that the tunnel is > being used only for register packets originating from that DR. That is where I see overhead outweighs the benefits. > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- Yiqun From ycai@cisco.com Mon Feb 14 14:02:33 2011 Return-Path: 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 9621A3A6997 for ; Mon, 14 Feb 2011 14:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 dmrP8FOSII3n for ; Mon, 14 Feb 2011 14:02:32 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3FA913A6810 for ; Mon, 14 Feb 2011 14:02:32 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoABAOs0WU2rR7Hu/2dsb2JhbACXLo5bAnOgNJs7gn2CYQSFBIZ7gziDBoIb X-IronPort-AV: E=Sophos;i="4.60,470,1291593600"; d="scan'208";a="259945210" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2011 22:02:56 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1EM2u2c014425; Mon, 14 Feb 2011 22:02:56 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 14:02:56 -0800 Received: from 128.107.112.114 ([128.107.112.114]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Feb 2011 22:02:55 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 14 Feb 2011 14:03:02 -0800 From: Yiqun Cai To: "Bhatia, Manav (Manav)" , David Bard Message-ID: Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvLNqgn435SgTf4g0CibZtiq3bDqAAIlHmwAE5+LKQ= In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFC91B03E@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Feb 2011 22:02:56.0170 (UTC) FILETIME=[EF4418A0:01CBCC92] Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 22:02:33 -0000 On 2/13/11 12:47 AM, "Bhatia, Manav (Manav)" wrote: > Hi Yiqun, >=20 > This mechanism is exclusively meant for networks that are MPLS enabled, s= o > setting up a tunnel and distributing labels between the DRs and the RPs s= hould > not be a concern. If it's the RSVP control traffic that you are concerned= with > then we can use the RSVP Refresh reduction mechanism as described in RFC = 2961. > If it's the state that you are concerned with then we could go in for a L= DP > based solution. >=20 > I agree that this draft must also address Anycast RP; will do that in the= next > revision. >=20 > Quickly, would the following approach work? >=20 > Instead of the RP (one closest to the source) ensuring that all PIM Regis= ter > messages reach the other RPs in the Anycast-RP set, cant the DR set up > separate RSVP tunnels to each RP. Alternatively the DR can set up one P2M= P LSP > with all the RPs. The mechanism would then be the same as described in th= e > current draft. No changes there. Using one Path message to describe all t= he > S2L sub-LSPs the control traffic too would be limited. >=20 Today, both Anycast RP solutions require only participation from the RPs. DRs are not involved. DRs see only one RP per group (range). > Cheers, Manav >=20 >=20 >> -----Original Message----- >> From: Yiqun Cai [mailto:ycai@cisco.com] >> Sent: Sunday, February 13, 2011 10.00 AM >> To: David Bard; Bhatia, Manav (Manav) >> Cc: pim@ietf.org >> Subject: Re: [pim] Replacing PIM Register packets with MPLS >> encapsulation >>=20 >> I do have some concerns with the proposal. >>=20 >> Most of the RP implementations today attempt to switch to >> source trees upon >> receiving a register. After that, most, if not all, the processing is >> related to the handling of null registers. The overhead of >> extracting the >> (S,G) information from the null register is not that >> significant, because it >> is a fixed sized header from a fixed offset. So I don't see >> using an MPLS >> tunnel can improve scalability or performance substantially. >>=20 >> On the other hand, using an MPLS tunnel requires some >> mechanism, static or >> dynamic, to distribute labels between the RP and the DRs (and >> maybe everyone >> in between too). This overhead has to be discussed when >> evaluating the >> improvement over the existing registering mechanism. >>=20 >> Finally, the draft doesn't address how the proposal can work >> with Anycast RP >> as described by RFC3446 and RFC4610. As Anycast RP is the >> most common and >> important choice of RP engineering in today's network, not >> addressing this >> issue will make the solution very difficult to deploy. >>=20 >> Thanks. >>=20 >>=20 >>=20 >> =20 >>=20 >>=20 >> On 2/12/11 2:49 PM, "David Bard" wrote: >>=20 >>> Hi Manav, >>>=20 >>> You might face an issue if RP is doing a PHP, as in that >> case you will >>> not be able to differentiate these packets with the native multicast >>> packets arriving over the SPT. However, this should not an >> issue since >>> the RP must never send a label value 3 to the penultimate LSR. You >>> might want to add this in your draft. >>>=20 >>> Overall, i think the idea holds merit and i do support it. >>>=20 >>> Dave >>>=20 >>> On Sat, Feb 12, 2011 at 5:55 AM, Bhatia, Manav (Manav) >>> wrote: >>>> Hi Suresh, >>>>=20 >>>> The RP can identify that its an equivalent of a Register >> packet if it >>>> arrived on an MPLS tunnel as against a packet that arrived >> natively over the >>>> SPT. In case there is a P2MP/regular LSP thats delivering >> traffic over the >>>> SPT, in which case you will get labeled packets there as >> well, the RP can >>>> disambiguate between the two packets by looking at the >> tunnel label that the >>>> packet arrives with. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>> ________________________________ >>>> From: Sureshkannan [mailto:sureshkannan@gmail.com] >>>> Sent: Saturday, February 12, 2011 5.49 AM >>>> To: Bhatia, Manav (Manav) >>>> Cc: erosen@cisco.com; pim@ietf.org >>>> Subject: Re: [pim] Replacing PIM Register packets with >> MPLS encapsulation >>>>=20 >>>> Hi Manav, >>>>=20 >>>> PIM RP router would accept (s,g) register packet and >> creates (s,g) entries >>>> even though its not local (s) (interface subnet). In this >> case, how does RP >>>> differentiate this packet?. Will MPLS gives some info to >> PIM about this >>>> packet is actually register packet based on tunnel end point ?. >>>>=20 >>>> Thanks, >>>> Regards, >>>> Sureshkannan. >>>>=20 >>>> On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) >>>> wrote: >>>>>=20 >>>>>>=20 >>>>>>> This draft introduces no changes in how the DR sends >> the Register >>>>>>> packets. =A0The same rules apply as defined in[RFC4601]. =A0The only >>>>>>> thing that changes is that the DR MUST send Register >> packets using >>>>>>> the tunnel, instead of the regular registration >> encapsulation that's >>>>>>> defined in [RFC4601]. >>>>>>=20 >>>>>> But then how does the RP distinguish a Register packet for >>>>>> (S,G) from an >>>>>> "ordinary" (S,G) data packet? >>>>>=20 >>>>> The regular (S,G) data packets would reach the RP >> natively over the SPT. >>>>> Its only the register packets that will use the tunnel. I >> do explain this in >>>>> the Appendix. >>>>>=20 >>>>> "When the RP joins the SPT by sending (S,G) Join to its >> RPF neighbor for >>>>> the source it will wait till it starts receiving packets >> natively before >>>>> sending a Register-Stop message. =A0Meanwhile, it will >> continue using the >>>>> traffic that arrives on the RSVP-TE tunnel and will >> forward it natively on >>>>> the RPT tree." >>>>>=20 >>>>> Cheers, Manav >>>>> _______________________________________________ >>>>> pim mailing list >>>>> pim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pim >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pim mailing list >>>> pim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pim >>>>=20 >>>>=20 >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >>=20 >>=20 >> --=20 >> Yiqun >>=20 >>=20 --=20 Yiqun From manav.bhatia@alcatel-lucent.com Mon Feb 14 15:09:59 2011 Return-Path: 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 683F83A6DD6 for ; Mon, 14 Feb 2011 15:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.651 X-Spam-Level: X-Spam-Status: No, score=-6.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1+YrbHt7vKSy for ; Mon, 14 Feb 2011 15:09:58 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 7D9013A6C2E for ; Mon, 14 Feb 2011 15:09:57 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1ENADYt026236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Feb 2011 17:10:15 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1ENABGd015477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Feb 2011 04:40:12 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 15 Feb 2011 04:40:11 +0530 From: "Bhatia, Manav (Manav)" To: "erosen@cisco.com" Date: Tue, 15 Feb 2011 04:40:10 +0530 Thread-Topic: [pim] Replacing PIM Register packets with MPLS encapsulation Thread-Index: AcvMUpIfugskMK0FRtyr4eYEWeGQ+QASDcTw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFC91B2FB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: Your message of Sat, 12 Feb 2011 05:55:41 +0530. <7C362EEF9C7896468B36C9B79200D8350CFB2F7530@INBANSXCHMBSA1.in.alcatel-lucent.com> <31408.1297693297@erosen-linux> In-Reply-To: <31408.1297693297@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "pim@ietf.org" Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 23:09:59 -0000 Eric, =20 > Manav> The RP can identify that its an equivalent of a=20 > Register packet if it > Manav> arrived on an MPLS tunnel as against a packet that=20 > arrived natively > Manav> over the SPT >=20 > I really don't understand this. If you were running PIM on an overlay > topology that consists of pseudowires, e.g., every packet=20 > whatsoever would > be arriving on an MPLS tunnel. In another scenario, an (S,G)=20 > data packet > might be arriving from its prior hop over a backup tunnel. =20 Fair enough. Then can we change this to say that RP can identify that its a= n equivalent of a Register packet if it arrived on an MPLS tunnel that was = explicitly set up with the DR? It can disambiguate that based on the outerm= ost tunnel value. > David> However, this should not an issue since the RP must=20 > never send a > David> label value 3 to the penultimate LSR. >=20 > Under any circumstances? I don't think you want to turn off=20 > php for all > traffic just because you're functioning as an RP. >=20 > Perhaps the supposition is that the DR sets up a special TE=20 > tunnel to the > RP, where the purpose of that tunnel is exclusively to carry register > packets, and the tunnel does not use php. =20 Yes. > But this would=20 > require additional > signaling between the DR and the RP so that the RP knows that=20 > the tunnel is > being used only for register packets originating from that DR. This should not be too difficult. One could for example use LSP_Attribute o= bject which would allow setting a flag indicating that this LSP is meant on= ly for carrying register packets originating from the DR. Cheers, Manav= From Internet-Drafts@ietf.org Tue Feb 15 12:00:03 2011 Return-Path: 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 6C3443A6D70; Tue, 15 Feb 2011 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qKwfm7Se9+C3; Tue, 15 Feb 2011 12:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1D13A6D6F; Tue, 15 Feb 2011 12:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215200002.22757.9681.idtracker@localhost> Date: Tue, 15 Feb 2011 12:00:02 -0800 Cc: pim@ietf.org Subject: [pim] I-D Action:draft-ietf-pim-port-05.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 20:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : A Reliable Transport Mechanism for PIM Author(s) : D. Farinacci, et al. Filename : draft-ietf-pim-port-05.txt Pages : 32 Date : 2011-02-15 This draft describes how a reliable transport mechanism can be used by the PIM protocol to optimize CPU and bandwidth resource utilization by eliminating periodic Join/Prune message transmission. This draft proposes a modular extension to PIM to use either the TCP or SCTP transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-port-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pim-port-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-15115416.I-D@ietf.org> --NextPart-- From stig@venaas.com Tue Feb 15 12:39:49 2011 Return-Path: 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 9C3933A6D9F for ; Tue, 15 Feb 2011 12:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 MTNNWer+FKSZ for ; Tue, 15 Feb 2011 12:39:48 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 2BD3B3A6C43 for ; Tue, 15 Feb 2011 12:39:48 -0800 (PST) Received: from [10.33.12.88] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6E2708008 for ; Tue, 15 Feb 2011 21:40:13 +0100 (CET) Message-ID: <4D5AE4AA.7060501@venaas.com> Date: Tue, 15 Feb 2011 12:40:10 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] pim-port 05 changes X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 20:39:49 -0000 I just posted version 05, http://tools.ietf.org/html/draft-ietf-pim-port-05 There are quite a lot of changes based on the wglc input and the recent discussions on the list. I will try to summarize the changes here. Those of you that provided comments, and hopefully the rest of you as well, please have a look and see if you are happy with this. Let me know of any issues. Thanks a lot for all your input, I certainly feel the document quality is significantly improved. 1. PIM Hello format We previously had an Interface ID field in the TCP and SCTP Hello options. After some discussions with people that may also need an Interface ID, I figured that it is better to have a separate Hello option. E.g. if we include both TCP and SCTP Hello options, why include Interface ID twice in the Hello. Similarly if other protocols need it, it would be a shame to include the ID several times in the Hello. See the new draft http://tools.ietf.org/html/draft-gulrajani-pim-hello-intid-00 for definition of an Interface ID option. For PORT we just say that if the Hello includes the TCP or SCTP option, then it MUST also contain the Interface ID option. 2. PORT Join/Prune message format I was asked to remove Instance ID since we don't know how we would use it. I change the format to using options, so that we can add things like Instance ID later if we find a use for it. I then decided to have a single PORT Join/Prune message that contains an option for PIM J/P. There are different options for IPv4 and IPv6. I made it an option partly because I want a length field for the PIM J/P. 3. Keep-alive message Based on the recent discussions I added a keep-alive message. Rather than mandating that PORT messages are sent at a certain frequency, I specified a holdtime field. If no PORT messages are received within the holdtime, the connection should be taken down. Note that keep-alive messages need not be sent if other PORT messages are sent frequently enough. 4. TTL check (GTSM) MUST send with TTL of 255. Optional to verify when receiving. 5. Improved text Other than that I've tweaked various text based on your input, and things I also figured were not clear enough. This includes IANA and Security considerations. Stig From stig@venaas.com Tue Feb 15 12:41:54 2011 Return-Path: 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 B48153A6DB2 for ; Tue, 15 Feb 2011 12:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WuVj8N1jNBvh for ; Tue, 15 Feb 2011 12:41:54 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id D83AD3A6D9F for ; Tue, 15 Feb 2011 12:41:53 -0800 (PST) Received: from [10.33.12.88] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 5734C8008 for ; Tue, 15 Feb 2011 21:42:19 +0100 (CET) Message-ID: <4D5AE529.8000205@venaas.com> Date: Tue, 15 Feb 2011 12:42:17 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pim@ietf.org References: <4D5AE4AA.7060501@venaas.com> In-Reply-To: <4D5AE4AA.7060501@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] pim-port 05 changes X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 20:41:54 -0000 On 2/15/2011 12:40 PM, Stig Venaas wrote: > I just posted version 05, > http://tools.ietf.org/html/draft-ietf-pim-port-05 > > There are quite a lot of changes based on the wglc input and the recent > discussions on the list. > > I will try to summarize the changes here. Those of you that provided > comments, and hopefully the rest of you as well, please have a look and > see if you are happy with this. Let me know of any issues. [...] For changes you may also check the diff at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-port-05.txt Stig From iesg-secretary@ietf.org Wed Feb 23 11:25:00 2011 Return-Path: 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 AED053A6A2D; Wed, 23 Feb 2011 11:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mEhTJL0kJJDz; Wed, 23 Feb 2011 11:24:59 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6653A6A33; Wed, 23 Feb 2011 11:24:59 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110223192459.27362.92074.idtracker@localhost> Date: Wed, 23 Feb 2011 11:24:59 -0800 Cc: Internet Architecture Board , pim chair , pim mailing list , RFC Editor Subject: [pim] Protocol Action: 'A Registry for PIM Message Types' to Proposed Standard (draft-ietf-pim-registry-04.txt) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 19:25:00 -0000 The IESG has approved the following document: - 'A Registry for PIM Message Types' (draft-ietf-pim-registry-04.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-registry/ Technical Summary This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies initial content of the registry based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types. In addition to this, one message type is reserved, and may be used for a future extension of the message type space. Working Group Summary This draft is the product of the PIM WG where it has been reviewed. Document Quality This document creates an IANA registry and requires no implementation. The codepoints allocated are already in use in existing RFCs. A number of minor comments were raised in IETF last call and Directorate reviews - these were addressed in a new revision. Personnel Mike McBride (mcbride@cisco.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From bharat_joshi@infosys.com Sun Feb 27 21:15:40 2011 Return-Path: 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 9D4D33A6A5F for ; Sun, 27 Feb 2011 21:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-1.675, BAYES_00=-2.599] 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 w3hEvg8syoKk for ; Sun, 27 Feb 2011 21:15:39 -0800 (PST) Received: from KECGATE08.infosys.com (Kecgate08.infosysconsulting.com [122.98.10.33]) by core3.amsl.com (Postfix) with ESMTP id 7994E3A68D9 for ; Sun, 27 Feb 2011 21:15:37 -0800 (PST) X-TM-IMSS-Message-ID: <121927d600423352@infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 121927d600423352 ; Mon, 28 Feb 2011 10:50:40 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.26]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Mon, 28 Feb 2011 10:46:35 +0530 From: Bharat Joshi To: "stig@cisco.com" Date: Mon, 28 Feb 2011 10:46:34 +0530 Thread-Topic: Some questions and suggestions on PIM-PORT draft Thread-Index: AQHL1waqmwaJMdvCxUqMPtOkYSlLOA== Message-ID: <31D55C4D55BEED48A4459EB64567589A10AD0CB4C1@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: [pim] Some questions and suggestions on PIM-PORT draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 05:15:40 -0000 Hi=20Stig, =20=20=20=20I=20finally=20managed=20to=20squeeze=20some=20time=20to=20loo= k=20at=20the=20updated=20draft.=20I=20have=20got=20some=20more=20question= s=20on=20this=20below: Regards, Bharat =95=20You=20may=20want=20to=20add=20'mechanism'=20in=20the=20following=20= sentence:=20"if=20and=20only=20if=20both=20have=20reliable=20transport=20= enabled."=20->=20"if=20and=20only=20if=20both=20have=20reliable=20transpo= rt=20mechanism=20enabled. =95=20Can=20we=20just=20use=20the=20full-form=20when=20an=20acronyms=20us= ed=20first=20time?=20I=20am=20sure=20it=20will=20be=20asked=20when=20IESG= =20review=20happens.=20For=20example:=20RPF=20neighbor.=20Another=20usefu= l=20thing=20would=20be=20to=20add=20such=20acronyms=20in=20terminology=20= or=20a=20reference=20to=20other=20RFC. =95=20In=20section=203.1,=20section=20number=20is=20missing=20in: 'All=20Hello=20messages=20containing=20the=20PIM-over-TCP=20Capable=20hel= lo=20option,=20=20=20MUST=20also=20contain=20the=20Interface=20ID=20hello= =20option,=20see=20section=20." =95=20In=20section=203.1,=20should=20we=20use=20'It=20is=20RECOMMENDED=20= that'=20instead=20of=20"We=20RECOMMEND=20that". =95=20The=20above=20two=20issues=20in=20section=203.2=20as=20well. =95=20In=20section=204,=20the=20paragraph=20starting=20with=20"It=20is=20= possible=20that=20a=20router=20starts"=20interchangeably=20uses=20ID=20or= =20IDs.=20We=20start=20describing=20things=20in=20ID=20but=20later=20star= t=20using=20IDs.=20Can=20we=20keep=20this=20consistent? =95=20In=20section=204,=20it=20is=20described=20that=20a=20full-table=20u= pdate=20happens=20when=20connection=20is=20established=20and=20any=20stat= e=20received=20during=20datagram=20is=20left=20to=20expire.=20Can=20we=20= be=20explicit=20on=20what=20to=20do=20with=20timer=20of=20each=20group=20= for=20which=20the=20update=20has=20been=20received?=20I=20think=20we=20ne= ed=20to=20stop=20that=20timer=20when=20we=20move=20from=20datagram=20to= =20PORT=20mode=20and=20for=20which=20the=20update=20has=20been=20received= .=20Right? =95=20In=20section=204,=20also,=20do=20we=20start=20the=20timer=20for=20e= ach=20state=20if=20the=20PORT=20connection=20goes=20down?=20What=20do=20w= e=20do=20with=20this=20timer=20when=20the=20connection=20is=20reestablish= ed=20and=20an=20update=20is=20received.=20So=20in=20affect,=20the=20same= =20functionality=20as=20asked=20in=20the=20previous=20question? =95=20Small=20typo=20"One=20can=20quicker=20detect=20that"=20->=20"One=20= can=20quickly=20detect=20that" =95=20Small=20typo=20in=20"since=20the=20the=20previous" =95=20In=20section=204.2,=20most=20of=20the=20test=20in=20para=202=20and= =203=20are=20repetitive.=20Can=20we=20cut=20down=20to=20keep=20it=20more= =20straight=20forward? =95=20In=20para=202=20of=20section=204.2,=20=20draft=20says=20'We=20RECOM= MEND=09this=20to=20be=20optional"=20and=20in=20para=204,=20it=20says=20'I= mplementations=20SHOULD=20support=20Keep-Alive=20messages'. =95=20In=20following=20text: It=20is=20possible=20that=20a=20router=20receives=20Join/Prune=20messages= =20for=20an=20interface/link=20that=20is=20down.=20As=20long=20as=20the= =20neighbor=20has=20not=20expired,=20we=20RECOMMEND=20processing=20those= =20messages=20as=20usual. I=20am=20not=20sure=20how=20the=20hello=20timer=20is=20still=20running=20= if=20the=20interface=20is=20down.=20Also=20how=20this=20message=20has=20c= ome=20in,=20if=20the=20link=20itself=20is=20down?=20(I=20am=20assuming=20= that=20the=20link=20here=20means=20the=20port). =95=20In=20last=20para=20of=20section=204.2,=20in=20following=20text: However,=20if=20=20the=20connection=20is=20shared=20by=20multiple=20inter= faces=20and=20the=20GenID=20changes=20only=20for=20one=20of=20them,=20the= n=20there=20was=20not=20a=20full=20restart,=20and=20one=20may=20simply=20= send=20a=20full=20update=20similar=20to=20other=20cases=20when=20a=20GenI= D=20changes=20for=20an=20upstream=20neighbor. Can=20we=20change=20this=20to: However,=20if=20=20the=20connection=20is=20shared=20by=20multiple=20inter= faces=20and=20the=20GenID=20changes=20only=20for=20one=20of=20them,=20POR= T=20neighbor=20SHOULD=20simply=20send=20a=20full=20update=20similar=20to= =20other=20cases=20when=20a=20GenID=20changes=20for=20an=20upstream=20nei= ghbor. =95=20"no=20more=20PIM=20neighborships=20using=20it"=20->=20"no=20more=20= PIM=20neighbors=20using=20it" =95=20Small=20typo=20in=20"rules=20for=20connestion" =95=20J/P_HoldTime=20->=20JP_HoldTime =95=20Typo=20"message=20message=20format" =95=20"Each=20PORT=20message=20will=20have=20the=20below=20Type/Length/Va= lue=20format"=20->=20"Each=20PORT=20message=20will=20have=20the=20Type/Le= ngth/Value=20format" =95=20In=20section=205,=20can=20we=20change=20the=20following=20text: =20If=20any=20parsing=20errors=20occur=20in=20a=20Join/Prune=20message,= =20it=20is=20skipped,=20and=20we=20proceed=20processing=20any=20following= =20PORT=20messages. to =20If=20any=20parsing=20errors=20occur=20in=20a=20PORT=20message,=20it=20= is=20skipped,=20and=20we=20proceed=20to=20any=20following=20PORT=20messag= es. =95=20In=20section=205.1,=20in=20following=20text: As=20can=20be=20seen=20from=20the=20packet=20format=20diagram,=20multiple= =20Join/Prune=20messages=20can=20go=20into=20one=20TCP/SCTP=20stream=20fr= om=20the=20same=20or=20different=20Interface=20IDs. How=20is=20it=20possible=20to=20use=20different=20interface-id=20in=20the= =20same=20message?=20Interface-id=20is=20not=20repeating=20in=20the=20mes= sage=20after=20each=20Option=20buffer. =95=20The=20message=20length=20calculation=20is=20using=20'4*n',=20is=20t= his=20for=20interface-id?=20If=20so=20then=20the=20figure=20needs=20to=20= be=20updated=20to=20show=20interface-id=20before=20next=20PORT=20option= =20type. =95=20Small=20typo=20in=20"are=20not=20sent=20of=20the=20desired=20freque= ncy". =95=20I=20was=20thinking=20that=20keep-alive=20message=20will=20just=20ha= ve=20a=20hold-time=20value=20but=20it=20seems=20to=20bee=20have=20PORT=20= Option=20type=20as=20well.=20The=20reason=20of=20generating=20keep-alive= =20message=20was=20that=20we=20do=20not=20have=20any=20PORT=20messages=20= to=20send=20so=20what=20will=20we=20fill=20in=20PORT=20Option=20type=20in= =20keep-alive=20message. =95=20In=20keep-alive=20message,=20can=20we=20correct=20the=20calculation= =20of=20message=20length?=20It=20uses=204*n=20in=20the=20calculation=20wh= ich=20I=20think=20is=20not=20correct.=20Also=20why=20it=20uses=206=20as= =20the=20starting=20length,=20should=20not=20this=20be=208. =95=20Should=20we=20define=20mux/demux=20term=20somewhere?=20Can=20it=20b= e=20interpreted=20in=20the=20right=20context? =95=20Should=20not=20we=20register=20the=20new=20hello=20option=20'TCP-Ca= pable'=20with=20IANA? ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS***