RE: [magma] Question about proxy implemenation in RFC = 4605

From kunal.shah@ericsson.com Thu Oct 28 15:45:02 2010 Return-Path: X-Original-To: magma@core3.amsl.com Delivered-To: magma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABE53A67BE for ; Thu, 28 Oct 2010 15:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.313 X-Spam-Level: X-Spam-Status: No, score=-4.313 tagged_above=-999 required=5 tests=[AWL=-1.715, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 8kTirIN+DXrB for ; Thu, 28 Oct 2010 15:45:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 72C0E3A6767 for ; Thu, 28 Oct 2010 15:45:01 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9SN7Niw027738 for ; Thu, 28 Oct 2010 18:07:24 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 28 Oct 2010 18:46:52 -0400 From: Kunal Shah To: "magma@ietf.org" Date: Thu, 28 Oct 2010 18:46:50 -0400 Thread-Topic: Question about fast-leave implementation Thread-Index: Act28gKeg1WqzTs6TI21dKWgWWG0bQ== Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2E@EUSAACMS0703.eamcs.ericsson.se> 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_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2EEUSAACMS0703e_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 29 Oct 2010 11:13:28 -0700 Subject: [magma] Question about fast-leave implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 22:45:02 -0000 --_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2EEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Is there any reason to send out a query in fast-leave is enabled on the int= erface?? Enabling fast-leave allows deleting the cache immediately on recei= ving a leave. If the cache is deleted immediately, hosts on the interface w= ill see traffic loss, which makes me think that fast-leave is enabled when = the interface is gauranteed to receive a leave when the last host goes away= or there is only one host on the interface. So does it make any sense in s= ending out a query on receiving a leave if fast-leave is enabled?? Thanks Kunal --_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2EEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Is there any reason to send out a query in fast-leave is enabled on th= e interface?? Enabling fast-leave allows deleting the cache immediately on = receiving a leave. If the cache is deleted immediately, hosts on the interf= ace will see traffic loss, which makes me think that fast-leave is enabled when the interface is gauranteed = to receive a leave when the last host goes away or there is only one host o= n the interface. So does it make any sense in sending out a query on receiv= ing a leave if fast-leave is enabled??

Thanks

Kunal

--_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2EEUSAACMS0703e_-- From sbeeram@hp.com Fri Oct 29 11:20:28 2010 Return-Path: X-Original-To: magma@core3.amsl.com Delivered-To: magma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FEE3A68DB for ; Fri, 29 Oct 2010 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=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 eL7Zc8rpUwLl for ; Fri, 29 Oct 2010 11:20:27 -0700 (PDT) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by core3.amsl.com (Postfix) with ESMTP id F15DC3A6814 for ; Fri, 29 Oct 2010 11:20:26 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id 8A35B2822E; Fri, 29 Oct 2010 18:22:21 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Oct 2010 18:21:32 +0000 Received: from GVW1101EXC.americas.hpqcorp.net ([16.230.34.85]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Fri, 29 Oct 2010 18:21:32 +0000 From: "Beeram, Suresh KumarReddy" To: Kunal Shah , "magma@ietf.org" Date: Fri, 29 Oct 2010 18:21:27 +0000 Thread-Topic: Question about fast-leave implementation Thread-Index: Act28gKeg1WqzTs6TI21dKWgWWG0bQAo4F7A Message-ID: <23E658492CE48649B5B5168EBC60387842C80B2890@GVW1101EXC.americas.hpqcorp.net> References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2E@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2E@EUSAACMS0703.eamcs.ericsson.se> 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_23E658492CE48649B5B5168EBC60387842C80B2890GVW1101EXCame_" MIME-Version: 1.0 Subject: Re: [magma] Question about fast-leave implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:20:28 -0000 --_000_23E658492CE48649B5B5168EBC60387842C80B2890GVW1101EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kunal, Eventhough Fast-leave enabled on interface if no of hosts greater than one = for particular group we need to send query.. Only difference with normal behavior was when no of hosts is only one. Then= FL enabled interface immediately deletes cache entry without sending Query Apart from that no other reason to send out query on FL enabled interface.. Thanks B Suresh Reddy From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of K= unal Shah Sent: Friday, October 29, 2010 4:17 AM To: magma@ietf.org Subject: [magma] Question about fast-leave implementation Hi all, Is there any reason to send out a query in fast-leave is enabled on the int= erface?? Enabling fast-leave allows deleting the cache immediately on recei= ving a leave. If the cache is deleted immediately, hosts on the interface w= ill see traffic loss, which makes me think that fast-leave is enabled when = the interface is gauranteed to receive a leave when the last host goes away= or there is only one host on the interface. So does it make any sense in s= ending out a query on receiving a leave if fast-leave is enabled?? Thanks Kunal --_000_23E658492CE48649B5B5168EBC60387842C80B2890GVW1101EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kunal,

Eventhough Fast-leave enabled on interface if no of hosts greater than one for particular group we need to send query..

Only difference with normal behavior was when no of hosts is only one. Then FL enabled interface immediately deletes <= /p>

cache entry without sending Query

Apart from that no other reason to send out query on FL enab= led interface..

Thanks

B Suresh Reddy

From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of = Kunal Shah
Sent: Friday, October 29, 2010 4:17 AM
To: magma@ietf.org
Subject: [magma] Question about fast-leave implementation=

Hi all,

Is there any reason to send out a query in fast-leave is enabled on the interface?? Enabling fast-leave allows deleting the cache immediately on receiving a leave. If the cache is deleted immediately, hosts on the interf= ace will see traffic loss, which makes me think that fast-leave is enabled when= the interface is gauranteed to receive a leave when the last host goes away or there is only one host on the interface. So does it make any sense in sendi= ng out a query on receiving a leave if fast-leave is enabled??

Thanks

Kunal

--_000_23E658492CE48649B5B5168EBC60387842C80B2890GVW1101EXCame_-- From asaeda@sfc.wide.ad.jp Fri Oct 29 22:44:17 2010 Return-Path: X-Original-To: magma@core3.amsl.com Delivered-To: magma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8413C3A682E for ; Fri, 29 Oct 2010 22:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.848 X-Spam-Level: X-Spam-Status: No, score=-96.848 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508, 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 OYTBQNNC9KVp for ; Fri, 29 Oct 2010 22:42:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 80C613A6844 for ; Fri, 29 Oct 2010 22:41:26 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 26C692780B5; Sat, 30 Oct 2010 14:41:45 +0900 (JST) Date: Sat, 30 Oct 2010 14:41:44 +0900 (JST) Message-Id: <20101030.144144.39171384.asaeda@sfc.wide.ad.jp> To: kunal.shah@ericsson.com From: Hitoshi Asaeda In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2E@EUSAACMS0703.eamcs.ericsson.se> References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D5C2E@EUSAACMS0703.eamcs.ericsson.se> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: magma@ietf.org Subject: Re: [magma] Question about fast-leave implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 05:44:30 -0000 Hi Kunal, > Is there any reason to send out a query in fast-leave is enabled on > the interface?? Enabling fast-leave allows deleting the cache > immediately on receiving a leave. If the cache is deleted > immediately, hosts on the interface will see traffic loss, which > makes me think that fast-leave is enabled when the interface is > gauranteed to receive a leave when the last host goes away or there > is only one host on the interface. So does it make any sense in > sending out a query on receiving a leave if fast-leave is enabled?? Good question. In fact, I've been working the function that supports fast leave. You may want to read the following draft; http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-01 This draft is currently submitted to MBONED. Any commnet is welcome. Regards, -- Hitoshi Asaeda From kunal.shah@ericsson.com Fri Oct 29 17:44:44 2010 Return-Path: X-Original-To: magma@core3.amsl.com Delivered-To: magma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57013A679C for ; Fri, 29 Oct 2010 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gplnLhLy1hbZ for ; Fri, 29 Oct 2010 17:44:43 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 2622D3A657C for ; Fri, 29 Oct 2010 17:44:42 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o9U0kbGN030600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Oct 2010 19:46:37 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 29 Oct 2010 20:46:36 -0400 From: Kunal Shah To: "magma@ietf.org" Date: Fri, 29 Oct 2010 20:46:35 -0400 Thread-Topic: Question about proxy implemenation in RFC 4605 Thread-Index: Act3y+dEzA46tWwmR6yuBZkXU/iNeA== Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AE@EUSAACMS0703.eamcs.ericsson.se> 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_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AEEUSAACMS0703e_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 30 Oct 2010 09:06:44 -0700 Subject: [magma] Question about proxy implemenation in RFC 4605 X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 00:44:44 -0000 --_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AEEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, According to RFC 4605, a router creates a membership database after merging= the subscriptions on individual interfaces. Lets say that 3 IGMPv3 capable= interfaces are as follows: Interface 1 has host reporting Include S1 -> I(S1) Interface 2 has host reporting Exclude S2 -> E(0,S2) Interface 3 has host reporting Exclude nothing -> E(0,0) For a device doing IGMPv3 proxy, the final membership record for group G is= (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, becaus= e of which the subscription on interface 3 would expire and there wont be a= ny IGMPv3 state on interface 3. How would the new membership record for PR= OXY be calculated?? The RFC does not suggest any way to do this. Would IGMP= process have to go through each interface again and then recompute the new= membership record?? This would be very inefficient especially if there are= multiple interfaces. Is there a better way to recompute the new membership record?? Thanks Kunal --_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AEEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

According to RFC 4605, a router creates a membership database after me= rging the subscriptions on individual interfaces. Lets say that 3 IGMPv3 ca= pable interfaces are as follows:

Interface 1 has host reporting Include S1 -> I(S1)

Interface 2 has host reporting Exclude S2 -> E(0,S2)

Interface 3 has host reporting Exclude nothing -> E(0,0)

For a device doing IGMPv3 proxy, the final membership record for group= G is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, b= ecause of which the subscription on interface 3 would expire and there wont= be any IGMPv3 state on interface 3. How would the new membership record for PROXY be calculated?? The = RFC does not suggest any way to do this. Would IGMP process have to go thro= ugh each interface again and then recompute the new membership record?? Thi= s would be very inefficient especially if there are multiple interfaces.

Is there a better way to recompute the new membership record??

Thanks

Kunal

--_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AEEUSAACMS0703e_-- From Alvaro@soportemv.com Sat Oct 30 10:34:30 2010 Return-Path: X-Original-To: magma@core3.amsl.com Delivered-To: magma@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAC63A63C9 for ; Sat, 30 Oct 2010 10:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bAw3SwL5VDLh for ; Sat, 30 Oct 2010 10:34:29 -0700 (PDT) Received: from soportemv.com (correo.soportemv.com [80.81.115.248]) by core3.amsl.com (Postfix) with ESMTP id 6DEAE3A677D for ; Sat, 30 Oct 2010 10:34:26 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7858.F6BF7B75" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 30 Oct 2010 19:36:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about proxy implemenation in RFC 4605 Thread-Index: Act3y+dEzA46tWwmR6yuBZkXU/iNeAAi/kn8 References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AE@EUSAACMS0703.eamcs.ericsson.se> From: "Alvaro Fernandez" To: "Kunal Shah" Cc: magma@ietf.org Subject: Re: [magma] Question about proxy implemenation in RFC 4605 X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:34:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7858.F6BF7B75 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kunal I read it years ago but I think RFC 4605 explains that the downstream = network interface should behave like a router, so the solution is in the = state machine explained in RFC3376 for the IGMPv3 router =C1lvaro -----Mensaje original----- De: magma-bounces@ietf.org en nombre de Kunal Shah Enviado el: s=E1b 30/10/2010 2:46 Para: magma@ietf.org Asunto: [magma] Question about proxy implemenation in RFC 4605 =20 Hi all, According to RFC 4605, a router creates a membership database after = merging the subscriptions on individual interfaces. Lets say that 3 = IGMPv3 capable interfaces are as follows: Interface 1 has host reporting Include S1 -> I(S1) Interface 2 has host reporting Exclude S2 -> E(0,S2) Interface 3 has host reporting Exclude nothing -> E(0,0) For a device doing IGMPv3 proxy, the final membership record for group G = is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, = because of which the subscription on interface 3 would expire and there = wont be any IGMPv3 state on interface 3. How would the new membership = record for PROXY be calculated?? The RFC does not suggest any way to do = this. Would IGMP process have to go through each interface again and = then recompute the new membership record?? This would be very = inefficient especially if there are multiple interfaces. Is there a better way to recompute the new membership record?? Thanks Kunal ------_=_NextPart_001_01CB7858.F6BF7B75 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [magma] Question about proxy implemenation in RFC = 4605

Hi Kunal

I read it years ago but I think RFC 4605 explains that the downstream = network interface should behave like a router, so the solution is in the = state machine explained in RFC3376 for the IGMPv3 router

=C1lvaro

-----Mensaje original-----
De: magma-bounces@ietf.org en nombre de Kunal Shah
Enviado el: s=E1b 30/10/2010 2:46
Para: magma@ietf.org
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

According to RFC 4605, a router creates a membership database after = merging the subscriptions on individual interfaces. Lets say that 3 = IGMPv3 capable interfaces are as follows:

Interface 1 has host reporting Include S1 -> I(S1)
Interface 2 has host reporting Exclude S2 -> E(0,S2)
Interface 3 has host reporting Exclude nothing -> E(0,0)

For a device doing IGMPv3 proxy, the final membership record for group G = is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, = because of which the subscription on interface 3 would expire and there = wont be any IGMPv3 state on interface 3. How would the new = membership record for PROXY be calculated?? The RFC does not suggest any = way to do this. Would IGMP process have to go through each interface = again and then recompute the new membership record?? This would be very = inefficient especially if there are multiple interfaces.
Is there a better way to recompute the new membership record??

Thanks
Kunal

------_=_NextPart_001_01CB7858.F6BF7B75--